IoT Security Used to Be Someone Else's Problem. The Cyber Resilience Act Just Changed That.

By Iain Davidson, Head of Product Marketing

 With thirty years across systems, networking and telecoms, the last decade deep in IoT, Iain Davidson knows exactly where the gaps are between how organisations think about connected device security and what's actually happening in the field. 

 In September 2020, an employee at a UK water utility company called South Staffordshire PLC, opened a phishing email. It was, by all accounts, a convincing one. Malicious software was installed. And then, for the better part of twenty months, absolutely nothing happened. 

Behind the scenes however, attackers had gained full administrative access to the company's systems. They stayed. They looked around. They helped themselves. By the time anyone noticed, 4.1 terabytes of data had been exfiltrated and published on the dark web. The personal records of 633,000 customers , that water utility's customers, people who had no meaningful choice in the matter, were compromised.

The fine was around €1 million.. Significant, but not ruinous. The reputational damage, the customer impact, the operational disruption perhaps a little more significant.

This is not an isolated story. It is, increasingly, a template 

Why the CRA regulation was always coming

For years, the approach to cybersecurity across most industries was broadly voluntary. Frameworks existed of course, lots of them: ISO 27001, NIS2, EN 18031, EN 303645 and more, (A bit of an EU focus here, but every region has their equivalents such as NIST CSF in the USA) and organisations were encouraged to adopt them. Many did. Many didn't, or adopted them partially, or treated them as a point-in-time certification exercise rather than an ongoing operational commitment.

Legislators and regulators watched this pattern for long enough. The conclusion they reached was not unreasonable: when the consequences of poor security extend beyond the organisation itself, to customers, to critical infrastructure, to public safety, voluntary compliance is insufficient.

The EU Cyber Resilience Act (and for the UK, the incoming Cyber Security & Resilience Bill) is the most significant legislative response to that conclusion. It applies to any organisation manufacturing or selling connected products into the European market. It is not a checklist. It does not prescribe exactly how security must be achieved. What it does is require organisations to apply systematic, risk-based thinking to the security of their connected products or assets and not just at the point of launch, but across the entire lifecycle.

 That last part is where most organisations haven't yet caught up. 

The lifecycle problem nobody talks about

Historically, product security was largely a launch-time concern. You built the device, you certified it, you shipped it. Maybe you bought it with all the certifications confirmed. Security was someone else's problem after that whether that be the OEM's, the connectivity provider's or your IT team's.

The CRA removes that ambiguity entirely. Security is now a lifecycle responsibility. Vulnerability management, firmware updates, patch deployment, breach disclosure, incident response, these are ongoing obligations, not one-time activities. For a device with a ten or fifteen year operational lifespan, that is a fundamentally different proposition than anything most product and engineering teams have had to plan for before.

This matters particularly for IoT and connected devices, which present a very different challenge than traditional IT systems. A managed laptop fleet such as smartphones, desktops, standard enterprise endpoints operates within a relatively controlled environment, with standardised tooling, known operating systems, and direct administrative access. IoT devices don't work that way. They're distributed across locations you may not control, running on varied and sometimes proprietary operating systems, with limited compute resources, and communicating infrequently with systems that may themselves be third-party managed. Many of them cannot support the kind of agent-based security that traditional IT teams rely on. And many of them will be in the field long after the team that deployed them has moved on.

The gap between the boardroom and the field

There is a consistent pattern in how organisations are currently approaching CRA readiness, and it is not always especially reassuring.

At board level, compliance tends to be understood as a governance exercise. There’s documentation, certification, a process to be managed before deployment. The assumption is that if the right boxes have been ticked at launch, the obligation has been met.

The operational reality is different. The questions that actually matter under the CRA are practical ones: Do you know where every device in your fleet is deployed? Do you know what firmware version each one is running? Can you push an update to a compromised device remotely? Can you isolate it from the network quickly if you need to? Do you know, right now, whether any of your devices are communicating with server infrastructure they shouldn't be? (remember that data exfiltration problem I opened with?)

For many organisations, the honest answer to several of those questions is no. Not because of negligence, but because the tooling and processes to answer them at scale simply haven't been in place. The CRA is, in effect, requiring organisations to build that capability, and to maintain it continuously, not demonstrate it once.

