The EU Cyber Resilience Act Deadline Is Coming: A Product Team Checklist for IoT Security

Picture a normal Tuesday morning. A security researcher emails your support inbox to say that attackers are using a flaw in your gateway's web interface. If that gateway is sold in Europe, your company now has 24 hours to tell the regulators. The deadline is not for fixing the problem, only for reporting it.

This is no longer a future scenario. Since September 11, 2026, the EU Cyber Resilience Act (CRA) has required every manufacturer of connected products sold in the EU to report actively exploited vulnerabilities and severe security incidents on that clock. The rest of the law, including secure-by-design rules, software bills of materials, and CE marking, applies from December 11, 2027 (FOSSA).

For a hardware team, the 14 months that remain are about one product cycle, so the work you plan this quarter decides whether your devices can still be sold in Europe in 2028. According to Maggie Nelson, Head of People and Operations at Court Case Finder, the hard part is rarely the law itself. "Most of the companies we talk to have a security policy. Far fewer can tell you, today, which firmware version is running on which device and who gets the phone call when something breaks. The CRA is really asking for that second thing."

This guide skips the legal summary. It takes each CRA obligation, from incident reporting and secure updates to component tracking and network exposure, and turns it into tasks that product managers, embedded engineers and system architects can own, track and close.

Why US Teams Can't Treat This as a European Problem

The CRA follows the product, not the company. If a smart camera, gateway, or industrial sensor is sold in the EU, the manufacturer carries the obligations, wherever its engineers sit. Importers and distributors must also check for CE marking and documentation, so your European channel partners will start asking for proof well before 2027.

The idea should not feel foreign to US teams. Washington has been pushing the same shift for years, without the fines. "Ensuring that software manufacturers integrate security into the earliest phases of design for their products is critical to building a secure and resilient technology ecosystem," said Jen Easterly, former Director of the Cybersecurity and Infrastructure Security Agency (CISA), when the agency published its Secure by Design principles. The CRA turns that advice into a condition for market access.

The fines are set high on purpose. Breaking the essential security requirements or the reporting duties can cost up to €15 million or 2.5% of global annual turnover, whichever is higher (Regulation (EU) 2024/2847, Article 64). For most companies, though, the bigger risk is simpler: a product without a CE mark can't be sold in a market of 450 million people.

Many teams are not ready. In ENISA's first survey of small and medium businesses on the CRA, only 66% of respondents had heard of the law before taking part. Incident response and product lifecycle management scored lowest of all areas assessed (ENISA). Those are exactly the two capabilities the CRA now requires.

Step 1: Make the 24-Hour Reporting Rule Workable

The reporting rule is live now, so it comes first. Under Article 14, the clock starts when you become aware of the problem, not when you finish investigating it. The timeline looks like this:

