CRA reporting starts 11 September 2026: are you ready?

A vulnerability report arrives late on Friday. It concerns a component embedded in several products, and the reporter says exploitation has been seen in the wild. Engineering wants time to reproduce it. Legal wants to know whether the Cyber Resilience Act (CRA) applies. Incident response wants affected versions and telemetry. Management wants to wait until the facts are clean.

From 11 September 2026, waiting for a complete picture may burn most of the first CRA deadline.

The reporting duties in Article 14 start before the CRA's main obligations. Manufacturers of in-scope products with digital elements must notify actively exploited vulnerabilities and severe incidents affecting product security. The process is staged: an early warning within 24 hours, a fuller notification within 72 hours, then a final report on a different timetable for vulnerabilities and incidents.

This is not a reason to send every bug to ENISA. It is a reason to decide, in advance, who can establish awareness, identify the legal manufacturer, preserve evidence and submit a defensible report while the investigation is still moving.

What changes on 11 September 2026

The CRA entered into force on 10 December 2024. Most obligations apply from 11 December 2027, but Article 14 reporting applies from 11 September 2026. The early start catches teams that have treated CRA readiness as a 2027 product-conformity project.

The reporting rule covers all products with digital elements within the CRA's scope, including qualifying products placed on the market before 11 December 2027. Commission guidance also says that reporting continues after a product's support period ends, even though the broader vulnerability-handling duties may not apply to an older or unsupported product in the same way.

That makes product history operationally relevant. A legacy appliance, old software branch or discontinued connected device cannot simply disappear from the reporting inventory because engineering no longer builds it. The organisation still needs enough ownership data to recognise the product, find the responsible manufacturer entity and assess a report.

Article 14 has two mandatory triggers for manufacturers:

• an actively exploited vulnerability contained in the product of which the manufacturer becomes aware; and
• a severe incident that affects the security of the product and of which the manufacturer becomes aware.

A newly discovered vulnerability is not automatically an actively exploited vulnerability. The Regulation requires reliable evidence that a malicious actor exploited it without the system owner's permission. Good-faith research, a laboratory finding or a bug-bounty submission without evidence of malicious exploitation does not meet that mandatory trigger, although voluntary reporting remains possible.

The same caution applies in the other direction. A third-party component vulnerability cannot be dismissed as "the supplier's problem." If active exploitation is present in the manufacturer's product, the manufacturer of that product has its own reporting duty. If the vulnerable code is unreachable in the product or there is no exploitation in that product, the Commission guidance says it is not mandatory CRA reporting for that manufacturer, though vulnerability handling and upstream coordination may still be required.

The CRA clock: 24 hours, 72 hours, then a final report

The deadlines run from awareness, not from confirmation of every technical detail. The Commission's July 2026 guidance says awareness is reached when an initial assessment gives the manufacturer a reasonable degree of certainty that active exploitation exists, or that a severe incident has occurred and compromised the product's security. It also tells manufacturers to assess suspicious events promptly.

The staged process is designed for incomplete investigations:

1. Early warning: without undue delay and, in any event, within 24 hours of becoming aware.
2. Notification: without undue delay and, in any event, within 72 hours of becoming aware. This adds the information available as the investigation develops.
3. Final report for an actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure becomes available.
4. Final report for a severe incident: within one month after the 72-hour notification.

The 24-hour filing is not meant to be a finished forensic report. The mistake is to treat uncertainty as permission to stop the clock. Record what is known, what remains unverified, the basis for the trigger decision and who approved the submission. Update the notification as facts improve.

Notifications go through the CRA Single Reporting Platform (SRP), which ENISA is required to make operational by 11 September 2026. The Commission describes this as a single report addressed to the CSIRT for the Member State of the manufacturer's main establishment; except in particularly exceptional circumstances, the information is made available simultaneously to ENISA and disseminated to other relevant CSIRTs. ENISA has published SRP registration and submission guidance, but warns that operational instructions may change. Teams should check the live guidance before relying on a saved procedure.

Who has to report, and who should not be casually labelled a manufacturer

The Article 14 duty is framed around the manufacturer. Under the CRA, that is not always the factory or original coder. The legal classification depends on who develops or has a product developed and markets it under its own name or trademark, among other facts in the Regulation.

Importers and distributors have their own CRA duties. They should not be described as automatically subject to the manufacturer's 24- and 72-hour Article 14 process. However, an importer or distributor can be treated as a manufacturer if it places a product on the market under its own name or trademark or carries out a substantial modification. Other actors can also acquire manufacturer obligations after a substantial modification.

For that reason, a reseller, white-label provider, systems integrator or company shipping a modified product needs a product-by-product legal analysis. A contractual label does not settle the CRA role.

