EU Cyber Resilience Act – IoT Information

The EU Cyber Resilience Act entered into force in December 2024. Full compliance kicks in December 2027. Vulnerability reporting obligations start in September 2026 – which is four months from now.

Most of the coverage has come from compliance lawyers billing by the hour and security vendors with something to sell you. Very little of it has come from people who have actually deployed thousands of IoT devices across real industrial sites, logistics hubs, and commercial premises – people who know what “secure by default” looks like on the ground rather than in a white paper.

So here is a plain account of what the CRA requires, why most of the deployed estate is already non-compliant, and what it means if you sit in the middle of the supply chain as a reseller or integrator.

The timeline, without the padding

Three dates matter. Everything else is noise.

That September 2026 date is the one most people have missed. It is not theoretical. If you have a product on the EU market with an actively exploited vulnerability, you will be required to report it to the European Union Agency for Cybersecurity within 24 hours of becoming aware of it. Not 72 hours. Not “when convenient.” 24 hours.

What the CRA actually requires

Strip away the legal language and there are six things the CRA is demanding of products with digital elements – which includes any hardware or software with network or device connectivity.

1. No default or universal passwords

Devices must ship without hardcoded credentials or universal default passwords. Every device must have a unique authentication secret. Shipping a thousand units all with the same admin/admin login is finished.

This sounds obvious. It is not how a significant portion of industrial IoT gear currently ships.

2. Secure by default configuration

Products must be delivered in a secure configuration out of the box. Open ports, exposed services, and permissive default settings are not acceptable. The burden is on the manufacturer to make the device secure without the customer having to harden it.

3. A Software Bill of Materials

Manufacturers must produce and maintain an SBOM – a machine-readable inventory of every software component in the product, including version numbers and dependencies. Think of it as a nutritional label for firmware. The SBOM does not have to be made public, but it must be available to market surveillance authorities on request and must be retained for ten years.

The SBOM is also what makes the 24-hour vulnerability reporting requirement actually achievable. Without one, you cannot know within 24 hours whether a newly disclosed CVE affects your product.

4. Firmware update obligations

Manufacturers must provide security updates for the expected product lifetime or five years from market release – whichever is shorter. Those updates must be free, secure in delivery, and available without unnecessary delay when a vulnerability is identified.

A device sold and then quietly abandoned is not compliant. A device with a firmware update mechanism that requires users to download a ZIP file and manually flash it via USB is… arguable.

5. Vulnerability disclosure and reporting

Manufacturers must have a publicly accessible route for reporting vulnerabilities. They must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. They must inform users about security incidents and the corrective action available to them.

6. No known exploitable vulnerabilities at launch

Products cannot be placed on the EU market with known exploitable vulnerabilities. The word “known” is doing a lot of work there – but the intent is clear. You cannot ship something you already know is broken.

The problem with the deployed estate

Here is where anyone with field experience will recognise the gap between the CRA’s requirements and reality.

The IoT estate deployed across the UK and Europe over the last decade is enormous. It includes cellular gateways, industrial routers, remote monitoring units, SCADA edge nodes, environmental sensors, energy meters, and a long tail of niche devices built for specific verticals. A significant portion of it was designed and shipped before any of these requirements existed.

Common characteristics of that estate:

• Default credentials that were never changed during commissioning
• Firmware that has not been updated since installation – in some cases since manufacture
• No documented SBOM, no record of third-party components
• No OTA update capability at all – updates require physical access or manual intervention
• Manufacturers who have been acquired, gone under, or simply stopped supporting the product line
• Devices with open management interfaces exposed on public IP addresses

“Secure by default” in a white paper means a checkbox. Secure by default in a field cabinet at a water treatment plant that last had a site visit in 2019 means something rather different. The CRA addresses what gets built from now on. It does not magic away what is already installed.

Where resellers and integrators sit

This is the part the compliance coverage largely ignores, because compliance lawyers are usually retained by manufacturers.

The CRA defines obligations for manufacturers, importers, and distributors. Resellers and integrators sit in a complicated position depending on exactly what they do.

If you source a device from a manufacturer and resell it under that manufacturer’s branding, you are a distributor. Distributors have lighter obligations – primarily checking that the product carries the required CE marking, that technical documentation exists, and that the product is not non-compliant in an obvious way before passing it on.

