The CRA reporting clock is live, and the hard part is not the form but moving from an external signal to a defensible product position inside 24 and 72 hours. Suppliers that fix product scope, the awareness rule and evidence traceability before an incident report on controlled facts instead of reconstruction.
The Cyber Resilience Act reporting clock is now operational. Since 11 September 2026, manufacturers of products with digital elements covered by the CRA must report actively exploited vulnerabilities and severe incidents that affect product security. The first deadline can arrive within 24 hours of awareness, and a fuller notification follows within 72 hours. CRA reporting for automotive suppliers has therefore stopped being a planning topic and become a live operational obligation for Tier-1 PSIRT, product security, compliance and CSMS leaders.
For an automotive supplier, the difficult part is rarely opening a regulatory form. The difficult part is establishing what happened, which products are in scope, which customers and markets may be affected, and what evidence supports the initial position while the investigation is still moving.
The reporting obligation therefore exposes an operational question: can the organization move from an external signal to a defensible product decision before the clock expires? This guide covers the deadlines, the preparation that belongs before any incident, the evidence behind each submission, and a worked example in which the clock starts before scope is complete.
The CRA reporting deadlines at a glance
The CRA sets a staged reporting sequence rather than a single submission. Each stage has a different purpose and a different standard of completeness, and confusing them is the first way teams lose time.
| Stage | Deadline | Applies to | What it should rest on |
|---|---|---|---|
| Early warning | Within 24 hours of awareness | Actively exploited vulnerability or severe incident affecting product security | Controlled facts: trigger, awareness timestamp, candidate products, what is still unverified |
| Notification | Within 72 hours of awareness | The same event, after initial assessment | Structured impact assessment: affected products and versions, exploitation conditions, mitigations, open questions with owners |
| Final report (vulnerability) | No later than 14 days after a corrective or mitigating measure becomes available | Actively exploited vulnerability | Root cause, the measure, validation evidence, affected population, customer communication |
| Final report (incident) | Within one month of the 72-hour notification | Severe incident | Complete incident record, corrective actions, supplier responses, approvals |
Two features of this sequence shape everything that follows. Every deadline is anchored to the moment of awareness, so the organization's definition of awareness is itself a compliance control. And the early warning is explicitly not the final technical answer, so the team must be able to separate confirmed facts from working assumptions. Suppliers that have worked through the EU CRA conformity roadmap for automotive suppliers will recognize reporting as the operational end of the same traceability.
Confirm product scope before the incident
CRA applicability in automotive requires careful product-level analysis. Some products or functions may sit within sector-specific regulatory regimes, while independently marketed ECUs, telematics units, diagnostic software, fleet applications, aftermarket devices and other digital products may require separate CRA consideration. Companies should not assume that vehicle type approval automatically answers the question for every item in the portfolio. The interaction between the two regimes is examined in EU Cyber Resilience Act vs. UNECE R155.
Legal teams should confirm the formal scope. Product security and engineering teams must make that scope usable, because a legal opinion in a memorandum cannot be queried on the morning an exploit is published. At minimum, the portfolio record should identify, for each product:
- The legal manufacturer and the entity that placed the product on the market.
- The product family and the software versions currently in support.
- The markets in which each version is sold or deployed.
- The responsible PSIRT contact and escalation path.
- The support period and end-of-support date.
- The relevant regulatory route: CRA, a sector-specific regime, both, or under legal review.
Consider a typical Tier-1 with, say, 40 product families: 28 vehicle-integrated control units delivered into type-approved programs, 6 aftermarket telematics and fleet devices sold under the supplier's own name, 4 workshop diagnostic tools and 2 fleet applications. The regulatory route may differ across those groups, and even within a family when the same hardware is sold through a different channel. Engineering does not decide the legal answer, but the answer must be recorded against the product record so that it is retrievable without a meeting.
This work belongs in the operating model before an incident. Trying to establish legal product boundaries while the 24-hour window is already running introduces avoidable delay, and the delay compounds: scope uncertainty blocks the customer list, which blocks the exposure assessment.
Define awareness before the clock defines it
The awareness timestamp anchors every reporting deadline, so the organization needs an agreed rule for when awareness begins and a record showing how the rule was applied. A message in a private inbox or an untriaged VSOC queue should not become an invisible starting point.
A workable awareness rule names the intake channels and the recognition event for each:
- A vulnerability-intelligence alert that matches a component in a supported product.
- An OEM notification under the contractual disclosure or escalation protocol.
- A VSOC or fleet-monitoring escalation that reaches the PSIRT queue.
- A researcher or coordinator disclosure received through the published contact.
- An internal finding, or a supplier's own notification.
For each channel, the rule states what counts as recognition, who records the timestamp, and where the record lives. Illustratively: an OEM security contact emails a named engineer at 17:40 on a Friday, and the engineer reads it at 08:15 on Monday. Without a rule, the organization has two candidate timestamps more than two days apart and no documented basis for either. With a rule that routes every channel to a monitored PSIRT queue, the question is answered before it is asked.
An untriaged message is not a delay in awareness. It is a deadline already running that nobody can see.
The OEM's own reporting clock may depend on when the supplier informs it, so the awareness rule and the contractual commitment in the OEM–supplier incident escalation framework should be designed together.
The first 24 hours: an early warning built on controlled facts
The European Commission describes the first submission as an early warning. It is not expected to contain the final technical answer. It should still rest on controlled facts rather than assumptions.
A practical first-day workflow should answer six questions:
- What triggered awareness, and when was that awareness recorded?
- Does the event concern an actively exploited vulnerability or a severe incident affecting product security?
- Which product families and versions could be affected based on current evidence?
- Which teams and suppliers must contribute to the assessment?
- What is known, what remains under investigation, and which statements require validation?
- Who is authorized to approve the early warning?
The questions map onto a rough sequence. In the first two hours, the PSIRT registers the signal with its source, timestamp and candidate product association, and opens the incident record that every later artifact attaches to. Between hours two and eight, the team runs the candidate scope: SBOM matching, architecture lookup, customer configuration records. Between hours eight and eighteen, it drafts the early warning in three labeled blocks: confirmed, under investigation, and not yet assessed. The remaining time is for the authorized approver to review and submit.
The labeled blocks are the heart of the early warning. "The component is present in three delivered builds; reachability in the delivered configuration is under investigation; aftermarket variants have not yet been assessed" is more defensible than either a confident claim of no impact or a vague statement that the matter is being looked into.
The 72-hour notification: from signal to supported impact assessment
The next phase turns the early signal into a structured impact assessment. The team should connect the vulnerability or incident to the affected product architecture, software composition, deployed versions, available mitigations and known exploitation conditions.
For automotive suppliers, that often requires evidence from several sources, each answering a different question.
| Evidence source | Question it answers | Typical failure mode |
|---|---|---|
| SBOM for each delivered build | Is the component present, and at which version | SBOM exists per release branch, not per delivered build |
| Software architecture | Is the vulnerable function present and reachable in the delivered configuration | Architecture is a slide, not a queryable model linked to software records |
| TARA | Which damage and threat scenarios the exposure activates | TARA predates the current software baseline |
| Test results | Reachability proven or disproven; compensating control demonstrated | Tests are not linked to the control they verify |
| Customer configuration records | Which OEM programs received the affected version, in which markets | Delivery records sit in a general-purpose ticketing system without version granularity |
| Supplier responses | Status of sub-components the Tier-1 did not author | No clock on the reply, no record of what was asked |
The SBOM may identify a component match, and the practices in SBOM management for automotive decide whether that match can be made per delivered build rather than per release branch. Each of the other sources then narrows the match toward a product-level answer.
The 72-hour submission should reflect the best supported position available at that time. Where the investigation remains incomplete, the record should say so plainly and assign the next action. Confidence improves when the decision chain preserves both evidence and uncertainty: claiming more certainty than the evidence supports creates a correction obligation later, while omitting evidence the team already holds invites the question of why it was not used.
Final reports still require engineering discipline
The CRA also requires final reporting. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month of the 72-hour notification.
That later report cannot be assembled reliably from email fragments. The organization needs the following in one traceable incident record:
- The original signal, its source and the awareness timestamp.
- Every scope change, with the evidence that drove it.
- The technical analysis and its inputs: SBOM matches, architecture lookups, TARA scenarios, test results.
- Supplier requests and responses, with timestamps.
- The treatment decision and its rationale.
- Validation evidence for the corrective or mitigating measure.
- Customer communication and the affected-program list it went to.
- Every regulatory submission and the approval behind it.
This is where many teams discover that compliance depends on engineering traceability. The report is the output. The underlying capability is the ability to connect a product event to the exact components, versions, programs, risks, controls, tests and owners involved.
The final report is not written at day 14. It is written, one record at a time, from the moment of awareness.
A practical CRA reporting chain in five stages
An automotive supplier can organize the workflow around five controlled stages, each producing an output that the next stage consumes.
- Capture awareness: register the signal, source, timestamp and initial product association.
- Scope exposure: map the event to product families, versions, customers, markets and deployed configurations.
- Assess impact: connect the issue to architecture, SBOM records, attack paths, TARA scenarios and available controls.
- Decide and report: preserve the facts, uncertainties, approvals and regulatory submissions for each deadline.
- Validate and close: verify the corrective measure, update affected records, and retain the final evidence package.
The chain is deliberately product-centric: "product family", "delivered version", "OEM program" and "TARA scenario" must be records that can be queried, not text in a ticket description. The most useful readiness test is a drill: take one recent advisory that touched a supported product, run the five stages against the clock, and record where time was lost. Suppliers comparing their tooling against this requirement can start with compare your current setup.
For Tier-1 organizations, the practical question is how much of the chain already exists in engineering records and how much is reconstructed per incident; the ThreatZ for Tier-1 suppliers overview describes the connected record in that context.
Worked example: the reporting clock starts before scope is complete
A Tier-1 supplier learns at 09:10 that a software library used in a telematics module is being actively exploited. The supplier delivers the module to three OEMs, but the library version and build configuration differ by program. At that moment, the team may know enough to start the CRA assessment but not enough to make a final product-impact statement.
The first controlled action is to preserve the awareness timestamp and the candidate product scope. The PSIRT registers the signal at 09:25 under the awareness rule. By 11:00, SBOM matching across delivered builds shows the library in all three delivered versions, but at two library releases: programs A and B received release 2.4, program C received release 2.1. The advisory names 2.4. Program C is marked "likely not affected, pending confirmation" rather than removed from scope, because a component-level match is not yet a function-level answer.
By mid-afternoon, the architecture record shows that the vulnerable function belongs to the remote-configuration path in the 2.4 builds, and that program B's delivered configuration disables that path at build time. The team records this as a mitigating condition under investigation and assigns a test engineer to confirm it. A request goes to the library's upstream supplier, with its time recorded. The early warning is approved at 17:30 and submitted: component confirmed in three delivered versions; exploited release present in two; reachability in one of those under investigation; aftermarket variants not yet assessed.
On day two, the reachability test confirms that program B is not reachable through the exploited path, and the aftermarket variant is confirmed to ship release 2.4 with the path enabled. The TARA already contains a threat scenario for unauthorized remote configuration, so the existing risk position is attached rather than rewritten. The 72-hour notification adds the supported impact assessment, the treatment direction and the updated product scope: program A and the aftermarket variant affected, program B mitigated by configuration with test evidence, program C not affected by version.
A patched library release becomes available on day nine; the 14-day window for the final vulnerability report runs from the availability of that measure, and because every step attached to the same incident record, the final report is an export of the chain. The example shows why CRA reporting readiness depends on product traceability before the incident, not on form-filling after it.
Frequently asked questions
When does the CRA 24-hour reporting period begin?
The period begins when the manufacturer becomes aware of an actively exploited vulnerability or severe incident that meets the reporting conditions. Because the timestamp anchors every later deadline, the organization should define how awareness is recognized, timestamped and escalated across all intake channels, so an untriaged message in a private inbox or a monitoring queue does not create an invisible deadline.
Does the 72-hour notification need a final root-cause analysis?
No. It should provide the fuller information required by the CRA based on the best supported position available at that time. Where scope, root cause or treatment remains under investigation, the submission should distinguish confirmed facts from open questions and assign the next actions with owners. Preserving both evidence and uncertainty makes the notification easier to defend and to update.
How does CRA reporting relate to automotive type approval?
The regimes can interact, but they are not interchangeable. Automotive companies should determine which products with digital elements fall within CRA scope and which sector-specific rules apply, product by product rather than by portfolio. Legal counsel should confirm applicability; engineering and product-security teams must maintain the product records needed to execute the decision quickly when a signal arrives.
What should a supplier do when product scope is still uncertain at the 24-hour mark?
Report on the controlled facts and label the rest. The early warning is not expected to hold the final technical answer, so the defensible position is a candidate scope with an evidence basis per entry, a clear statement of what is under investigation, and named owners for each open question. Removing a product on an assumption, or including every product to be safe, both weaken the record.
Which records must survive to the final report?
The original signal and awareness timestamp, every scope change with its evidence, the technical analysis with its SBOM, architecture, TARA and test inputs, supplier requests and responses with timestamps, the treatment decision, validation evidence for the measure, customer communication, and every regulatory submission with its approval. Attached to one incident record from the start, the final report is an export; scattered across email and tickets, it is a reconstruction.
- The clock is live: since 11 September 2026, covered manufacturers owe a 24-hour early warning, a 72-hour notification and a final report within 14 days of a measure or one month of the notification.
- Scope before the incident: confirm the legal route per product and record it against the product record, so it does not block the customer list on day one.
- Define awareness explicitly: name every intake channel, the recognition event and the timestamp owner, and route all channels to one monitored queue.
- Early warning means controlled facts: three labeled blocks of confirmed, under investigation and not yet assessed, approved by a named authority.
- The 72-hour position is evidence-based: SBOM per delivered build, queryable architecture, current TARA, linked tests and customer configuration records each answer a different question.
- Final reports are built incrementally: every scope change, supplier response, decision and approval attaches to one incident record from the moment of awareness.
- Run the chain as a drill: take one real advisory, run the five stages against the clock, and fix the stage where time was lost.
Related reading on VxLabs Security
- ThreatZ for Tier-1 suppliers
- Compare your current setup
- ThreatZ platform
- EU CRA conformity roadmap for automotive suppliers
- EU CRA vs UNECE R155
- OEM–supplier incident escalation framework
Authoritative references
- Regulation (EU) 2024/2847 — Cyber Resilience Act — European Parliament and Council, 2024
- Cyber Resilience Act summary — European Commission
- Cyber Resilience Act reporting obligations for manufacturers — European Commission
- UNECE Regulation No. 155 — Cyber security and cyber security management system — UNECE
- ISO/SAE 21434:2021 Road vehicles — Cybersecurity engineering — ISO/SAE