CRA 24-hour reporting checklist: detection and triage

Scope: manufacturers (and, from 11 December 2027 and only to the extent set out in Article 24(3), open-source software stewards) of products with digital elements made available on the EU market.

Legal basis: Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14. Article 14 has applied since 11 September 2026 (Article 71(2)), including to products placed on the market before 11 December 2027 (Article 69(3); Commission FAQ 5.3).

Official text: EUR-Lex, ELI https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (opens in a new tab), HTML https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847 (opens in a new tab).

The purpose of this section is to make sure the 24-hour clock never starts without anyone noticing. It also makes sure that, when the clock does start, the people writing the early warning already have the facts they need.

1. What the law actually requires (verbatim anchors)

Both early warnings must indicate, “where applicable, the Member States on the territory of which the manufacturer is aware that their product … has been made available” (14(2)(a), 14(4)(a)).

Notifications go through ENISA’s Single Reporting Platform (SRP) to the CSIRT designated as coordinator for the manufacturer’s main establishment (14(7), Article 16). The SRP has been operational since 11 September 2026.

“Main establishment” means where decisions on product cybersecurity are mainly taken; if that cannot be determined, the EU establishment with the most employees (Article 14(7)). A manufacturer with no EU main establishment, which includes most UK vendors, reports to the CSIRT in the Member State of its authorised representative (the one acting for the most of its products); failing that, its importer (the one placing the most of its products on the market); then its distributor (the one making the most of them available); then the Member State with the most users (Article 14(7)(a)–(d); ENISA SRP FAQ Q18). Settle which CSIRT that is before you need it.

Definitions that drive triage (Article 3)

• (40) Vulnerability: “a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat”.
• (42) Actively exploited vulnerability: “a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner“.
• (44) Incident having an impact on the security of the product: “an incident that negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of data or functions”.
• Article 14(5): “severe”, where it:
  • (a) “negatively affects or is capable of negatively affecting the ability of a product … to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions”; or
  • (b) “has led or is capable of leading to the introduction or execution of malicious code in a product … or in the network and information systems of a user”.

Recital 68 (interpretive, not binding, but the clearest steer)

• Actively exploited vulnerabilities “concern instances where a manufacturer establishes that a security breach affecting its users or any other natural or legal persons has resulted from a malicious actor making use of a flaw”.
• Good-faith research findings “should not be subject to mandatory notification”.
• Severe incidents “refer to situations where a cybersecurity incident affects the development, production or maintenance processes of the manufacturer”. The recital’s example is malicious code introduced “into the release channel via which the manufacturer releases security updates”.

2. What counts as “becoming aware”

The Regulation does not define the moment of awareness. Two Commission documents help, but neither is binding. The guidance (C(2026) 5252) has had its content approved; its covering Communication says it applies only once formally adopted in all language versions. The FAQ is a Commission services document, not the Commission’s official position. Only the Court of Justice can interpret the CRA authoritatively.

• When. The Commission’s guidance on applying the CRA (C(2026) 5252, 27 July 2026, Annex, section 9.1) says a manufacturer that detects a suspicious event, or is told of one, should assess it immediately. It is regarded as having become aware when, after that initial assessment, it has a “reasonable degree of certainty” that a vulnerability in its product is being actively exploited, or that a severe incident has compromised the product’s security (para 213, p. 74). The guidance deliberately aligns this with the NIS2 and GDPR breach-notification concept of awareness (para 212, p. 74), and stresses prompt action on the initial assessment (para 214, p. 75).
• How. The Commission’s FAQs on the CRA implementation (version 1.4, 4 September 2026, section 5.1) give examples of how a manufacturer may become aware: reports from customers or partners, threat-intelligence and researcher publications, government agencies, ethical hackers, and its own monitoring, telemetry, honeypots or dark-web watching. The FAQ is clear that listing these channels does not oblige a manufacturer to monitor them. Annex I, Part II still requires a vulnerability-reporting contact and a coordinated disclosure policy.
• Before 11 September 2026. The start date is not an amnesty for older flaws. A manufacturer need not report a vulnerability whose active exploitation it was already aware of before 11 September 2026. But where it knew of the vulnerability before that date without being aware of any active exploitation, the vulnerability becomes reportable if, after 11 September 2026, active exploitation occurs or the manufacturer becomes aware of it. Either way, the 24-hour clock runs from the moment the manufacturer becomes aware, not from when the exploitation happened (C(2026) 5252, para 217, pp. 75–76; Commission FAQ 5.3; ENISA SRP FAQ Q13).
• Record the moment. The SRP has a field for “Date/Time when you became aware of the incident/actively exploited vulnerability”. Fill it deliberately and keep the evidence behind it. ENISA notes that in the current release the 72-hour counter shows a due time 48 hours after the early warning was submitted, and that there is no counter for a vulnerability’s final report (SRP FAQ Q26). Do not rely on the platform’s 72-hour counter. Run your own clock from T_aware.

