The EU Cyber Resilience Act Just Got Real: What IoT Teams Must Fix Before 2027?
On June 11, 2026, something quiet but consequential happened across the EU. Member states had to designate their notifying authorities. These bodies certify who can assess connected products under the Cyber Resilience Act (CRA). No press conference, no dramatic headline. Just the first domino in a regulatory sequence. It will reshape how companies design, ship, and maintain connected hardware and embedded software sold into the EU.
Does your roadmap include anything with a chip, a sensor, or a firmware update mechanism? Think industrial controllers, fleet telematics, medical-adjacent monitoring equipment, smart retail hardware, wearables, or connected vehicles. If so, the CRA applies to you. It doesn’t matter where your company is headquartered or where you manufacture the product. The obligation attaches to placing the product on the EU market, full stop. That’s according to the European Commission’s Cyber Resilience Act overview.
A staggered deadline, not a single cliff edge
The CRA doesn’t arrive all at once. That’s exactly why so many product teams are underprepared: there’s no single date forcing urgency. The timeline breaks into three real milestones. By June 11, 2026, Member States had to put conformity assessment infrastructure in place. September 11, 2026 is the one every embedded team should mark on its calendar. From that date, manufacturers must report actively exploited vulnerabilities within 24 hours of discovery. The report goes to ENISA and the relevant national CSIRT. A full notification follows within 72 hours. A final report is due within 14 days, as TechTimes reported when the 24-hour vulnerability clock was announced. Then December 11, 2027 brings full compliance across the essential cybersecurity requirements of the regulation. Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover.
Eighteen months sounds comfortable. It isn’t, once you map it against how teams build embedded products in practice.
Why most embedded and IoT teams aren’t ready
Four gaps show up again and again in connected-product organizations, and none of them are quick fixes.
Start with the paper trail. Embedded stacks accumulate third-party libraries, RTOS components, and vendor SDKs over years of development. Most teams can tell you what’s in the current firmware release, but not much before that. Very few can produce a complete, versioned bill of materials across every product still in the field. That’s exactly what a 24-hour vulnerability disclosure clock demands, per ArmorCode’s CRA requirements guide.
Then there’s the update problem. A CRA-compliant product needs a secure, authenticated over-the-air update path for its full support lifetime. Much of today’s fielded hardware never anticipated that need. Engineers assumed firmware would rarely, if ever, change after shipment. Retrofitting OTA into a product line that lacks it takes real engineering work, not a quick patch you bolt on later.
Incident response is the third gap, and it’s the one teams underestimate most. Reporting a vulnerability to ENISA within 24 hours assumes three things are already in place. You need monitoring that can detect exploitation. You need an escalation path that doesn’t depend on one engineer answering their phone. And you need disclosure templates drafted before you need them. Most embedded teams have never run this drill, because until now nothing forced them to.
The fourth gap sits outside engineering entirely. Most embedded products depend on components such as chipsets, modules, RTOS distributions, and third-party SDKs. Most companies never asked those suppliers for a security attestation or a patch commitment. Few even have a reliable contact for vulnerability disclosure. The CRA makes the integrator responsible for the security posture of everything in the bill of materials. That includes parts they didn’t write a single line of code for. Supplier contracts and procurement criteria need updating alongside the engineering work. That’s a conversation most product teams haven’t had yet with their hardware vendors.
The retrofit problem: products already in the field
Teams can architect new product lines for CRA compliance from the start. The harder question is what happens to everything already shipped. Think of the industrial controllers, fleet trackers, and connected hardware sold over the last five to ten years. Much of it is still under warranty or still generating revenue through service contracts. Engineers never designed a lot of that installed base with an OTA update path, let alone a signed one. That means “just push a patch” isn’t an option without a hardware or firmware architecture change.
Products with long field lifecycles face a real strategic decision. Industrial, aerospace, and maritime hardware routinely runs for ten years or more. Teams can retrofit a secure update mechanism into the current generation. They can accept a defined end-of-support date and communicate it to customers. Or they can manage the compliance gap through compensating controls, such as network segmentation or managed monitoring. That buys time until the next hardware revision ships. None of these options are free. The right choice depends on unit count in the field and how much runway remains before December 2027. The teams handling this best are mapping their installed base against the CRA’s requirements now. There’s still time to choose deliberately rather than react.
The compliance surface is also getting bigger, not smaller
This lands at an inconvenient moment. Enterprise IoT is moving past the pilot phase into what analysts now call “autonomous connected operations.” That means more devices, more autonomy, and more data flowing between machines with less human review in the loop. That’s according to IoT Analytics’ State of Enterprise IoT 2026 report. Every device added to a fleet is one more entry in the SBOM and one more endpoint that needs an update path. It’s also one more thing to track once a vulnerability disclosure clock starts ticking. Growth and compliance debt are compounding at the same time. That’s exactly why teams can’t treat this as a document-writing exercise handed to legal in Q4 2027.
What “secure by design” means in practice
For product and engineering leaders, CRA readiness breaks into work that’s genuinely architectural, not cosmetic:
CRA readiness starts with secure boot and signed firmware, so a device only runs code it has cryptographically verified. It also means encrypting and authenticating communication between devices and back-end services. That protection needs to hold not just at rest, but as data moves across the fleet. Teams need a maintained, exportable SBOM that regenerates automatically as part of the build pipeline. That beats an SBOM an engineer assembles by hand only when an auditor asks. They need a tested OTA mechanism that can push a patch to deployed hardware. No truck roll required, no asking a customer to plug something in manually. And they need an incident response runbook the team has rehearsed, not just written. That way, the 24-hour clock doesn’t start with someone reading the regulation for the first time.
None of it is exotic. It just means applying discipline earlier in the product lifecycle than most embedded roadmaps allow for.
A realistic roadmap for the next eighteen months
Teams that treat this as a single 2027 deadline tend to compress all the hard decisions into the final quarter. That’s exactly when engineering capacity is scarcest and mistakes are most expensive. A more workable sequence starts now, in the second half of 2026, with a gap assessment. That means mapping every connected product line against the CRA’s essential requirements. It means cataloguing what SBOM data already exists versus what needs reconstruction. And it means identifying which fielded products can realistically get a secure OTA retrofit versus which need a defined end-of-support date.
That assessment should feed directly into architecture decisions before any 2027 hardware revision locks its bill of materials. Retrofitting secure boot or signed firmware into a design that’s already frozen costs dramatically more than specifying it up front. Teams can build and rehearse incident response processes and monitoring in parallel, well ahead of the September 2026 reporting obligation. That way, the first real disclosure isn’t also the first time anyone has run the process. None of this requires waiting for a final compliance deadline to start. It requires treating the next eighteen months as the working window it is.
How we approach this at Allmatics
This is squarely inside the work we do in Embedded IoT Development and Tech Consulting. That includes gap assessments against the CRA’s essential requirements, security retrofits for fielded products, and OTA pipeline design. We also build the SBOM and monitoring tooling that makes a 24-hour disclosure window achievable instead of aspirational. We’ve built connected systems across aviation, maritime, and logistics hardware, and the pattern holds everywhere. The earlier security becomes a first-class requirement, not a checklist item, the cheaper compliance gets down the line.
If your product roadmap has connected hardware shipping into the EU between now and December 2027, plan ahead. The right time for a product idea evaluation that includes a CRA gap assessment is before the next hardware revision locks in. Don’t wait until regulators start asking questions.