On 11 September 2026, one of the EU Cyber Resilience Act’s fastest obligations starts more than a year before most of the regulation. A manufacturer that becomes aware of an actively exploited vulnerability or a severe product-security incident may have only 24 hours to send an early warning and 72 hours to provide a fuller notification.
The practical response is not a new legal-policy PDF. It is an incident lane that can identify an in-scope product, decide whether a CRA trigger is met, preserve the awareness time, assemble the minimum report, and keep engineering, legal, support, and leadership working from one record.
This is an operational guide, not legal advice. Scope, manufacturer status, product history, other notification regimes, and the facts of an incident can change the answer. Confirm your interpretation with qualified counsel and the relevant CSIRT.
What starts on 11 September 2026
The CRA entered into force in December 2024. Most obligations apply from 11 December 2027, but Article 14 reporting starts on 11 September 2026. The rule covers manufacturers of products with digital elements made available on the EU market. The Commission describes those products broadly as hardware and software whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network.
The European Commission’s reporting page identifies two mandatory events: an actively exploited vulnerability contained in the product and a severe incident affecting the product’s security. Reporting is made once through ENISA’s Single Reporting Platform, which routes it to the appropriate national CSIRT and ENISA.
This early date matters for legacy products. The Commission’s CRA legislative summary says reporting applies to all products with digital elements made available on the EU market, including products placed there before the main December 2027 application date. A team cannot safely postpone its incident lane until the conformity and CE-marking programme is complete.
Decide whether your product and role are in scope
Start with a product register, not a company-wide yes/no label. One business can sell an in-scope desktop application, distribute a connected device, operate a service that needs separate analysis, and contribute to open-source software under a different CRA regime.
| Question | Evidence to keep | Owner |
|---|---|---|
| Is this hardware or software with a direct or indirect data connection? | Architecture, intended use, product description | Product + legal |
| Was it supplied in a commercial activity on the EU market? | Contracts, channels, release and territory records | Commercial operations |
| Whose name or trademark is on the product? | Packaging, listing, licence, declaration records | Legal + product |
| Is a hosted function a remote data-processing solution integral to the product? | Dependency map and service responsibility | Engineering + legal |
| Does an exclusion or sector-specific rule apply? | Written scope assessment and source | Qualified counsel |
A developer is not automatically the CRA manufacturer; generally, the manufacturer is the person or organisation placing the product on the market under its name or trademark. Conversely, outsourcing development does not necessarily outsource manufacturer responsibility. Pure services and free/open-source arrangements need careful, fact-specific analysis. The Commission’s July 2026 implementation guidance specifically addresses remote data processing, open source, support periods, substantial modification, and reporting.
For every product or family, record the manufacturer entity, EU main establishment or authorised representative, responsible CSIRT, EU countries where it is available, supported versions, components, and named reporting deputies. That information is difficult to reconstruct at hour 18.
Separate the two reporting triggers
An unpatched vulnerability is not automatically reportable under Article 14. The vulnerability trigger requires reliable evidence that a malicious actor exploited it in a system without the system owner’s permission. A proof of concept, scanner alert, severity score, or researcher report can demand urgent investigation without, on its own, proving active exploitation.
The incident trigger is different. An incident is severe where it negatively affects, or is capable of negatively affecting, the product’s protection of the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or where it has led, or could lead, to malicious code being introduced or executed in the product or a user’s systems. Apply the exact legal criteria to documented facts.
- Security signal: capture the source, time received, affected product/version, and original evidence.
- Product match: confirm that the vulnerable component or incident is in an in-scope product made available in the EU.
- Trigger assessment: test active exploitation and severe-incident criteria separately. Record yes, no, or unknown with reasons.
- Awareness decision: timestamp when reliable evidence made the organisation aware; do not silently reset it as the issue escalates.
- Parallel action: contain and fix the problem while reporting work proceeds. A report never replaces remediation or user protection.
Use a conservative escalation threshold internally: uncertainty should reach the reporting team quickly. That does not mean reporting every bug. It means the people authorised to apply the legal test receive the evidence before the statutory clock is consumed by hand-offs.
Run the 24/72/final-report clock
The official ENISA SRP FAQ, updated 31 August 2026, makes the sequence concrete:
- Within 24 hours of awareness: submit the early warning without undue delay. Identify the manufacturer and product, notification type, title, and—where available or required—the relevant Member States or whether malicious action is suspected.
- Within 72 hours of awareness: update the same record with general information, an initial assessment, measures already taken, actions users can take, and any sensitivity assessment. It is 72 hours total, not 72 hours after the early warning.
- For an actively exploited vulnerability: submit the final report no later than 14 days after a corrective or mitigating measure becomes available.
- For a severe incident: submit the final report within one month after the 72-hour incident notification.
The 24-hour report is intentionally an early warning. Do not wait for attribution, a complete blast radius, or root cause. Clearly label confirmed facts, working hypotheses, and unknowns. Update the same notification as evidence changes.
As of 3 September, ENISA says the public SRP URL will be communicated before launch. Assigned representatives authenticate with a personal EU Login using two-factor authentication. One Primary AR and up to 20 Secondary ARs can represent a manufacturer. ENISA advises registering when a report is needed; validation runs in parallel and does not stop submission. Because operational guidance is changing near launch, verify the current SRP page during every event.
Build one evidence record before automating
A ticket scattered across chat, email, a vulnerability scanner, and a legal spreadsheet will not reliably support three deadlines. Create a restricted case record with stable identifiers and an append-only decision log.
cra_case
case_id + notification_type
manufacturer + product + affected_versions
signal_received_at + awareness_at + rationale
evidence_of_exploitation + severity_test
eu_markets + csirt_coordinator
containment + user_mitigation + corrective_measure
confirmed_facts + hypotheses + unknowns
sensitivity + disclosure_decision
reporter + approver + deputies
24h_due + 72h_due + final_due
srp_reference + submission_receipts + change_logProtect this record as sensitive security data. Grant access by role, log changes, preserve submitted payloads and receipts, and define retention with counsel. Do not paste exploit details into broad channels or a general-purpose AI assistant. The system should calculate deadlines from the recorded awareness time, show timezone, and page a deputy if an owner does not acknowledge.
Design the workflow around decisions, not forms
ENISA lists the reporting fields, but completing a form is the last mile. The real workflow must collect reliable inputs under pressure.
- Intake: security, support, researchers, monitoring, suppliers, and customers can open one high-priority case.
- Triage: product and component ownership are resolved against a maintained inventory or software bill of materials.
- Decision: security supplies evidence; legal/compliance applies scope and trigger tests; an incident lead owns the clock.
- Submission: two trained representatives can access EU Login and the SRP. The approver reviews the exact payload, not a summary.
- Response: engineering, support, and communications use approved facts and mitigations; disclosure stays coordinated.
- Closure: the final report, patch evidence, customer action, submission receipts, and post-incident changes remain linked.
Automate reminders, product lookups, deadline calculation, required-field checks, and evidence snapshots. Keep the actual report decision and external submission under accountable human control. ENISA currently says no API will be available at launch, so design a human submission step instead of brittle browser automation.
CRA reporting may coexist with GDPR personal-data-breach notification, NIS2 incident reporting, customer contracts, insurance terms, sector rules, or non-EU obligations. Build one incident fact base with separate decision lanes and clocks; never assume an SRP submission automatically satisfies another regime.
Run a 90-minute tabletop before launch
Use a scenario involving a third-party library in a supported EU product, credible exploitation evidence arriving late on Friday, uncertain affected versions, and a mitigation that may break one customer integration.
- Start the clock when the evidence reaches the chosen monitoring channel.
- Locate manufacturer, product, EU-market, version, component, and CSIRT data.
- Draft the 24-hour payload using only what is known.
- Record unknowns and owners for the 72-hour update.
- Test the Primary AR’s absence and the Secondary AR hand-off.
- Prepare a safe user mitigation without exposing exploit-enabling detail.
- Capture where the runbook stalled, then assign a dated fix.
Measure time to triage, time to an awareness decision, missing product data, approval latency, and whether a deputy can complete the workflow. The useful outcome is not a polished slide deck. It is proof that a real team can submit a factual early warning inside 24 hours without stopping containment.
Frequently asked questions
When do CRA incident-reporting obligations start?
They apply from 11 September 2026. Most other CRA obligations apply from 11 December 2027.
Does the reporting rule cover products sold before December 2027?
Yes. Commission guidance says reporting applies to products with digital elements already made available on the EU market, including products placed there before 11 December 2027. Confirm that your role and product are within scope.
Must every software vulnerability be reported?
No. Mandatory vulnerability reporting concerns an actively exploited vulnerability for which there is reliable evidence of unauthorised malicious exploitation. Severe product-security incidents are a separate trigger. Other vulnerabilities still require appropriate handling.
Is the 72-hour deadline counted after the first report?
No. Both 24 and 72 hours are measured from awareness. The second stage is effectively no more than 48 hours after an on-time early warning.
Can the report wait until root cause is known?
No. The early warning is meant to be submitted with incomplete information. Separate confirmed facts from hypotheses, state unknowns, and update the record.
Can we integrate directly with an ENISA API?
ENISA’s 31 August FAQ says no API will be provided at the initial stage. Automate internal preparation and validation, but keep a tested human SRP submission step.
Make the first 24 hours reproducible
The CRA deadline exposes an operating-system problem: product ownership, component evidence, EU-market data, incident decisions, and authorised reporting cannot live in separate silos. A compact case record, a named decision team, two working reporter accounts, and one tested scenario are a stronger starting point than a hundred-page compliance manual.
Rendframe can map the product-security workflow, connect component and product records, build controlled incident tooling, and test the hand-offs. See our production-readiness checklist, review product engineering services, or bring us one anonymised incident timeline for a focused workflow review.