Working rule for this checklist (operational, not a legal interpretation)

Awareness is the point at which a competent person acting for the manufacturer has information that meets both of these tests:

1. Attribution to our product. Our product, component or release channel is involved, not merely the same vendor or a lookalike.
2. Reliable evidence of malicious exploitation or a severe-incident condition. This means the evidence is from a credible source, it is specific, and it is not a proof-of-concept or researcher test.

In practice:

• Receiving an unverified tip is not awareness. It starts triage. Log the receipt time as T_report.
• Awareness (T_aware) is when the triage lead records that both tests are met. That decision must be made “without undue delay”. Target: no more than 4 working hours from T_report for P1 sources (section 3), and the same day for others.
  • Delaying the decision to delay the clock is the risk regulators will look for.
• When the initial assessment reaches a reasonable degree of certainty, declare T_aware; do not wait for root cause. If the evidence sits on the threshold, err towards declaring: an early warning can be narrowed in the 72-hour notification, but a late one cannot be made early.
• Awareness held by any team counts: PSIRT, SOC, support, sales engineering, cloud operations or a subsidiary. Make sure those teams know to forward reports immediately (see Roles).

3. Detection sources to have in place before you need them

Rank each source by priority (P1 = can on its own push you over the reliable-evidence threshold). Assign an owner and a check frequency.

Readiness checks (tick before go-live):

• ☐ A product and component inventory, with CPE/PURL identifiers, mapped to an owner.
• ☐ An up-to-date SBOM per supported version, kept queryable.
• ☐ The list of Member States where each product is made available, needed for the early-warning field.
• ☐ Automated KEV, EUVD and CSIRT matching against the inventory, with alerts to the PSIRT on-call.
• ☐ Support-desk routing rule to PSIRT tested within the last quarter.
• ☐ Build, signing and update infrastructure logged centrally, with alerting on key use outside the pipeline.
• ☐ SRP account registered and at least two submitters able to log in. Test it. Do not discover login problems at hour 22.
• ☐ Clock-synchronised (UTC) logging, so T_report and T_aware can be defended.

4. Triage decision trees

4a. “Actively exploited vulnerability?” (Article 3(42), Article 14(1))

START: signal received → log T_report (UTC), assign triage lead
│
├─ Q1. Does it concern a product with digital elements WE place on the EU market
│      (including a third-party component we ship)?
│      ├─ No  → record rationale, close (consider courtesy note to upstream/vendor)
│      └─ Yes ↓
│           Note: component flaw that cannot be exploited in OUR product
│           (FAQ 5.4; C(2026) 5252 para 218, p. 76), or has not been exploited
│           in it (para 218) → not Art. 14 reportable for us: report upstream
│           (Art. 13(6)), consider Art. 15, keep watching
├─ Q2. Is it a vulnerability (weakness/flaw in our product), not misuse of a
│      correctly-functioning feature or a customer misconfiguration?
│      ├─ No  → go to tree 4b (could still be a severe incident) / handle as support
│      └─ Yes ↓
├─ Q3. Is there evidence of exploitation by a MALICIOUS actor, in a system,
│      WITHOUT the owner's permission?
│      ├─ Only PoC / researcher test / pentest / bug-bounty report → NOT reportable
│      │      under Art. 14(1) (recital 68). Handle via CVD. Re-check daily.
│      ├─ Unknown → gather evidence (section 5); decision within target window
│      └─ Yes ↓
├─ Q4. Is the evidence RELIABLE?
│      Any ONE of these is normally sufficient:
│        • listed in CISA KEV / flagged as exploited by EUVD or a national CSIRT
│          AND the listing concerns our own code, or we have evidence it was
│          exploited in our product (a KEV entry for a component we ship is a
│          P1 trigger to assess, not by itself awareness);
│        • our own forensic analysis of an affected system shows exploitation;
│        • a customer's incident report with artefacts we have verified;
│        • a credible vendor/researcher report with technical indicators tied to
│          our product and version.
│      Two or more weaker signals that corroborate each other also count.
│      ├─ No  → keep open, re-assess on each new signal, log why not yet reliable
│      └─ Yes ↓
└─ AWARE → record T_aware (UTC) and who decided → 24h early-warning clock runs
           → hand to reporting owner + start evidence pack