Open source needs the same precision. Code developed or supplied outside a commercial activity is treated differently, and individual contributors should not be swept into manufacturer language. The CRA creates a separate category of open-source software steward for a legal person, other than a manufacturer, that systematically provides sustained support for FOSS intended for commercial activities and ensures its viability.

Stewards have a narrower reporting obligation under Article 24. Commission guidance specifically says they must report actively exploited vulnerabilities under Article 24(3), to the extent they are involved in development of the relevant product. A company can be a steward for a free community version and a manufacturer for a monetised version, so one organisation may hold different roles for different releases.

Scope and role classification are legal questions. Engineering can supply facts, but should not decide them alone during an incident.

Build the reporting path around evidence, not meetings

A workable process starts before the alert. The goal is not a large CRA policy. It is a short route from signal to decision, with enough evidence to support each handoff.

1. Map products to legal entities and accountable owners

Create an inventory that links each product family and supported or legacy version to:

• the entity that places it on the EU market;
• trade names and white-label arrangements;
• its components and remote data-processing dependencies;
• product, security and legal owners;
• support status and available build or forensic material;
• the CSIRT jurisdiction associated with the manufacturer's main establishment.

Do not wait for a live incident to discover that the product name used by customers is absent from internal records.

2. Define the awareness decision

The CRA clock needs an auditable starting point. Record the first signal, source, time received, initial assessment steps, evidence of exploitation or compromise, affected product reasoning and the time at which reasonable certainty was reached. Preserve contrary evidence too.

A single security intake should accept customer reports, researcher disclosures, SOC alerts, threat intelligence and supplier notifications. Route it to a small decision group with named alternates. Twenty people in a bridge call is not an escalation model.

3. Prepare the 24-hour minimum dataset

Draft a template that can be completed with partial information. It should capture the product and manufacturer, event type, awareness time, affected versions or uncertainty, observed exploitation or incident indicators, territories known to be affected, immediate containment, likely impact and a contact who can answer follow-up questions.

Separate facts from hypotheses. Keep source timestamps, logs, hashes, tickets and copies of external reports under a clear retention rule. A vulnerability management programme can help maintain the component and remediation trail, but the filing decision still needs legal ownership.

4. Make the 72-hour update an engineering deliverable

By 72 hours, the organisation should be able to explain more: the product exposure, affected versions, exploitation path or incident mechanics, impact, indicators, mitigation status and next investigation steps. This requires product engineering, security and incident response to work from one case record.

Assign an evidence lead. Their job is to prevent three teams from keeping conflicting timelines. If the event also triggers NIS2, data-protection, sectoral or contractual notices, maintain a matrix of deadlines and recipients rather than assuming one filing satisfies every regime.

5. Connect remediation to the final report

For a vulnerability, the final-report deadline is tied to availability of a corrective or mitigating measure. Patch release, configuration mitigation and customer communication therefore need recorded times and version identifiers. For a severe incident, reserve review time before the one-month deadline; do not leave the final narrative with the incident commander on day 29.

Article 14 also requires manufacturers to inform impacted users and, where appropriate, all users. Commission guidance says that communication should be risk based and proportionate: it need not indiscriminately publish sensitive technical detail while exploitation remains possible.

A 30-day readiness plan

In the first week, classify product families and responsible entities. Include old products and separate community, commercial and white-label editions. Escalate uncertain roles to qualified counsel.

In week two, run a tabletop exercise. Use a realistic component report with incomplete evidence. Measure when the team reaches reasonable certainty, not when the fictional patch is finished. Force a decision on the 24-hour warning.

In week three, test SRP access and assigned representatives against ENISA's current instructions. Prepare filing templates, alternates, out-of-hours contacts and evidence storage. Do not put credentials in the procedure document.

In week four, run the exercise again with legal, engineering, product security, communications and incident response. This time add a second regulatory notification and a supplier dispute. Close every gap with an owner and due date.

A virtual CISO can help coordinate governance and exercises where no internal security leader owns the process. If the product inventory or response evidence is weak, start there rather than buying another alert feed. When the ownership and facts are ready for an external review, contact Enclave Guard to scope a focused CRA reporting-readiness exercise.

The deadline is procedural, but the failure will be organisational

The CRA does not expect the full answer in 24 hours. It expects a manufacturer to recognise a reportable situation, submit the early warning and improve the record as the investigation advances. The organisations most likely to miss that window are not necessarily those with poor detection. They are the ones that cannot identify their legal role, product exposure, decision owner or evidence source quickly enough.

Treat 11 September 2026 as an incident-readiness deadline. Classify the products, rehearse the awareness decision, establish SRP access and make the reporting chain work out of hours. The filing form is the easy part.

This article provides general information and does not constitute legal advice. CRA scope, economic-operator status and notification duties depend on the facts of each product and organisation. Obtain qualified legal advice for your situation.