Ask most product teams about the EU Cyber Resilience Act and they will quote December 2027, when the regulation applies in full. That date is real, but it is not the first one. On 11 September 2026 — three months from now — the reporting obligations take effect: manufacturers must notify actively exploited vulnerabilities and severe incidents affecting their products, with an early warning within 24 hours and a full notification within 72 hours through the ENISA reporting platform. If you ship software or connected hardware into the EU market, you need a functioning PSIRT process this quarter, not next year.
The CRA (Regulation (EU) 2024/2847) entered into force in December 2024 and is the first horizontal EU law regulating the security of products themselves. It applies to products with digital elements placed on the EU market — firmware, IoT devices, desktop and mobile applications, and commercial software components. Open source gets nuanced treatment through the steward regime, but the moment code is monetized as a product, the obligations attach.
Scope and classification determine your assessment path
Most products fall into the default category and can self-assess conformity. Important products — class I includes things like password managers, VPNs, and operating systems; class II covers items like hypervisors and firewalls — face stricter conformity routes, and critical products stricter still. The first engineering task is boring but essential: inventory every product and module you place on the market and classify it. Everything downstream depends on that list.
The essential requirements read like a secure SDLC
Annex I of the CRA will look familiar to anyone who has built a security development lifecycle:
- ▸No known exploitable vulnerabilities at release: which means vulnerability scanning and a triage gate in CI, with documented risk acceptance for anything waived.
- ▸Secure by default configuration: shipping with hardening as an opt-in is over; the default install must be the safe one.
- ▸Security updates for the support period: at least five years or the expected product lifetime, with security fixes deliverable separately from feature updates — a real architectural constraint for teams that only ship monoliths.
- ▸A machine-readable SBOM: covering at minimum the top-level dependencies, in a format like CycloneDX or SPDX, generated in the build pipeline rather than assembled by hand.
- ▸Coordinated vulnerability disclosure: a published policy, a reachable contact point, and no legal threats against good-faith researchers.
The reporting machinery you need by September
The 24-hour clock starts when you become aware of active exploitation. That presupposes several things most organizations lack: a monitored intake channel, an agreed definition of what counts as actively exploited, a decision-maker who can authorize a regulatory notification outside business hours, and pre-drafted templates. A vulnerability handling process that routes everything through a monthly review meeting will structurally miss the deadline.
CE marking changes release engineering
A compliant release is no longer just a binary and a changelog. It is a technical documentation file, a conformity assessment, and an EU declaration of conformity backing the CE mark. Harmonised standards that grant presumption of conformity are still being drafted, so early movers are aligning to existing work — IEC 62443, ETSI EN 303 645, and their own ISO 27001 SDLC controls — and documenting the mapping.
A roadmap that fits the time remaining:
1. Inventory and classify every product with digital elements you place on the EU market. 2. Wire SBOM generation into CI so every release artifact carries one automatically. 3. Stand up a vulnerability handling process with severity SLAs and a named PSIRT owner. 4. Verify your update channel: signed updates, security patches separable from features. 5. Write the reporting runbook keyed to the 24-hour and 72-hour deadlines and rehearse it once. 6. Start the technical documentation file per product now; retrofitting it in 2027 will hurt.
The strategic view: the CRA converts product security from a differentiator into a market-access requirement, and that reshuffles competitive dynamics in your favor if you move early. Buyers — especially those under NIS2 and DORA pressure themselves — are already asking for SBOMs and support-period commitments in procurement. Teams that can hand over a CRA-shaped documentation pack this year will win deals against competitors still treating December 2027 as a distant abstraction.