4b. “Severe incident having an impact on the security of the product?” (Article 14(3) and (5))

START: security incident affecting us, our product, or our dev/build/update chain
│
├─ Q1. Does the incident affect (or could it affect) the PRODUCT's ability to
│      protect availability, authenticity, integrity or confidentiality of data
│      or functions? (Art. 3(44))
│      Typical yes: build/CI compromise, signing-key exposure, update server or
│      repo tampering, malicious dependency injected, cloud back-end of the
│      product (its "remote data processing solution") breached.
│      Typical no: phishing of a sales mailbox with no route to product, HR data
│      breach (may be GDPR/NIS2 — route elsewhere).
│      ├─ No  → not CRA Art. 14; check GDPR / NIS2 / other duties; close here
│      └─ Yes ↓
├─ Q2. Is it SEVERE? Either:
│      (a) affects/capable of affecting SENSITIVE OR IMPORTANT data or functions; or
│      (b) has led/capable of leading to malicious code being introduced or run
│          in the product or in users' systems.
│      Note "capable of" — actual harm to users is not required.
│      ├─ No  → record rationale; consider voluntary notification (Art. 15; the SRP does not yet support it, ENISA SRP FAQ Q27)
│      └─ Yes ↓
├─ Q3. Is it suspected to be caused by unlawful or malicious acts?
│      (Must be stated in the early warning — Art. 14(4)(a). Answer yes / no /
│       not yet known; do not wait for certainty. The 72-hour notification
│       may need to correct this; that is expected.)
│      ↓
└─ AWARE → record T_aware (UTC) → 24h early-warning clock runs
           → if the same event also involves an exploited flaw, run tree 4a too:
             one event can create BOTH notification types.

4c. Severity and urgency labels (internal)

5. Evidence to capture in the first 24 hours

Capture what supports the early warning and the 72-hour notification. Preserve everything else for the final report. Do not wait for complete forensics before submitting the early warning.

Timeline and decision log (start at T_report)

• ☐ T_report: when and how the first signal arrived, plus the original message or ticket, preserved unedited.
• ☐ T_aware: when, who decided, and which test in 4a or 4b was met, with the evidence relied on.
• ☐ Every later decision, with a timestamp and a name or role.

Product scope

• ☐ Product name, affected versions and builds, components (SBOM entry, PURL/CPE), deployment models (on-premises, cloud, embedded).
• ☐ Member States where the product is made available. This is required “where applicable” in the early warning.
• ☐ Rough installed base and the customer segments affected, especially essential and important entities under NIS2.

Exploitation and incident evidence

• ☐ Source of the exploitation evidence: KEV entry, CSIRT advisory, customer report or our own forensics. Keep a link or copy.
• ☐ Indicators we have verified: file hashes, request patterns, log lines, process trees. Never invent or extrapolate indicators.
• ☐ Logs from affected systems we control: product telemetry, cloud back-end, build and CI, signing service. Take hash-verified copies and keep them under chain of custody.
• ☐ For customer systems: what the customer has shared, and what we have asked them to preserve. Do not access customer systems without written permission.
• ☐ For incidents: initial view on cause. Malicious or unlawful: yes, no or unknown.

Mitigation

• ☐ Mitigations available now: configuration change, feature disable, WAF signature, detection rule.
• ☐ Whether a fix is in progress, and an ETA if known. The final-report clock for vulnerabilities starts when a fix or mitigation becomes available.
• ☐ What users can do now. This feeds the user notice under Article 14(8).

Sensitivity and delayed dissemination

• ☐ Decide what we will indicate. The 72-hour notification must state, where applicable, how sensitive we consider the information (Articles 14(2)(b) and 14(4)(b)). We may also ask the coordinating CSIRT to delay sharing it with other Member States, for example because coordinated disclosure is under way or a fix is imminent (recital 70).
• ☐ Do not promise anyone a delay. The decision belongs to the CSIRT designated as coordinator that first receives our notification (Article 16(2), recitals 70 and 71). It may delay only in exceptional circumstances, on justified cybersecurity grounds, and for no longer than strictly necessary. It must tell ENISA why. The terms and conditions for applying those cybersecurity-related grounds are set out in Commission Delegated Regulation (EU) 2026/881, in force since 10 May 2026.
• ☐ Only for a vulnerability notification, and only in particularly exceptional circumstances: check whether one of the three conditions in Article 16(2)(a)–(c) applies (not exploited in any other Member State; dissemination contrary to essential national interests; imminent high risk from dissemination). If so, mark it in the SRP’s PEC field in the 72-hour notification. ENISA then receives limited information until the CSIRT releases the rest.