When the media covers regulatory non-compliance, the focus is usually on the financial penalty. The CRA carries fines of up to €15 million or 2.5% of global annual turnover for the most serious breaches. Those numbers are large enough to command attention in a board meeting.

But the fine is arguably the least of it.

Operational downtime following a cyber incident creates immediate, tangible costs — service disruption, customer impact, recovery effort. In sectors like EV charging, healthcare, fleet telematics, or utilities, downtime isn't just inconvenient. It can be a significant commercial and safety event. Reputational damage accrues more slowly but lasts longer. And there is a growing pattern, one that is already visible in enterprise procurement , of buyers actively assessing a supplier's cybersecurity posture before awarding contracts. Organisations with a history of incidents, or without demonstrable security processes, are beginning to find themselves excluded from procurement frameworks before the conversation even starts.

Insurers are asking harder questions too. Cyber insurance underwriters have become considerably more rigorous about what they'll cover and at what premium, and lifecycle security practices, such as patching, monitoring, incident response, are increasingly part of that assessment.

The financial risk of getting this wrong is not the fine.

It is the compound effect of downtime, reputational damage, procurement exclusion, and insurance exposure, accumulating over time. Well known organisations such as Jaguar Land Rover have already started to feel the impact of these kind of attacks (24) Post | LinkedIn 

The not-if-but-when mindset

One of the more useful reframes that the CRA implicitly encourages is moving away from the idea that perfect security is achievable, toward the question of what happens when, not if, something goes wrong.

No organisation can credibly claim 100% protection. Attackers are persistent, tooling is constantly evolving, and the attack surface for a large distributed IoT fleet is simply too broad to defend entirely. The question is not whether a breach will occur, but whether the organisation has the visibility to detect it quickly, and the capability to respond effectively.

This is where the CRA's emphasis on monitoring and incident response becomes practically important. Regulators, it turns out, are not unsympathetic to organisations that experience attacks. What they are unsympathetic to is organisations that experience attacks and had no meaningful detection or response capability in place. The difference between a manageable regulatory conversation and a serious enforcement action is increasingly about what you had in place and how quickly you acted, not whether the attack happened at all.

South Staffordshire Water is instructive here too. Twenty months is an extraordinary length of time for an attacker to operate undetected inside a utility's systems. The fine reflected not just the breach, but the absence of the monitoring that would have caught it sooner.

Some organisations are getting ahead of the CRA

Not every organisation is approaching the CRA with dread. A growing number are treating it as an opportunity to differentiate. They’re building their own security frameworks, adopting lifecycle security tooling, and using their demonstrable posture as a selling point in regulated markets.

It is a reasonable strategy. In sectors where buyers are increasingly sceptical of vague cybersecurity claims, the ability to show, ,not just assert, that you have systematic, continuous, lifecycle security in place is becoming a genuine commercial advantage. The organisations moving fastest are those applying proportionate, risk-led thinking rather than trying to apply maximum controls to every device equally. Identify what is operationally critical. Focus on what is externally exposed. Build visibility, establish secure connectivity, ensure you can patch remotely, and make certain your monitoring and incident response capability is real, not theoretical.

Those are the fundamentals. And organisations that have them in place are finding that compliance and competitive differentiation are, in practice, the same thing.

 The Cyber Resilience Act is not a bureaucratic inconvenience. It is a structural shift in how responsibility for connected product security is allocated  away from a diffuse, contested space where everyone assumed it was someone else's problem, and toward a clear, enforceable obligation on the organisations that build and deploy connected products. 

For IoT specifically, that shift has implications that go well beyond legal compliance. It requires a different approach to product development, a different set of operational capabilities, and a different conversation at board level about what security actually means across the full life of a deployed device.

The organisations that understand that earliest will be in the strongest position, commercially, operationally, and regulatorily, when the enforcement that inevitably follows the legislation begins to bite.

 Iain Davidson is Head of Product Marketing at Wireless Logic, with a background in IoT connectivity and cybersecurity 

Wireless Logic's Anomaly and Threat Detection is built specifically for the security challenges of IoT and edge environments. Agentless for quick deployment.