The CRA is a 2026 problem, not a 2027 one

Ask a product team when the Cyber Resilience Act hits them and most will say December 2027. That is the date the essential requirements, conformity assessment, and CE marking apply, and it is the date every roadmap deck anchors to. It is also the wrong date to plan from.

The CRA entered into force on 10 December 2024, and Article 71 sets a staggered clock, not a single deadline. The provisions on notifying conformity assessment bodies (Chapter IV, Articles 35 to 51) apply from 11 June 2026. The reporting obligations in Article 14 apply from 11 September 2026. Only the main body of the regulation, the Annex I essential requirements and the conformity route to a CE mark, waits until 11 December 2027 (Regulation (EU) 2024/2847, Article 71; European Commission, "The Cyber Resilience Act: Summary of the legislative text", digital-strategy.ec.europa.eu). So the first hard obligation for a manufacturer already in scope lands roughly fifteen months before the date everyone is planning to.

This is not a plea to start early. It is a claim about order. The team that sequences its CRA work backwards from the 2027 CE mark has put the reporting duty last, when the calendar and the operational dependencies both put it first.

What actually switches on in 2026

Article 14 is not a paperwork obligation you bolt on at the end. From 11 September 2026, a manufacturer of a product with digital elements must notify any actively exploited vulnerability in that product, and any severe incident affecting its security, to the CSIRT designated as coordinator for the relevant Member State and to ENISA, through a single reporting platform. The clock is unforgiving: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available for a vulnerability, or within a month for a severe incident (Regulation (EU) 2024/2847, Article 14).

Read the trigger carefully. An "actively exploited vulnerability" is one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without the system owner's permission (Regulation (EU) 2024/2847, Article 3). That is not a hypothetical you handle at leisure. It is a live, dated event that starts a 24-hour timer the moment you become aware of it, and the obligation is in force more than a year before the essential requirements that would have made you capable of noticing.

The knowledge duty arrives before the handling duty

Here is the inversion that the 2027-anchored plan misses. A duty to report within 24 hours of becoming aware is, in practice, a duty to be able to become aware. You cannot file an early warning about an actively exploited vulnerability in your product if you have no channel through which exploitation reaches you, no inventory that tells you which shipped versions contain the affected component, and no triage rule that decides whether an incident is "severe" before the 72-hour window closes.

Every one of those capabilities is described in Annex I, Part II of the same regulation: maintaining a software bill of materials covering at least the top-level dependencies in a machine-readable format, operating a coordinated vulnerability disclosure policy with a contact point for reports, and remediating vulnerabilities without delay through security updates (Regulation (EU) 2024/2847, Annex I, Part II). Those requirements are legally due on 11 December 2027. But the reporting duty that legally binds you from 11 September 2026 is hard to meet reliably without them. The law lets you defer the handling process to 2027; it does not let you defer the consequences once awareness arrives.

So the practical effect of Article 14, for anyone genuinely in scope, is to pull forward the need for parts of the Annex I Part II operating model by fifteen months. Not because the essential requirements apply early, but because the reporting obligation is hard to satisfy reliably without the operational spine those requirements describe.

The objection, and why it does not hold

A careful practitioner will push back here, and the objection is worth taking seriously. Article 14 is narrow. It fires only on actively exploited vulnerabilities and severe incidents, not on the routine backlog of low-severity findings. A well-run product may go a long time without a reportable event. So why not run a thin reporting process from September 2026, keep the real vulnerability-handling build on the 2027 track, and accept the small risk of an early trigger?

Three reasons the thin version is a trap.

First, the rare-event framing gets the risk backwards. The obligation is not burdensome because it fires often. It is dangerous because it fires unpredictably and starts a 24-hour clock you cannot pause to go build capability. The one week you have an actively exploited vulnerability is precisely the week you cannot afford to be assembling an SBOM to work out which customers are affected.

Second, the liability shape is different from a conformity gap, and worse. An incomplete Annex I posture surfaces at assessment, in a room, with a chance to remediate. A missed 24-hour notification is a discrete, dated, externally provable failure. It creates a record that may later matter in supervisory or enforcement discussions, and the reporting trail you build from September 2026 is part of that record. A thin process is not a smaller version of compliance; it is a documented trail of the moments you were not ready.

Third, a reporting process with no handling process behind it is theatre. Being able to submit a form to ENISA within 24 hours is worthless if you cannot answer the form's actual questions: which versions are affected, what the corrective measure is, when it ships. The reporting duty and the handling requirements are one system observed at two moments. You cannot buy the observable half and skip the machine.

Sequence backwards from September 2026

The practical correction is not "do everything now." It is to identify the minimum subset of the 2027 essential requirements that Article 14 makes load-bearing in 2026, and to schedule that subset against the September date rather than the December-2027 one.

That report-readiness minimum is smaller than the full Annex I programme and specific enough to plan:

• A current software bill of materials for each shipped product, at least to top-level dependencies, so that on the day of an exploited vulnerability you can scope impact in hours, not weeks.
• A monitored intake channel and a coordinated vulnerability disclosure policy, so that exploitation and third-party reports actually reach you and start the clock you are accountable to.
• A written severity-and-incident triage rule that can classify an event as reportable inside the 72-hour window without convening a committee.
• A named owner and a rehearsed submission path to the coordinating CSIRT and ENISA, tested against the reporting platform before you need it in anger.

None of that requires the harmonised standards or the conformity route that are still being finalised for 2027. All of it is buildable now, and all of it is a down payment on the 2027 obligations rather than throwaway work. Manufacturers of important products in Annex III Class II have a second reason not to wait: their conformity route generally requires a notified body, and those bodies can only be designated once the Chapter IV machinery applies from 11 June 2026. Assessment capacity is finite, and queues form at deadlines, not before them.

The rule worth keeping

When a regulation applies in stages, the headline date is usually the last one, and the last date is the least useful thing in it for planning. Read the staggered clock instead, and ask which obligation the others depend on. For the CRA, the reporting duty in Article 14 comes first in the calendar and first in the dependency graph: you cannot report what you cannot detect, and you cannot detect without the handling spine the 2027 requirements describe. Plan the work backwards from 11 September 2026, not forwards to 11 December 2027, and the ordering falls out on its own.

If your near-term task is working out which of your products the CRA reaches and what the September 2026 reporting duty actually requires of each, that scoping and cross-referencing is the kind of work ISMS Copilot is built to speed up. For many teams, CE-marking work is a 2027 gate; Article 14 readiness is a 2026 gate. Plan for the earlier one first.

This is practical compliance analysis, not legal advice. Confirm your product's scope and obligations against the regulation itself and, where it matters, with your competent authority or counsel.