EU Cyber Resilience Act 2026 Compliance for IoT: The September Reporting Deadline That Changes Market Access
EU Cyber Resilience Act 2026 Compliance for IoT: The September Reporting Deadline That Changes Market Access
Manufacturers of connected hardware and IoT products face a hard operational clock under the EU Cyber Resilience Act. Regulation (EU) 2024/2847 entered into force on 10 December 2024. Vulnerability and severe-incident reporting obligations under Article 14 apply from 11 September 2026. Full conformity assessment, CE marking and the complete manufacturer regime for products placed on the Union market apply from 11 December 2027.
The distinction matters. September 2026 is not full CE compliance. It is the first continuous, enforceable duty: manufacturers must detect and report actively exploited vulnerabilities and severe security incidents on products already available in the EU. December 2027 is the market-access hard stop for new placements. Design cycles for IoT and embedded hardware routinely run 12–24 months or longer. Roadmaps, secure-by-default architectures, supplier contracts and vulnerability processes that ignore the dual timeline risk redesign costs, market exclusion or administrative fines.
The CRA is a horizontal, product-centric regulation. It covers nearly all “products with digital elements” — hardware or software that can connect, directly or indirectly, to a device or network — when made available on the Union market in the course of a commercial activity. It applies to EU and non-EU manufacturers alike. It complements entity-level rules under NIS2 and product rules under the Radio Equipment Directive, but it is the decisive CE-marking layer for connected products.
timeline title CRA Key Application Dates section 2024 10 Dec 2024 : Entry into force section 2026 11 Jun 2026 : Conformity assessment body notification ~Aug 2026 : Harmonised standards expected 11 Sep 2026 : Article 14 reporting live section 2027 11 Dec 2027 : Full application — CE and main duties
Core technical and process obligations
Annex I requires products to deliver an appropriate level of cybersecurity based on a documented risk assessment. Key controls include:
| Requirement | Practical IoT implication |
|---|---|
| No known exploitable vulnerabilities at placement | Pre-release vuln management |
| Secure by default (incl. secure reset) | No default passwords; locked factory config |
| Addressable security updates; auto-update as default | OTA design with clear opt-out |
| Unauthorised-access protection | Device identity and least privilege |
| Confidentiality and integrity (encryption, secure boot, signed firmware) | Crypto and firmware signing baseline |
| Data minimisation and limited attack surface | Interface hardening |
| Resilience after incidents; minimal impact on other networks | DoS resistance and neighbour-friendly design |
| Security logging and secure permanent data wipe | Telemetry with privacy; clean decommissioning |
Annex I Part II mandates continuous vulnerability handling: a machine-readable SBOM covering at least top-level dependencies; remediation without delay; regular security tests; a coordinated vulnerability disclosure (CVD) policy and public contact; secure, free-of-charge updates (narrow B2B exception); and public disclosure of fixed vulnerabilities with severity and remediation guidance.
Manufacturers must set a support period of at least five years from market placement (narrow shorter-use exception). The end date (month and year) must appear at purchase. Security updates remain available for at least ten years after issuance or the remainder of the support period, whichever is longer. Technical documentation and the EU declaration of conformity are retained for at least ten years after placement or for the support period, whichever is longer. User instructions must cover secure setup, use, decommissioning and the CVD contact.
Staged timelines: reporting first, then CE
From 11 September 2026, Article 14 requires reporting of actively exploited vulnerabilities and severe incidents that impact product security. Ordinary pre-exploitation fixes stay under Annex I processes.
| Stage | Deadline from awareness | Content |
|---|---|---|
| Early warning | 24 hours | Occurrence; whether suspected unlawful or malicious |
| Main notification | 72 hours | Initial assessment, severity, impact, available mitigations |
| Final report | 14 days after corrective measure (exploited vulns); typically within one month of the 72-hour submission for severe incidents | Full description, severity, remediation |
Notifications travel via the single ENISA platform to the CSIRT of the manufacturer’s main establishment and to ENISA. The duty applies regardless of final template status and covers products already on the market.
Full application from 11 December 2027 requires conformity assessment, EU declaration of conformity and CE marking before placement. Series production must remain compliant. National market surveillance authorities can demand documentation, order corrective action, restrict sales or withdraw products.
Conformity assessment routes by risk class
Most products fall into the default category and may self-assess. Important products in Annex III (Class I/II) — routers, operating systems, smart-home security products, connected toys, certain wearables, microprocessors and MCUs with security functions — face stricter routes; a notified body is often required, especially without harmonised standards. Critical products in Annex IV (secure elements, smart-meter gateways, certain hypervisors and container runtimes) always require a notified body.
Harmonised standards are expected in Q3 2026 (industry timing around August). Process readiness cannot wait for final standards. Future EU cybersecurity certification schemes may ease notified-body needs under delegated acts. Notified-body capacity is still ramping after the June 2026 notification window, creating scheduling risk for Class II and critical products.
Duties by economic operator
| Actor | Core duties |
|---|---|
| Manufacturer | Full Annex I + Articles 13/14: risk assessment, secure design, SBOM, support period, conformity, CE, technical file, reporting, user information |
| Authorised representative | Mandated EU-based tasks for non-EU manufacturers |
| Importer | Place only compliant, CE-marked products; verify documentation; cooperate with authorities. Becomes manufacturer if rebranding or substantially modifying |
| Distributor | Verify CE marking and instructions; refuse non-compliant products; cooperate on corrective actions. Same manufacturer escalation if rebranding or modifying |
| Open-source software steward | Article 24 light-touch regime: cybersecurity policy for secure development and vulnerability handling; limited reporting; cooperation with market surveillance. Exempt from administrative fines |
Non-commercial free and open-source software generally falls outside the full manufacturer regime. Commercial integration or monetisation pulls in manufacturer duties and component due diligence.
Supply chain, third-party components and SBOM
Manufacturers must exercise due diligence so third-party and open-source components do not compromise product cybersecurity. Upstream end-of-life is not a defence; the manufacturer’s support window still applies. Contracts need patch SLAs matching or exceeding the product support period, plus notification rights and vendor-exit contingency.
The SBOM floor is machine-readable and commonly used (CycloneDX or SPDX in practice), covering at least top-level dependencies. Continuous matching against vulnerability intelligence is essential to meet the 24-hour awareness window for actively exploited issues. Deeper transitive and firmware coverage is best practice beyond the legal minimum.
SME challenges and practical mitigation
Smaller vendors face notified-body cost and capacity constraints, multi-version support matrices, limited upstream leverage, and the gap between late standards and early reporting. Early product classification avoids over-engineering. Shared secure platforms across SKUs, automated SBOM generation in CI pipelines, continuous vulnerability monitoring, and treating September 2026 reporting readiness as the minimum viable programme — inventory, detection, decision tree, ENISA platform dry-runs and a public security contact — keep costs manageable while protecting market access.
Enforcement and business takeaways
Administrative fines under Article 64 reach €15 million or 2.5 percent of worldwide annual turnover (whichever higher) for breaches of the essential requirements and Articles 13 and 14. Other obligations attract lower ceilings (€10 million / 2 percent or €5 million / 1 percent). Fines sit alongside corrective measures, sales bans and withdrawals. Micro and small enterprises receive limited relief on certain early-warning deadlines; open-source stewards are exempt from administrative fines.
Prioritised readiness checklist:
P0 — before 11 September 2026
- Inventory all EU-facing connected products and standalone components.
- Generate and maintain versioned SBOMs with continuous monitoring for actively exploited vulnerabilities.
- Stand up the Article 14 playbook (24/72/14 hours, roles, platform registration).
- Publish a coordinated vulnerability disclosure policy and public security contact.
- Classify products against Annex III/IV to determine notified-body needs.
P1 — through mid-2027 6. Complete cybersecurity risk assessments and map Annex I Part I controls. 7. Implement secure-by-default configuration and OTA/auto-update architecture. 8. Set and disclose the support-period policy. 9. Build the technical documentation pack and declaration-of-conformity process. 10. Flow patch-duration and notification obligations into supplier contracts.
P2 — by 11 December 2027 11. Complete conformity procedures and affix CE marking on products placed thereafter. 12. Establish series-production change control against CRA requirements. 13. Prepare post-market surveillance response capability. 14. Update importer and distributor agreements.
The CRA turns cybersecurity from a feature into a condition of market access. Firms that treat September 2026 as a live operational deadline — not a distant certification event — will protect both European revenue and the integrity of their product lines. Those that wait for final standards or perfect tooling will face compressed redesign windows, scarce notified-body slots and avoidable regulatory exposure.