Europe's Cyber Resilience Act is about to produce an unusual compliance test: the reporting clock starts before most of the product rulebook. From September 11, manufacturers must notify certain actively exploited vulnerabilities and severe security incidents affecting products with digital elements. The regulation generally applies from December 11, 2027. That gap changes what readiness means today.
The immediate bottleneck is not proving that every product already satisfies the later secure-design regime. It is knowing when the organisation became aware, which product and version are affected, who owns the decision and who can file through the European reporting system. A software bill of materials can make those answers faster, but possession of an SBOM is neither the legal trigger nor a substitute for an operating process.
The calendar creates a two-speed regulation
The EUR-Lex summary of Regulation 2024/2847 states the sequence plainly: general application begins on December 11, 2027, while reporting on actively exploited vulnerabilities and severe incidents begins on September 11, 2026. Conformity-body notification began even earlier, in June 2026. Companies therefore face different obligations at different dates, not one all-at-once compliance event.
This distinction matters for budgets and claims. A September filing does not certify that a product meets every requirement due in 2027. Conversely, postponing all CRA work until the later date leaves a current reporting exposure. The European Commission's July implementation guidance reinforces that the reporting phase precedes wider technical compliance.
The scope is also not limited to newly launched products. ENISA's current guidance says Article 14 reporting can apply to in-scope products placed on the market before December 2027 when the manufacturer becomes aware of a reportable event after September 11. A company needs an inventory of supported products, not merely its next release plan.
Awareness is now an operational timestamp
The trigger is narrower than every discovered flaw. The Commission's reporting page identifies two categories: an actively exploited vulnerability, for which there is reliable evidence of malicious exploitation, and a severe incident affecting product security. Once the manufacturer becomes aware, an early warning is due without undue delay and within 24 hours; a fuller notification follows within 72 hours.
The staged design recognises that complete forensics rarely exist on day one. ENISA's field-by-field FAQ requires basic identifiers at the early-warning stage, including a title, summary, manufacturer, product name, product version and awareness time. Many technical details are optional initially or become required later. For an actively exploited vulnerability, a CVE identifier is optional at 24 hours.
That lowers the information threshold, but makes the awareness timestamp consequential. Security operations, product teams and counsel need an agreed method to record when reliable evidence crossed the threshold. If every alert is immediately labelled reportable, noise overwhelms the process. If the decision is deferred until root-cause analysis is complete, the statutory clock may already have expired.
A product owner matters more than a perfect inventory
A workable flow begins with ownership. The detection team must reach someone who can connect a technical signal to a commercial product and version. That owner must know whether the product is available in the EU, which legal manufacturer is responsible and which representative can submit. The compliance team then needs a durable record of the decision and the facts available at each stage.
The reporting channel is the ENISA Single Reporting Platform, which routes one submission to the relevant national CSIRT and ENISA. According to the ENISA operational FAQ, assigned representatives use personal EU Login accounts with multifactor authentication. One primary representative and up to 20 secondary representatives can be associated with a manufacturer. Validation can proceed alongside reporting.
There is a practical wrinkle for automation plans: ENISA says the initial platform release will not provide an API. Internal detection, ticketing and evidence collection can be automated, but the final submission starts as an interface task. Firms should design for a named human fallback, access continuity and time-zone coverage instead of assuming a machine-to-machine connection will exist on launch day.
Supplier visibility extends beyond an SBOM file
The Next Web's original report focuses on the difficulty of connecting supplier software to the finished product. That is a real operational problem. A component alert has little regulatory value if a manufacturer cannot determine which shipped models contain the affected version or whether the component changed after an inventory was generated.
An accurate, current SBOM can shorten that search. It can map components and dependencies to releases, support queries across product versions and give suppliers a common evidence format. But the CRA's September 11 reporting requirement should not be restated as a blanket legal command to possess a particular SBOM by that date. The official early-warning fields specify product and event information; they do not turn one document format into the trigger.
The stronger control is a maintained chain of evidence: supplier notice, component identity, build or firmware version, affected commercial product, support status, EU availability and named owner. An SBOM may anchor several links. Contractual escalation, source analysis, asset data and release records may supply others. A stale inventory can create confidence without speed.
The first filings will expose process debt
Mature incident-response organisations may not need a large new technology purchase. The lighter 24-hour notice, one-stop platform and parallel representative validation are genuine burden reducers. The unresolved risk is cross-functional latency: an alert can wait in a supplier inbox, a product can lack a legal owner, or the only registered reporter can be unavailable.
A useful readiness exercise follows the clock. Start with a credible third-party exploitation notice and measure the time to identify affected products, classify the event, preserve the awareness decision, reach an authorised representative and assemble the required early-warning fields. Then continue to the 72-hour assessment and final-report evidence. The result should show elapsed time and missing ownership, not just produce a policy document.
The first months of SRP operation will provide better evidence than vendor forecasts: how national CSIRTs interpret borderline cases, which fields cause delays and whether ENISA adds an API. Until then, investors and operators should distinguish two claims. A company may be preparing its products for 2027, yet still be slow at reporting in 2026; another may have a disciplined incident flow without claiming that its entire catalogue is already CRA-compliant. The 24-hour clock will reveal the difference.