But if you do any of the following, the obligations escalate:

• You put your own name or trademark on the device
• You make a “substantial modification” to the product
• You configure and deploy the device as part of a broader solution and take responsibility for its operation

The first two transform you into the manufacturer in the eyes of the regulation. That brings the full set of obligations: SBOM, vulnerability reporting, update obligations, CE marking, technical documentation – all of it.

What counts as a “substantial modification” is not entirely settled. Flashing a custom firmware image is almost certainly a substantial modification. Reconfiguring APN settings is almost certainly not. The large grey area in between is where integrators need to be careful.

What to do now

September 2026 is four months away. December 2027 is nineteen months away. Neither date is distant enough to ignore.

For anyone operating in the IoT hardware supply chain in the UK – resellers, integrators, system builders – there are practical steps worth taking now.

• Audit your supplier list. Which manufacturers are actively preparing for CRA compliance? Which ones have gone quiet on it? The answer tells you something about the risk profile of your product portfolio.
• Understand what you are actually doing to devices. If you configure, flash, or label devices before deployment, get clarity on whether that triggers manufacturer obligations.
• Ask for SBOMs. Any manufacturer that cannot or will not provide an SBOM by 2027 is not CRA-compliant. Starting to ask the question now gives you lead time to switch suppliers if necessary.
• Document your deployment configurations. What credentials are set? What firmware version is running? This matters both for your own risk management and for any vulnerability disclosure obligations.
• Review your customer contracts. If you are responsible for a deployment that turns out to contain non-compliant devices, where does the liability sit? Most integration contracts were written before the CRA existed.

Questions to ask your hardware suppliers

Not rhetorical questions. Actual questions, in writing, that you should be putting to every manufacturer in your supply chain before the end of 2026.

1. What is your CRA compliance roadmap and what is your target date for placing fully compliant products on the EU market?
2. Do your current products ship with unique per-device credentials, or with universal default passwords?
3. Can you provide a machine-readable SBOM for each product SKU? In what format – CycloneDX or SPDX?
4. What is your OTA update mechanism, and how long will you guarantee security update support from the date of last sale?
5. Do you have a public vulnerability disclosure process in place? Where is it documented?
6. How will you notify us if an actively exploited vulnerability is discovered in a product we have deployed?
7. If we configure devices with custom settings before deployment, does your legal team consider that a substantial modification under the CRA?

A supplier that cannot answer these questions by mid-2026 is a supplier that is going to cause you problems in 2027.

The UK angle

The UK has its own product security legislation – the Product Security and Telecommunications Infrastructure Act 2022 (PSTI), which came into force in April 2024. It covers consumer connectable products and has requirements around default passwords and vulnerability disclosure that overlap significantly with the CRA’s direction.

The UK is no longer subject to the CRA directly. But any UK business selling into EU markets – or sourcing hardware from manufacturers who sell into EU markets – is inside the CRA’s reach. Most hardware supply chains are not cleanly divided by geography. If your manufacturer is shipping CRA-compliant devices into the EU from late 2027, those will likely be the devices you receive too.

The practical effect is convergence. The direction of travel for IoT device security is consistent across jurisdictions. The CRA just happens to have the sharpest teeth.

The honest summary

The CRA is well-intentioned and largely technically correct. No universal default passwords, SBOMs, firmware update obligations, and rapid vulnerability disclosure are things the IoT industry should have been doing anyway. It took regulation to make them mandatory.

The gap is between what the regulation describes and what is actually in the field. The deployed estate is not going to become compliant by December 2027. Much of it cannot be made compliant without hardware replacement. That is a problem that the regulation does not solve and does not particularly acknowledge.

For people selling, deploying, and maintaining IoT hardware for a living, the practical work right now is supplier auditing, contract review, and working out exactly where your role in the supply chain puts you under the regulation. None of that work is glamorous. All of it is necessary.

The lawyers will tell you about risk and liability. The security vendors will tell you about their compliance platforms. I will tell you that if your field cabinet contains a cellular gateway running three-year-old firmware with admin/admin still set, you have got a more immediate problem than a regulation that kicks in next year.