The EU Cyber Resilience Act hits IoT this September. Most product teams aren't ready.

On September 11, 2026, the first teeth of the EU Cyber Resilience Act bite. From that date, anyone selling a product with digital elements into the EU — a smart thermostat, a fleet tracker, a connected coffee machine, the firmware inside any of them — must report actively exploited vulnerabilities to EU authorities within 24 hours of learning about them. Not 24 business hours. Twenty-four hours.

That's three months from now. And it applies to products you've already shipped, not just the ones you launch after the deadline.

Most CRA coverage focuses on December 2027, when the full secure-by-design requirements and CE marking obligations arrive. That framing is comfortable, and wrong. You can't report a vulnerability within 24 hours unless you already have the machinery to find it, triage it, and file it. That machinery takes longer than a quarter to build.

What the CRA covers (probably your product)

The regulation's phrase is "products with digital elements," and it's as broad as it sounds: hardware with software in it, plus standalone software itself. Consumer IoT, industrial sensors, routers, mobile apps sold into the EU, the embedded code in a vending machine. If it runs code and it's on the EU market, the default assumption should be that it's covered.

Where your company is based doesn't matter. Like GDPR, the CRA follows the product into the market. A US or UK startup selling smart devices to German customers carries the same obligations as a manufacturer in Munich.

A few categories escape, because they're regulated elsewhere: medical devices, cars, aviation systems, some marine equipment. Open source gets its own treatment — more on that below. Everyone else is on one timeline with two dates that matter: September 11, 2026 for reporting, December 11, 2027 for everything else.

September 11 is the real deadline

Here's the sequence the regulation expects when someone is actively exploiting a hole in your product. An early warning to your national CSIRT within 24 hours of becoming aware. A fuller notification within 72 hours. A final report within 14 days of a corrective fix being available. Severe incidents follow the same pattern with a month for the final report. Everything goes through a new Single Reporting Platform, which routes it to your member state's CSIRT and to ENISA, the EU's cybersecurity agency, simultaneously.

Read that again with a product manager's eyes and the problem is obvious. "Within 24 hours of becoming aware" assumes you become aware. Most small and mid-size device makers have no structured way to learn that a CVE was just published for a library baked into their firmware, no inbox where a security researcher can reach a human, and no internal answer to the question "who decides this counts as actively exploited, and who files?"

This is why the practical SBOM deadline is 2026, not 2027. The software bill of materials — a machine-readable inventory of every component in your product — is formally a 2027 requirement. But you can't monitor dependencies you haven't listed, and you can't meet a 24-hour clock with a triage process that starts from "wait, do we even use that library?" The reporting obligation quietly drags the SBOM work forward a year.

One more uncomfortable detail: the reporting duty covers products already on the market. The device you shipped in 2022 with a vague plan to "revisit security later" is in scope the moment someone starts exploiting it.

What your product needs by the end of 2027

The December 2027 wave is the bigger engineering lift. For products placed on the market from that date, the essential requirements include:

• Shipping without known exploitable vulnerabilities, with a secure default configuration — which among other things ends the era of the universal default password.
• A real update mechanism: security updates delivered over the air where applicable, cryptographically signed, verified on the device, protected against rollback to older vulnerable versions, and resilient enough not to brick the fleet mid-update.
• A machine-readable SBOM, in practice SPDX or CycloneDX, generated as part of the build rather than assembled by hand once a year.
• A coordinated vulnerability disclosure policy with a public way for researchers to report problems — and someone who actually reads what comes in.
• Free security updates for the product's support period — at minimum five years, or the product's expected lifetime if shorter.

Compliance gets stamped with the CE mark, the same mark you already know from electronics, now extended to cover cybersecurity. Most products can self-assess. The "important" classes — routers, firewalls, password managers, smart home hubs with security functions and the like — need a third-party notified body to check the homework. Worth finding out early which bucket your product is in, because notified-body capacity in 2027 is going to be a bottleneck.

The fines, and the small print

Breaching the essential requirements carries fines up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Lesser violations run €10 million or 2%, and misleading the authorities costs up to €5 million or 1%. The percentages are the point — this is GDPR-style arithmetic, designed so that ignoring the rules can never be cheaper than following them.

There are two carve-outs people tend to overread. Micro and small enterprises can't be fined for missing the 24-hour and 72-hour reporting deadlines — but every other obligation still carries full penalties, so this is a grace note, not an exemption. And open-source stewards (foundations and maintainers who develop software without monetizing it) are exempt from fines entirely. The moment that open-source code ships inside your commercial product, though, you're the manufacturer, and its vulnerabilities are your reporting problem.

What to do between now and September

If you sell, or plan to sell, a connected product in the EU, the summer checklist is short and concrete. Inventory what's actually in your products — generate an SBOM from the build, don't reconstruct one from memory. Stand up a vulnerability intake: a security.txt, a monitored mailbox, a disclosure policy a researcher can find. Write the incident runbook and dry-run the 24-hour clock once, on a fake CVE, so the first real run isn't also the rehearsal. And check your product's classification, because it decides whether 2027 means self-assessment or an audit queue.

The hardest item isn't on that list, because it's not a September problem: field-updatable firmware. If your devices can't take a signed update over the air today, retrofitting that is months of work across bootloader, delivery infrastructure, and fleet operations. Teams that start in 2027 will be doing it during the enforcement period instead of before it.

None of this is exotic engineering. Signed updates, dependency tracking, a way for someone to tell you your product is broken — a well-run product team wants these anyway, the same way it wants tests and backups. The CRA just turned "want" into "must" and attached a date. Two dates, actually. The second one gets all the attention. The first one is the deadline.