Original article Total Telecom:Read More
Interview
We caught up with Steven Offerein, VP of Product, Device Intelligence and Protection Services at CUJO AI, to discuss changes to the EU’s cybersecurity rules for connected products and what that will mean for operators
From 11 September, the first major obligations under the EU’s new cybersecurity rules for connected products take effect, with mandatory reporting of actively exploited vulnerabilities and severe security incidents. While much of that responsibility falls on manufacturers, operators have good reason to pay attention: they supply and manage millions of gateways and other connected products, and in some cases may themselves fall within the CRA’s definition of a manufacturer.
The regulation may put manufacturers on the clock, but operators are often the ones left dealing with the consequences on the network. That raises a bigger question: as Europe redraws the rules around connected-device security, where does the manufacturer’s responsibility end, and the operator’s begin?
Steven Offerein looks at what happens next, from identifying affected devices to protecting customers when a patch is no longer an option.
On paper, the CRA is a manufacturer’s law. Why is it an operator’s problem?
Two reasons. The first is that operators are not always just customers under the CRA; they can also be subject to it. If you put your brand on a gateway or substantially modify a product in a way that affects its cybersecurity, you may find yourself in the manufacturer’s seat, with the manufacturer’s obligations. Plenty of operators haven’t worked out yet which side of that line their CPE portfolio sits on.
The second is scale. An operator with tens of millions of gateways in the field is, in practical terms, one of the parties closest to the problem when a vulnerability is being actively exploited. The manufacturer may have the reporting obligation, but the exploit traffic runs across the operator’s network and into its customers’ homes. The CRA formalises the reporting, but it doesn’t change who must deal with the consequences.
Most of the industry is treating the CRA as a December 2027 problem. What are they missing?
The date. Most of the attention has gone to the full conformity requirements, CE marking, essential security requirements and support periods, which apply from December 2027. But the reporting obligations arrive first, on 11 September 2026, and crucially they apply to products already on the market, not just new ones.
The other misconception is that this is purely a paperwork exercise. A 24-hour reporting window puts pressure on the entire vulnerability-response process. For operators that also qualify as manufacturers, that means having the processes in place to establish what has happened and respond quickly. More broadly, operators need to understand whether a disclosed vulnerability affects devices across their installed base.
So, what concretely changes on 11 September, and who is actually on the clock?
For anyone who qualifies as a manufacturer, the mechanics are specific: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident, a fuller notification within 72 hours, and a final report once the issue is resolved. Reports go through the CRA’s single reporting platform, with the relevant national CSIRT and ENISA involved in the process.
For operators that don’t hold the manufacturer’s role, the change is more indirect but still important. Their vendors will have new legal reporting obligations when they become aware of active exploitation or severe incidents affecting their products. That should mean information about problems in the installed base moves more quickly.
But knowing a vulnerability exists is only step one. Knowing which subscribers actually have the affected device, whether it can be updated, and what you’re going to do about it is a different challenge.
You talk a lot about visibility. How can an operator managing 20 million gateways not know what’s connected to its own network?
Because the gateway fleet and the device population behind it are two completely different problems. Operators know what they’ve shipped. What’s much harder is maintaining a reliable, current view of what is actually connected behind those gateways — not what’s in a procurement database, but what’s present in customers’ homes.
Behind 20 million gateways, you’ll typically find several hundred million connected devices. Those devices arrive without registration, identify themselves inconsistently or not at all, and the mix changes every day.
Real visibility means identifying those devices by type, model and, where possible, software or firmware version, continuously and at population scale. When a vulnerability disclosure lands, the difference is being able to say, “We have 340,000 potentially affected devices across these markets,” rather than, “We genuinely don’t know.”
A vulnerability gets disclosed. Why is “which homes have this device?” now such an important question?
Detection without identification doesn’t lead to an actionable response. If you know an exploit is circulating but can’t say which homes have the affected device, you either treat every subscriber as potentially affected or risk missing the ones that are.
Identification turns a CVE from an abstract industry problem into a sized, addressable operational task. I think the ability to map a disclosure to an affected device population quickly will increasingly become a baseline operator capability, much like outage mapping is today.
Say that an operator knows exactly which devices are vulnerable. Then what?
It depends entirely on the device. For CPE the operator controls, the path is relatively clear: prioritise and push the firmware update, then use the management infrastructure to track uptake. For third-party devices in the home that still have vendor support, the operator’s role is more about awareness — helping customers understand what’s affected and what action they can take. Then there’s the third category, which is the uncomfortable one: devices that are vulnerable and will never receive a fix. That’s where the conversation shifts from remediation to mitigation.
The CRA is designed to ensure vulnerabilities are handled. What about the millions of existing devices that may never receive another update?
This is the reality nobody likes to talk about. Walk into an average European home, and you’ll find devices whose manufacturers no longer exist, cheap IoT products that never had a meaningful update mechanism in the first place, and perfectly functional equipment that has simply aged out of support. The customer often has no idea, and frankly no reason to know. The camera still streams, the plug still switches.
The CRA should improve this over time by requiring manufacturers to define support periods and establish proper vulnerability-handling processes for products covered by the new requirements. But it doesn’t make the existing population of unsupported devices disappear. Those products could remain in homes for years, and for many of them, “install the patch” simply isn’t an option. Something else has to mitigate the risk.
Is it really the operator’s job to protect a consumer’s abandoned smart camera?
Operators are in a unique position to help. If the device can no longer protect itself and the manufacturer is no longer providing updates, the network may be one of the few remaining places where protections can be applied.
The gateway sits in a particularly useful position because traffic to and from that device passes through it. Network-level security can block known malicious traffic before it reaches a vulnerable device, detect unusual behavior that may indicate compromise, and help contain compromised devices so they can’t threaten other devices in the home or be recruited into a botnet. None of that requires the vulnerable device to cooperate, which is precisely the point.
The CRA focuses on responsibility for the security of the product. Network-level security can provide another layer of protection, particularly where product-level protections are no longer available.
Will the CRA genuinely change how operators buy and manage CPE, or will price still win every RFP?
It should. Support periods, vulnerability handling, and update capability used to be secondary criteria in many RFPs, behind factors such as price and performance. The CRA gives those considerations much more weight.
It also forces more honesty around lifecycle management. Operators have historically been comfortable letting CPE sit in the field for a long time, because replacing hardware at scale is expensive. When a gateway carries a defined support period and vulnerabilities have to be handled throughout that period, end of support becomes a much more visible event. Operators have to plan for it: extend support contractually, replace the unit, or understand how the remaining risk will be mitigated.
Some argue that the CRA will force operators to pull CPE from the field sooner. Do you buy that?
Not necessarily. I think the more interesting outcome could be longer, better-supported lifecycles.
The wasteful pattern today isn’t always hardware living too long; it’s hardware being abandoned by software long before the silicon is done. A gateway can remain physically capable of providing service for years after active software support has declined.
The CRA puts more commercial and legal structure around support periods. That gives operators a reason to demand longer commitments upfront and gives vendors a way to account for those commitments commercially.
There’s also a sustainability angle. Replacing millions of units before the hardware itself needs replacing carries both an environmental and financial cost. The better outcome is hardware that’s properly supported for longer, alongside additional protections where updates are no longer available.
What are operators still failing to ask their hardware and software vendors?
I’d start with a few basic questions. Who is the manufacturer of record for this product under the CRA — you or us — and is that written down? What is the committed support period, and what exactly does “support” include?
Then, there are operational questions. Can you provide and maintain a software bill of materials? What is your coordinated vulnerability disclosure process? How quickly will we hear from you when something is being actively exploited? And are the reporting responsibilities between us clear enough that nobody is debating ownership when the clock starts?
A few years ago, some of those questions might have seemed overly cautious. Today, they need to be part of the conversation.
Every vendor now claims to “solve” CRA compliance. What can device intelligence honestly do, and what can’t it?
Let me be clear about the limits first: no platform makes you CRA compliant. Compliance involves processes, documentation, conformity assessment and legal accountability, and that responsibility belongs to the organization.
Where device intelligence can help is at the operational layer underneath. It can give operators a more accurate picture of what’s actually connected across the subscriber base, allowing a vulnerability disclosure to be mapped to a real device population much more quickly.
Combined with network security capabilities, visibility can also help operators understand suspicious behavior and apply protections to vulnerable or compromised devices — including devices that may never receive another update.
The CRA defines the responsibilities. Device intelligence can help operators build the visibility needed to respond at the scale of a broadband network.
An operator can’t fix everything before the deadline. What comes first?
Three things.
First, settle the role question. Go through your CPE and software portfolio and determine, product by product, whether you’re a manufacturer, importer or distributor under the CRA. Everything else depends on that answer, and it’s legal exercise, not a technical one.
Second, build the reporting process now. If any part of your portfolio puts you in the manufacturer’s seat, you need a rehearsed path from “we’ve become aware” to an early warning within the required timeframe. That means clear ownership, internal escalation, and an on-call process that exists before you need it.
Third, invest in visibility of the installed base — both the CPE fleet and the device population behind it. When a new vulnerability emerges, operators need to be able to establish what is affected, where it is, and what action is possible. Operators that can answer those questions quickly will be in a much stronger position to respond. Those that can’t may find every new disclosure becomes a fire drill.
Steven Offerein is VP of Product, Device Intelligence and Protection Services at CUJO AI, the market leader in device intelligence, network intelligence, and cybersecurity solutions for network operators, protecting more than 60 million households worldwide. He has over 15 years of experience in cybersecurity, telecommunications, and product leadership. Before joining CUJO AI in 2025, Steven held senior roles at F-Secure and TalkTalk, developing security solutions and connected-home products for international markets.
The post The devices you can’t patch: A hidden challenge behind the CRA appeared first on Total Telecom.