• 24 hours: an early warning to ENISA and your coordinating national CSIRT (the EU's computer security incident response teams), through the Single Reporting Platform.
• 72 hours: a fuller notification describing the product, the exploit, and any fixes available.
• 14 days after a fix ships: a final report for an exploited vulnerability. For a severe incident, the final report is due within one month.

ENISA opened the platform on September 11, 2026. "The streamlined reporting and sharing of information on actively exploited vulnerabilities and severe incidents helps to build a more resilient Digital Single Market," said Juhan Lepassaar, Executive Director of the EU Agency for Cybersecurity (ENISA). One practical detail matters here: the first version is web-only, with no API, so someone on your team must know how to file a report by hand.

You also have to tell affected users what happened and what they should do. None of this works if the first hours are spent finding out who owns the problem. These are the tasks to assign now:

• Product manager: build a list of every product sold in the EU, including older models still in the field. Products shipped in 2022 are in scope for reporting too.
• Security lead: write a one-page rule for what counts as "actively exploited" or "severe," and who makes that call at 2 a.m.
• Security lead: register on the Single Reporting Platform and run a test submission before you need it.
• Support and legal: prepare customer notice templates, so day one is not spent writing from scratch.
• Whole team: run a tabletop exercise built on a real-looking scenario, such as an exploited flaw in your gateway's web interface.

Step 2: Build an Update Path You Can Trust for Years

Reporting a flaw is only useful if you can fix it. The CRA requires security updates for a defined support period, which is generally at least five years, delivered free and without undue delay. Updates must also be checked for integrity before they install. For a sensor designed to run for 12 years, that is a long promise, so it needs to be built into the hardware now.

Embedded engineers should own the device side:

• Secure boot, so the device only runs firmware you have signed.
• An A/B partition or similar rollback plan, so a failed update doesn't turn a device into a brick.
• A version check that blocks downgrades to older, vulnerable firmware.

System architects should own the delivery side:

• Store signing keys in a hardware security module, never on a build server or a laptop.
• Plan for devices that connect rarely, run on batteries, or sit behind customer firewalls.
• Log which version every device runs, so you can answer "who is affected?" in minutes.

Product managers should write the support period into the product's documentation and price it into the business case. Five years of patches is a cost that the roadmap should show.

Step 3: Know What Is Inside Every Device

You can't report a vulnerability in a library you don't know you ship. That is why the CRA asks for a software bill of materials (SBOM), a machine-readable list of every component, library, and version inside a product. It is also what makes the 24-hour deadline possible in practice.

The risk is real. Claroty's research found more than 111,000 operational technology devices carrying known exploited vulnerabilities across manufacturing, logistics, and natural resources, and 68% of those flaws are linked to active ransomware groups (Swif.ai, citing Claroty). Attackers already know which components are weak. The question is whether you know you ship them.

Here is how to split the work:

• Embedded engineers: generate an SBOM automatically in every build, in a standard format such as SPDX or CycloneDX. Include the vendor SDKs and binary blobs, not just open-source code.
• Security lead: match each SBOM against vulnerability feeds every day, so a new alert points to the products it affects.
• Security lead: publish a coordinated vulnerability disclosure policy and a security contact, so researchers can reach you before attackers do.
• Procurement: ask chipset and module suppliers for their own SBOMs and support dates. Their end of life becomes your problem.

Step 4: Close the Doors on the Device and in Your Own Workspace

The CRA asks for products that are secure by default, with a small attack surface and protection against unauthorized access. On the device, the tasks are familiar but often skipped:

• Embedded engineers: remove shared factory passwords and give each device unique credentials, or force the user to set them on first use.
• Embedded engineers: close debug ports, Telnet, and unused services before shipping, not after the first pentest.
• System architects: encrypt data in transit and at rest, and make sure devices only talk to the endpoints they need.

Most CRA guides stop at the device. Yet many IoT breaches start somewhere else: in the shared drives, code repositories, ticket systems, and chat tools where the product is built. These workspaces hold the most valuable things a team owns, including signing keys, admin credentials, SBOMs, and reports of unfixed bugs.

This is a common path. Verizon's 2025 Data Breach Investigations Report found that stolen or misused credentials were the first step in 22% of breaches, and that third parties were involved in 30%, double the year before. "Businesses need to invest in robust security measures, including strong password policies, timely patching of vulnerabilities, and comprehensive security awareness training for employees," said Chris Novak, Vice President of Global Cybersecurity Solutions at Verizon Business.

Two cases show the cost. In 2021, attackers reached live feeds from about 150,000 Verkada security cameras using a super admin login they found exposed online (CBS News). In 2023, a ransomware gang leaked MSI's firmware signing keys, including Intel Boot Guard keys, which weakened protections on many devices that could not easily be fixed (Help Net Security). In both cases, the products were only as safe as the workspace behind them.

For Nelson, this is where many teams misjudge the risk. "A leaked signing key or an exposed admin password is not an IT incident anymore. It is a product incident," she says. "If someone can push firmware to your fleet, every device you have sold is now part of the breach."

This matters for compliance too. Under Article 14, a severe incident includes one that can lead to malicious code running on the product. A compromised build server or stolen key can therefore start the same 24-hour clock as a flaw in the device itself.

The workspace tasks are simple, but they need an owner:

• IT and security: give access to signing keys, release pipelines and vulnerability tickets only to people who need it, and review that list every quarter.
• IT and security: require phishing-resistant multi-factor authentication for code repositories, cloud consoles, and device management portals.
• Engineering managers: scan repositories and shared documents for secrets, such as API keys, passwords, and private certificates.
• Security lead: keep logs that show who accessed what, so you can tell regulators within hours whether a workspace breach reached the product.

Final Thoughts

The CRA does not ask IoT teams to invent anything new. It asks them to prove they know what they ship, can fix it for years, and can tell the truth quickly when something goes wrong. Those are habits of good engineering, now written into law.

The teams that start now will treat December 2027 as a normal release date. The ones that wait will spend 2027 doing redesigns under pressure. And the checklist has to reach beyond the device, as Nelson points out: "Teams spend months hardening the device and then keep the keys to it in a shared folder that half the company can open. Attackers don't need to break your encryption if they can log in as your engineer."