For connected-product companies selling into Europe, the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) has moved from a policy discussion to an operational reality. Since September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents within tight deadlines. On December 11, 2027, the rest of the regulation applies: essential cybersecurity requirements, vulnerability handling for the support period, conformity assessment and CE marking. Products that cannot demonstrate compliance after that date cannot be placed on the EU market.
For IoT manufacturers, the CRA is especially demanding because it touches hardware, firmware, mobile apps and the cloud back ends that make devices work. This article explains what is already in force, what comes next, how to classify your products, and a phased roadmap to get ready in the roughly thirteen months that remain.
What Is Already in Force, and What Comes Next
The CRA entered into force in December 2024 with staggered application dates. Three matter most for IoT businesses:
- June 11, 2026: provisions on conformity assessment bodies began to apply, so that notified bodies can be designated in time for products that need third-party assessment.
- September 11, 2026: reporting obligations for manufacturers began. According to the European Commission, they apply to actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
- December 11, 2027: the remaining obligations apply, including the essential requirements in Annex I, vulnerability handling throughout the support period, technical documentation, conformity assessment and CE marking.
A point that surprises many teams: the reporting duties apply to products already on the market, regardless of when they were first placed there, as law firm Skadden notes in its September 2026 FAQ. If you sold connected devices in the EU five years ago and they are still in use, an actively exploited vulnerability in them is reportable today.
The Reporting Obligation in Practice
The reporting regime is short, strict and centralized. The Commission’s guidance sets out the timeline:
- Early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
- A fuller notification within 72 hours, with available information on the issue, its nature and corrective or mitigating measures.
- A final report no later than 14 days after a corrective measure is available for an exploited vulnerability, or within one month of the 72-hour notification for a severe incident.
Notifications are submitted once, through ENISA’s Single Reporting Platform, which has been operational since September 11, 2026. They go to the computer security incident response team (CSIRT) of the Member State where the manufacturer has its main establishment, with ENISA receiving them simultaneously except in exceptional circumstances. Manufacturers must also inform affected users and explain mitigation steps, and CSIRTs can notify users directly if a manufacturer does not do so in time.
What 24 hours really demands
A 24-hour clock is unforgiving for organizations where vulnerability information arrives through a support ticket, a researcher’s email or a cloud provider’s alert and then waits for a weekly triage meeting. Meeting it reliably requires:
- A single intake channel for vulnerability reports, published on your website and in product documentation.
- Named reporters, backups and decision-makers, with authority to submit an early warning on incomplete information.
- Registered accounts and tested access to the Single Reporting Platform before you need them.
- Clear internal criteria for “actively exploited” and “severe incident,” so engineers escalate rather than debate.
- Tabletop exercises that simulate a weekend discovery and measure the time to a submitted early warning.
Is Your Product in Scope, and in Which Category?
The CRA covers “products with digital elements”: hardware and software whose intended use includes a direct or indirect data connection to a device or network. Most IoT devices, gateways, companion apps and embedded software fall in scope, as do remote data processing solutions (such as cloud back ends) without which the product cannot perform one of its functions. Some sectors with their own regimes, such as medical devices, motor vehicles and certain aviation and marine equipment, are carved out.
Within scope, the conformity route depends on the product’s category:
- Default products (the large majority) can use self-assessment by the manufacturer.
- Important products, Class I (Annex III) include categories such as routers and modems, and smart home products with security functions like smart door locks, security cameras, baby monitors and alarm systems. Self-assessment is possible only when harmonized standards or certification schemes are applied in full; otherwise third-party assessment is needed.
- Important products, Class II include categories such as firewalls and intrusion detection or prevention systems, and require third-party conformity assessment.
- Critical products (Annex IV), such as smart meter gateways and smartcards, may be subject to European cybersecurity certification.
Classification is a legal judgment with large cost implications, so document your reasoning per product line, involve counsel, and revisit it as the Commission publishes technical descriptions of the categories.
The Standards Gap and How to Work Around It
Harmonized standards give manufacturers a presumption of conformity. The problem is timing. As of September 2026, no CRA harmonized standard had been cited in the Official Journal, according to the independent tracker cyberresilienceact.eu, which also reports a draft Commission amendment that would push some drafting deadlines back by two months to the end of October and end of December 2026. Horizontal standards (the EN 40000 series), vertical standards for certain product types (including the prEN 50770 series) and a batch of ETSI product drafts are in progress.
For Class I products, the absence of cited standards matters directly, because self-assessment depends on them. The practical response is to design against the published drafts and established frameworks now, keep an evidence trail mapping each Annex I requirement to your controls, and monitor Official Journal citations rather than drafting deadlines. If a Class I product may need a notified body, book capacity early; demand will spike as December 2027 approaches.
The CRA does not reward last-minute compliance projects. Reporting is already live, standards are still arriving, and notified-body capacity will be tight. Manufacturers who treat product security as an engineering process now will be the ones still shipping in 2028.
What the Essential Requirements Mean for IoT Engineering
Annex I of the CRA sets out security properties and vulnerability handling requirements. Translated into IoT engineering practice, the most consequential themes are:
Secure by default and by design
- No universal default passwords; unique credentials or forced setup at first use.
- Minimized attack surface: disable unused services, ports and debug interfaces in production builds.
- Protection of data at rest and in transit, with modern cryptography and key management appropriate to the device class.
- Secure boot and integrity protection for firmware and configuration.
- Logging of security-relevant events in a way that respects device constraints and user privacy.
Updates and the support period
Manufacturers must provide security updates throughout a defined support period, which should reflect how long the product is expected to be in use and, in general, be at least five years unless the product is expected to be used for less. For IoT that means a robust over-the-air update mechanism, the ability to deliver security fixes separately from feature updates where feasible, and cloud services that remain available for as long as devices depend on them.
Vulnerability handling
You need a coordinated vulnerability disclosure policy, a software bill of materials (SBOM) for at least top-level dependencies, a process to monitor components for new vulnerabilities, and the ability to ship fixes without undue delay. Open-source components count: their vulnerabilities are your vulnerabilities once they are in your product.
Who Owns CRA Compliance: The Operating Model
Many IoT companies discover that nobody owns product security end to end. Hardware engineering owns the board, a firmware team owns the image, a cloud team owns the back end, and customer support owns the inbox where researchers write. The CRA forces these responsibilities into one accountable structure. The model that works best for most mid-sized manufacturers has three parts:
- A product security incident response team (PSIRT). A small, named group that runs vulnerability intake, triage, CRA reporting and customer advisories. It does not need to be large, but it needs authority and an on-call rota.
- Security champions in each engineering team. Engineers who own threat modeling, secure coding practices and SBOM quality for their component, and who are the PSIRT’s first call during an incident.
- A compliance owner. Usually in quality or regulatory affairs, responsible for classification decisions, technical documentation, declarations of conformity and liaison with notified bodies and market surveillance authorities.
Map these roles to a simple RACI for each CRA obligation and review it with leadership; the regulation’s penalties, which can reach the higher of 15 million euros or 2.5 percent of worldwide annual turnover for breaches of the essential requirements, justify board-level visibility.
Connecting the CRA to other obligations
The CRA rarely arrives alone. Radio equipment sold in the EU has had to meet cybersecurity requirements under the Radio Equipment Directive’s delegated act since August 2025, and those requirements will be superseded by the CRA for in-scope products. Customers that are themselves subject to the NIS2 Directive will push supply-chain security clauses into contracts, and data protection rules continue to apply to any personal data your devices collect. Building one control framework that maps to all of these, rather than separate projects per regulation, saves effort and avoids contradictory evidence.
A Phased Readiness Roadmap
With reporting already live and full application roughly thirteen months away, a pragmatic roadmap has four overlapping phases.
Phase 1 (now): Reporting readiness
- Inventory all products with digital elements on the EU market, including legacy lines and the back-end services they depend on.
- Identify the legal manufacturer and main establishment for each, and therefore the lead CSIRT.
- Stand up the intake channel, escalation matrix and Single Reporting Platform access.
- Run a tabletop exercise and fix the bottlenecks it reveals.
Phase 2 (Q4 2026 to Q1 2027): Classification and gap analysis
- Classify each product line and decide the conformity route.
- Assess each product against Annex I and record gaps with owners and target dates.
- Generate SBOMs in your build pipeline and connect them to vulnerability monitoring.
- Define and publish support periods.
Phase 3 (2027): Remediation and documentation
- Fix design gaps in current products and bake requirements into new product development.
- Build the technical documentation file: risk assessment, design and development records, SBOM, test evidence and update procedures.
- Engage notified bodies where needed and schedule assessments.
- Align suppliers and module vendors contractually on vulnerability notification and update support.
Phase 4 (before December 11, 2027): Conformity and CE marking
- Complete self-assessment or third-party assessment.
- Issue EU declarations of conformity and affix CE marking.
- Transition to steady-state operations: continuous monitoring, regular reporting drills and periodic reassessment.
A Worked Example: A Smart Building Sensor Range
Imagine a generic manufacturer selling wireless occupancy and air-quality sensors, a gateway and a cloud dashboard to facility managers across Europe. The sensors and gateway are default-category products, but the company also sells a smart access controller that may fall into Class I. The cloud dashboard is a remote data processing solution, because devices cannot be configured without it.
In Phase 1, the company discovers that vulnerability reports for older gateway firmware still go to a shared sales inbox. It creates a security intake page and on-call rota, and registers on the Single Reporting Platform. A tabletop exercise simulating an exploited flaw in the gateway’s web interface shows that the team needs two days just to identify affected firmware versions, so it prioritizes an asset inventory linking serial numbers, firmware versions and customers.
In Phase 2, gap analysis shows the sensors ship with a shared default configuration key and the gateway has a debug port enabled in production. Both are fixed in the next hardware revision and, for the gateway, by a firmware update. SBOM generation is added to the CI pipeline. Because harmonized standards are not yet cited, the access controller is designed against current drafts and the company books a notified-body slot as a contingency. By late 2027 the documentation file is complete and the sensor range carries CE marking under the CRA.
Pitfalls to Avoid
- Forgetting the cloud. If a device cannot perform a function without your back end, the back end is part of the compliance picture.
- Treating SBOMs as paperwork. An SBOM nobody monitors does not help you meet a 24-hour reporting window.
- Overlooking legacy products. Reporting already applies to products sold years ago.
- Leaving suppliers out. Module, chipset and software vendors must commit to timely vulnerability information and fixes.
- Waiting for standards. Build against drafts and established practice; adjust when citations arrive.
Conclusion
The Cyber Resilience Act changes the economics of connected products: security becomes a condition of market access, maintained for the life of the product. Reporting obligations are already live, and the full regime arrives in December 2027. IoT manufacturers that act now, starting with reporting readiness and product inventory, then classification, gap remediation and documentation, can turn compliance into a quality advantage instead of a last-minute scramble.
How Hanoi Technology Can Help
Hanoi Technology supports IoT manufacturers with CRA gap assessments, secure firmware and cloud engineering, SBOM pipelines and update infrastructure delivered as projects or dedicated teams.