The Cyber Resilience Act is already in force. The first hard deadline that touches engineering is 11 September 2026, when reporting duties for actively exploited vulnerabilities and severe incidents begin. Here is what to build now, before the clock starts, so the reporting obligation lands on a system that already works.
What is the September 2026 CRA deadline, really?
The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024, and its obligations phase in over three years. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents to their coordinating national CSIRT and to ENISA. The broader CE-marking and conformity duties follow on 11 December 2027.
- ▸Three milestones matter: entry into force in December 2024, reporting duties from 11 September 2026, and full application from 11 December 2027 (conformity assessment bodies are notified from 11 June 2026).
- ▸September 2026 is the milestone that forces a working reporting pipeline and a monitored intake channel to exist now, not on paper.
- ▸The reporting obligation falls primarily on the manufacturer, and it runs through a single reporting platform that ENISA operates and national CSIRTs connect to, so you cannot satisfy it with an ad hoc email to a regulator.
- ▸The phasing is deliberate: it gives manufacturers time to build vulnerability handling and disclosure before the heavier conformity assessment and CE-marking machinery becomes mandatory.
- ▸For the strategic framing, see The Cyber Resilience Act Countdown: September 2026 Is the Real Deadline.
Which products count as "products with digital elements"?
A product with digital elements is any hardware or software with a direct or indirect data connection to a device or network, together with its remote data-processing solutions. That sweeps in firmware, mobile and desktop apps, IoT devices, commercially supplied libraries, and connected industrial gear. Genuinely non-commercial open source and some sector-regulated products are excluded.
- ▸In scope: connected consumer and enterprise devices, embedded firmware, commercial software, and components placed on the market for profit.
- ▸Out of scope: products already covered by sectoral law such as medical devices, motor vehicles, and civil aviation, plus open source developed outside a commercial activity.
- ▸Firmware and device identity carry their own engineering weight: Device Identity and Firmware Supply Chain: Securing the IoT Edge in 2026.
What must an SBOM contain under the CRA?
The CRA requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies of the product. In practice that means generating an SBOM at build time, refreshing it every release, keeping it as part of the technical documentation, and being able to hand it to authorities on request.
- ▸Format: SPDX or CycloneDX, generated in CI rather than assembled by hand.
- ▸Depth: top-level dependencies are the legal floor; deeper transitive graphs let you answer "are we affected?" in minutes when the next widely used library is compromised.
- ▸Pair the SBOM with build provenance so you can prove what you shipped, not just what you declared: Provenance You Can Prove: SLSA, Sigstore, and Policy-as-Code CI/CD.
- ▸Dependencies remain the dominant risk surface, so treat the SBOM as a query target for the next compromised library, not a compliance PDF.
- ▸Full SBOM and CRA depth: The Software Supply Chain in 2026: SBOMs, Provenance, and the CRA Reckoning.
How does CRA vulnerability handling and disclosure work?
Annex I Part II makes vulnerability handling a product requirement, not a nicety. You must identify and document components through the SBOM, remediate vulnerabilities without delay, run regular security testing, publish a coordinated vulnerability disclosure policy with a contact address, and distribute free security updates across the defined support period.
- ▸Support period: at least five years by default, or the product's expected lifetime if that is shorter.
- ▸Disclosure policy: a public contact (a security.txt-style address works) and a documented intake-to-fix process.
- ▸Update mechanism: secure, signed, and ideally automatic delivery of patches, with a way to notify users.
- ▸Building this early is far cheaper than retrofitting it under deadline pressure, and a coordinated disclosure process is expected regardless of product class.
What are the CRA incident and vulnerability reporting clocks?
For an actively exploited vulnerability or a severe incident, the CRA sets a staged clock: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days for vulnerabilities or one month for incidents. Reports flow through a single ENISA platform to the coordinating CSIRT.
- ▸24 hours: early warning to the coordinating CSIRT and ENISA.
- ▸72 hours: notification with the detail known so far, including any corrective or mitigating measures taken.
- ▸14 days or one month: final report once a corrective measure is available.
- ▸The clock starts when you become aware, so the hard part is detection and internal escalation, not the paperwork; instrument telemetry and a clear on-call path so awareness is timestamped rather than argued about after the fact.
- ▸These clocks fail without rehearsed runbooks and a clear on-call owner: Incident Response Playbooks That Teams Actually Use.
Do you need a third-party assessment or can you self-certify?
Most products self-assess against the essential requirements and affix the CE mark on that basis. Products classed as important (Annex III, Class I and Class II) and critical products face stricter routes, applying harmonized standards or third-party conformity assessment, and for some critical categories a European cybersecurity certification.
- ▸Default class: internal self-assessment, technical documentation, and CE marking.
- ▸Important Class II and critical products: third-party conformity assessment or full harmonized-standard conformity, with harmonized standards still being finalized as the deadline approaches.
- ▸Technical documentation must be drawn up before placing the product on the market and kept available to authorities for ten years after, so version it alongside the code it describes rather than treating it as a one-off deliverable.
- ▸Importers and distributors carry their own duties: they must verify that the manufacturer completed conformity assessment, that the CE marking is present, and that documentation and contact details ship with the product.
- ▸Penalties for breaching the essential requirements reach up to 15 million euro or 2.5 percent of total worldwide annual turnover, whichever is higher.
What should you ship before September 2026?
Treat the deadline as a backlog, not a policy binder. Before the reporting clock starts you want automated SBOM generation, a live vulnerability intake channel, a triage-to-patch process with SLAs, signed update delivery, and a reporting runbook mapped to the 24- and 72-hour duties. The rest can follow toward the 2027 CE deadline.
- ▸SBOM in CI (SPDX or CycloneDX) produced per release.
- ▸Monitored disclosure channel and a public coordinated-disclosure policy.
- ▸Vulnerability triage SLAs and a repeatable patch pipeline.
- ▸Signed, ideally automatic updates across the whole support period.
- ▸Reporting runbook wired to the ENISA and CSIRT timelines.
- ▸Map all of this against NIS2, DORA and the CRA together in our hub: EU Cyber Compliance for Engineers: NIS2, DORA and the Cyber Resilience Act.
How TuniCyberLabs helps
We stand up the CRA machinery that must exist before the reporting clock starts: SBOM pipelines in CI, a coordinated-disclosure intake, vulnerability triage SLAs, signed-update delivery, and reporting runbooks mapped to the 24- and 72-hour duties, plus the technical documentation your conformity route requires. See our security and compliance services.
Start with a CRA readiness review and leave knowing exactly what to ship before 11 September 2026.