Storage

• ☐ One case folder per event, with restricted access. The CRA sets no express retention period for Article 14 case files. We keep them for at least 10 years after the affected product was placed on the market, or for its support period if longer. This matches the period in Article 13(13) for the technical documentation, which must describe our vulnerability-handling processes (Annex VII, point 2(b)) and which these records support (Annex I, Part II, point 1). This is a policy choice, not a statutory requirement. Personal data in the folder (names, customer contacts, log extracts) is kept only as long as necessary under GDPR Article 5(1)(e): minimise or pseudonymise it once the final report is filed.

6. Roles (RACI for the first 24 hours)

Rules:

• At least two named people must be able to perform the triage lead and reporting owner roles, with weekend and holiday cover documented.
• The triage lead must have authority to declare T_aware without management approval. Escalation runs in parallel and must not hold up the declaration.
• Run a tabletop exercise each quarter. Alternate two scenarios: a KEV listing of our own product, and a KEV listing of a component we ship, where the exercise is deciding whether it has been exploited in our product.

7. Common pitfalls

• Relying on the SRP’s 72-hour counter. It is not reliable in the current release (ENISA SRP FAQ Q26); run your own clock from T_aware.
• Treating the 24-hour clock as starting when the PSIRT finishes investigating. It starts at awareness. The investigation runs alongside the clock.
• Assuming “no customer harm yet” means “not severe”. Article 14(5) says “capable of”.
• Missing exploited third-party components you ship. Your SBOM matching must cover them, and each match needs an assessment of whether the flaw is exploitable, and exploited, in your product.
• Not knowing where the product is sold, which leaves an early-warning field blank.
• Logging times in local time without a time zone. Use UTC.
• Confusing a public PoC (exploitable) with in-the-wild use (actively exploited).
• Forgetting that a single event can trigger both CRA reporting and other regimes (GDPR, NIS2, DORA). Recital 72 encourages national single entry points, but deadlines and recipients still differ.

Related: The EU Cyber Resilience Act’s 24-hour clock: reporting obligations six weeks in

Sources

1. Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024. Articles 3(40)–(45), 13(13), 14, 15, 16, 24(3), 69(3), 71(2); Annex I Part II; Annex VII; recitals 65–72, 126. EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (opens in a new tab). Text retrieved 25 October 2026.
2. ENISA, Single Reporting Platform: Frequently Asked Questions, Q4, Q13, Q14, Q18, Q19, Q21, Q26 (page updated 15 October 2026). https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp/frequently-asked-questions (opens in a new tab). Retrieved 25 October 2026.
3. ENISA, The CRA Single Reporting Platform is launched, 11 September 2026. https://www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched (opens in a new tab)
4. European Commission, Cyber Resilience Act: reporting obligations, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting (opens in a new tab), and FAQs on the CRA implementation, version 1.4 (4 September 2026), sections 5.1–5.5 (the change log records no change to 5.1–5.4 since first publication; 5.5 was added in version 1.4). The FAQ is prepared by the Commission services and is not the Commission’s official position. https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions (opens in a new tab).
5. CISA Known Exploited Vulnerabilities catalogue. https://www.cisa.gov/known-exploited-vulnerabilities-catalog (opens in a new tab)
6. European Commission, Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, Annex, 27 July 2026, section 9.1 (paras 209–219, printed pp. 74–76), https://ec.europa.eu/newsroom/dae/redirection/document/131456 (opens in a new tab). The covering Communication (C(2026) 5252 final, https://ec.europa.eu/newsroom/dae/redirection/document/131455 (opens in a new tab)) approves the content and states that the guidance “will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply.” The guidance is not binding (Annex, para 8).
7. Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 of the European Parliament and of the Council by specifying the terms and conditions for applying the cybersecurity-related grounds in relation to delaying the dissemination of notifications. OJ L, 2026/881, 20.4.2026; in force since 10 May 2026. ELI: http://data.europa.eu/eli/reg_del/2026/881/oj (opens in a new tab). Title, dates and ELI read from the Publications Office metadata record for CELEX 32026R0881 on 25 October 2026.

Nothing here is legal advice. The Commission’s guidance and FAQs are not binding; only the Court of Justice of the EU can interpret the Regulation authoritatively.

Follow Cyber-Threat.net RSS · Feedly (opens in a new tab) · X (opens in a new tab) · Bluesky (opens in a new tab) · LinkedIn (opens in a new tab)