What changed on September 11
The practical CRA milestone is narrow and immediate. From September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of products with digital elements. The European Commission says the early warning is due within 24 hours of awareness and the fuller notification within 72 hours. ENISA's Single Reporting Platform is the one-submit route to the relevant CSIRT and ENISA.
This is not the date when every CRA product requirement begins. The broader regime generally applies from December 11, 2027. Mixing those dates creates two bad outcomes: teams may postpone the live reporting duty, or they may treat every unfinished 2027 readiness item as an immediate incident-reporting blocker. The operational response needs a dedicated clock and decision path now.
The Commission describes final reports differently for the two lanes. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure is available. For a severe incident, it is due within one month after the 72-hour notification. Qualified counsel must verify the applicable rule and any current guidance for the specific case; an internal workflow should store the rule it used rather than rely on a hard-coded sentence.
The early warning can be timely and honest while root cause, full affected population, and permanent remediation remain unknown.
The hardest word in the clock is “aware.” Tickets, vendor emails, telemetry, customer reports, public exploitation evidence, and researcher disclosures arrive in different systems and reach people with different roles. Operations should not let an AI system choose the legal trigger. It should preserve candidate awareness events, route them immediately, and let the qualified decision owner designate the trigger with a timestamp and reason.
Run three tracks from one approved awareness record
Candidate signal received
|
v
Evidence freeze + candidate awareness timeline
|
+----------------+----------------+
| | |
v v v
Product scope Technical facts Authority readiness
and legal role and containment SRP access + backup
| | |
+----------------+----------------+
|
v
Qualified reportability gate
|
+--------------+--------------+
v v
24-hour early warning documented non-report decision
|
v
72-hour notification -> final report -> closure evidenceThe first track determines what the signal belongs to. Join it to a product register that names versions, the legal manufacturer or potential open-source steward, EU availability, support status, third-party components, and accountable owner. A CVE alone is not the join key. The same component may be exploitable in one product configuration, unreachable in another, and supplied under different legal roles.
The second track establishes technical facts without waiting for perfect certainty. Record exploit observations, affected interfaces, evidence provenance, versions tested, telemetry coverage, customer impact, containment, and mitigation. Separate confirmed facts from hypotheses. A missing log is an observability gap; it is not proof that exploitation did not occur.
The third track keeps submission authority ready. ENISA guidance now includes Assigned Representative registration, notification submission and update, interface functions, and particularly exceptional circumstances. Name a primary and backup representative, test access without submitting a fake case, maintain the required organization and product identifiers, and document the internal approval-to-submission handoff. A draft sitting in a ticket is not a report.
| Stage | Minimum reliable output | Human gate |
|---|
| Intake | Immutable evidence list and candidate awareness times | Incident commander accepts ownership |
| Scope | Product/version/legal-role matrix with gaps | Legal/Compliance and product owner decide scope |
| 24 hours | Early-warning payload, unknowns, evidence IDs, approved hash | Product Security + Legal approve; representative submits |
| 72 hours | Reconciled notification showing deltas from early warning | Same qualified release gate |
| Final | Root cause, affected population, corrective action, residual risk | Accountable owners approve exact record |
| Closure | Platform receipts, communications, retained evidence, improvements | Incident commander verifies completion |
Keep the AI assistant inside an evidence-preparation boundary
An approved AI tool can accelerate mechanical work: normalize timestamps, compare product identifiers, build a contradiction register, calculate deadlines from an approved trigger, draft field mappings, and show changes between the 24-hour and 72-hour records. Those are reversible preparation steps. It should not determine manufacturer status, active exploitation, incident severity, legal scope, disclosure recipients, or release language.
Every generated statement needs a source ID. Require the assistant to output UNKNOWN when evidence is missing and to preserve conflicting accounts. Store the prompt, model and version, input manifest, output, reviewer decisions, approved payload hash, and submission receipt. Do not send exploit details, personal data, privileged communications, customer secrets, or controlled technical information to an AI service unless the environment and use are explicitly approved.
Model facts, decisions, and submissions as separate records
A fact record says what an artifact supports: for example, a server log contains a request pattern at a specific time, or a build manifest places a component version in a product release. A decision record says what an authorized reviewer concluded from those facts: the approved awareness trigger, product scope, reportability, or communication path. A submission record says exactly what was sent, by whom, through which account, when, and with what acknowledgement. Combining all three into one ticket comment makes later corrections impossible to audit.
Give every fact an effective time and a last-verified time. A product version may be in scope at 10:00 and superseded by a corrected inventory at 14:00. Never rewrite the old row; add a new version and link the supersession. Give every decision an owner, rationale, conditions, and expiry. A preliminary non-report decision should reopen when new exploitation evidence, a changed product join, or contrary legal guidance arrives.
The submission object should be immutable after acknowledgement. Corrections and 72-hour updates become new linked objects, not edits that erase the record of what the authority received. Capture the platform reference, payload hash, attachments, submitter identity, timestamp, acknowledgement text, validation errors, and any retry. If the representative copies data manually into the SRP, use an independent reviewer to compare the entered fields with the approved payload before final submission where the clock permits.
This separation also constrains AI use. The assistant may propose fact extraction and draft a candidate payload, but it cannot promote a candidate fact to confirmed, create a legal decision, or mark a submission complete. Those state transitions require authenticated human actions in the case system. Automation should fail closed when the reviewer, payload version, or receipt is missing.
case:
id: CRA-2026-0042
awareness:
approved_at_utc: 2026-09-14T07:18:00Z
approved_by: legal-reviewer-id
evidence: EVT-014
clocks:
early_warning_due: 2026-09-15T07:18:00Z
notification_due: 2026-09-17T07:18:00Z
product_join:
product_id: P-104
versions: ["4.8.0", "4.8.1"]
eu_available: human-confirmed
legal_role: review-approved
release:
state: READY_FOR_QUALIFIED_REVIEW
payload_sha256: pending
srp_receipt: pending
Hashing does not prove a report is correct. It proves which exact version reviewers approved and which version the representative submitted. Pair the hash with names, roles, timestamps, conditions, and the SRP acknowledgement. If the platform rejects or partially accepts a submission, preserve the error and retry history instead of overwriting the first attempt.
Worked example: an exploited component with uncertain product reachability
At 09:18 UTC, Product Security receives a credible vendor notice that a library vulnerability is being exploited in the wild. The company uses the library in three products. One supported EU product exposes the affected function, one embeds the version but disables the path, and one end-of-support product is still installed by customers. The notice is evidence of ecosystem exploitation, not yet proof of exploitation against each product.
Operations freezes the notice and dependency records as evidence, opens one parent case with three product-scope rows, and records 09:18 as a candidate awareness event. Product owners supply build manifests and reachability evidence. Security validates the exploit conditions and searches telemetry. Legal determines which legal entities and products fall within scope, using current Commission guidance, and designates the awareness trigger used for the clocks.
The 24-hour draft states what is known: the vulnerable component and versions, the product relationship, why active exploitation is relevant, current evidence of reachability, immediate mitigations, contact, and the boundaries of customer-impact knowledge. It does not state “no customer exploitation” merely because telemetry is incomplete. Reviewers approve payload version 3; the representative submits it and records the SRP receipt.
Before 72 hours, new telemetry shows attempted exploitation against version 4.8.0 but no confirmed compromise. Version 4.8.1 is also affected, while the disabled product path remains unreachable under the tested configuration. The follow-up is a delta: it preserves the early warning, changes the affected-version and observation fields with source IDs, and explains the evidence. Investigation, customer communication, patch release, and final-report preparation continue under named owners.
Failure modes that break the reporting chain
| Failure | Why it fails | Control |
|---|
| Wait for root cause | The 24-hour clock expires while the team seeks certainty the early warning does not require. | Draft with confirmed facts, explicit unknowns, and parallel investigation. |
| AI chooses awareness time | A probabilistic inference becomes a legal trigger. | Show candidate events; require a named qualified human designation. |
| CVE-only scope | Component presence is confused with product exploitability and legal role. | Join component, configuration, version, product, EU availability, and role. |
| One mutable narrative | Later facts erase what was known and submitted earlier. | Version each payload and publish field-level deltas. |
| Email equals submission | No SRP receipt exists and the correct authority may not receive the record. | Authorized representative submits through the platform and retains acknowledgement. |
| Portal owner unavailable | A complete draft misses the deadline. | Maintain primary/backup representatives and tested access. |
| Every alert becomes reportable | Noise consumes qualified review and encourages automation shortcuts. | Use a fast evidence matrix and human reportability gate. |
| Legal review becomes a bottleneck | Cases wait in an unowned queue. | Define on-call roles, escalation times, minimum evidence, and deputies. |
| Sensitive evidence pasted into public AI | Investigation data crosses an unauthorized boundary. | Use approved tools, minimize inputs, redact safely, or keep the case offline. |
| CRA mixed with NIS2, DORA, or contracts | Different triggers, entities, recipients, and clocks are collapsed. | Maintain a related-obligations matrix with separate qualified owners. |
Measure control health, not just submission speed: time from signal to owner, time to awareness decision, product-register join coverage, percentage of facts with source IDs, unresolved contradictions, time in each review queue, payload rework, representative availability, submission acknowledgement latency, missed or near-missed clocks, and post-submission corrections. A fast report with unsupported facts is not a good outcome.
Implement and test the workflow in 30 days
Week 1 - Decide ownership. Name Product Security, Incident Response, Product, Legal/Compliance, Privacy, Communications, Assigned Representative, and executive escalation roles. Define deputies and response times. Inventory products with digital elements, versions, EU availability, legal entity, component evidence, support status, and owner.
Week 2 - Build the record. Create evidence, awareness, scope, reportability, payload, approval, submission-receipt, and communications objects. Map current official SRP fields. Configure immutable versions and access controls. Approve the AI boundary and pack inputs.
Week 3 - Tabletop. Run at least three cases: credible active exploitation with incomplete product reachability; a severe product-security incident with uncertain customer impact; and a third-party component alert that qualified reviewers decide is not reportable. Start outside business hours and make a primary reviewer unavailable.
Week 4 - Repair and attest. Fix register gaps, slow handoffs, access failures, ambiguous decision rights, and missing evidence. Re-run the hardest case. Record the exact official guidance version used, reviewer sign-off, platform readiness, metrics, and the next test date.
The tabletop should not submit fictional incidents to the production SRP. Test internal preparation and access, then follow ENISA's current guidance for any permitted training or support route. Keep legal interpretation under qualified counsel and update the workflow when Commission or ENISA materials change.
Frequently asked questions
Does every exploited open-source vulnerability require a CRA report?
Do not automate that conclusion. Product scope, the organization's legal role, the affected component's relationship to the product, exploitability in that product, awareness, and current Commission guidance all matter. Create the evidence matrix and route it to qualified reviewers.
Do products sold before full CRA application matter?
ENISA's current FAQ points to Commission guidance stating that Article 14 reporting applies from September 11, 2026 to products within CRA scope, including products placed on the market before December 11, 2027. It also states there is no retrospective duty for active exploitation already known before September 11. Verify the facts and current guidance with counsel.
Should Operations own the legal decision?
No. Operations can own the workflow, clock, evidence completeness, routing, version control, and receipts. Product Security owns technical validation; Legal/Compliance owns legal interpretation; accountable product/business owners own their decisions; the authorized representative owns submission.
What should the early warning say when impact is unknown?
State what is confirmed, how it is known, what remains unknown, what is being investigated, and what immediate mitigation is underway. Do not fill gaps with optimistic inference. The follow-up notification exists to add and reconcile evidence.
Can this workflow replace legal advice?
No. It is an operational evidence and release-control pattern. Qualified counsel must interpret the CRA, related laws, exceptional circumstances, confidentiality, scope, recipients, content, and timing for the actual organization and case.
Sources and current guidance
Public sources were checked on September 14, 2026. Official guidance and platform behavior can change. Verify current European Commission, ENISA, national CSIRT, and legal advice at the time of an actual case.
Related playbooks
Bind product change, owner, evidence, risk, and release decisions before scaling an AI system.
Join discovery signals to accountable assets, owners, data classes, and treatment.
Preserve evidence and route HR, Privacy, Security, and Legal decisions without automated conclusions.