The hard part of CRA Article 14 isn't the form. It's that your company now has 24 hours, weekends included, from the moment someone inside it holds reliable evidence that a product vulnerability is being exploited, to file an early warning with an EU national CSIRT and ENISA. If nobody has decided in advance who makes that call, what evidence counts, and where the product-to-country inventory lives, the clock runs out while people are still arguing in a chat channel.
The reporting duties in Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), have applied since 11 September 2026, and the Single Reporting Platform (SRP) run by the European Union Agency for Cybersecurity (ENISA) opened the same day. Law firms have explained the legal duty at length. What's been missing is a runbook for the people who have to execute it: detection, the severity decision, SRP onboarding, and the artefacts due at 24 hours, 72 hours, 14 days and one month.
Two triggers, not every CVE
Article 14 fires on exactly two events. Everything else in your backlog stays under ordinary vulnerability handling, which carries no 24-hour clock.
Trigger one: an actively exploited vulnerability. Article 3(42) defines this as a vulnerability for which there is reliable evidence that malicious code was executed by an actor on a system without the system owner's permission. A CVSS 9.8 with no observed exploitation doesn't meet it. A researcher's proof of concept run on their own lab system doesn't either. A medium-severity bug that an attacker is actually using against a customer does.
Trigger two: a severe incident having an impact on the security of the product. Article 14(5) sets two alternative tests: the incident negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or it has led, or could lead, to the introduction or execution of malicious code in the product or in a user's network and information systems. Note "capable of": a compromised build pipeline that could have signed a malicious update may qualify even if you caught it before shipping.
The two tracks share the 24-hour and 72-hour stages and diverge at the final report.
Stage | Actively exploited vulnerability (Art. 14(2)) | Severe incident (Art. 14(4)) |
Early warning | Within 24 hours of becoming aware. Indicate, where applicable, the Member States where the product has been made available. | Within 24 hours of becoming aware. State at least whether the incident is suspected to be caused by unlawful or malicious acts, plus affected Member States where applicable. |
Notification | Within 72 hours of becoming aware: general product information, the general nature of the exploit and vulnerability, corrective or mitigating measures taken and that users can take, and how sensitive you consider the information. | Within 72 hours of becoming aware: general nature of the incident, an initial assessment, measures taken and that users can take, and the sensitivity indication. |
Final report | Within 14 days after a corrective or mitigating measure is available: description of the vulnerability including severity and impact, information on the exploiting actor where available, and details of the update or other corrective measure. | Within one month after the 72-hour notification: detailed description including severity and impact, the type of threat or root cause likely to have triggered it, and applied and ongoing mitigations. |
Status updates | At the coordinating CSIRT's request (Art. 14(6)). | At the coordinating CSIRT's request (Art. 14(6)). |
Source: Article 14, Regulation (EU) 2024/2847
A planning detail: the vulnerability final report is anchored to the fix date, not the awareness date. If a patch takes six weeks, the final report is due six weeks and 14 days after awareness. The incident final report runs from your own 72-hour filing instead.
Scope is wider than many teams assume. Article 69(2) extends Article 14 to products already placed on the EU market before the rest of the CRA applies on 11 December 2027, and Kirkland & Ellis's September 2026 alert makes the same point: the duty covers legacy products, not just new launches. Importers or distributors selling under their own brand, or making a substantial modification, take on manufacturer duties too.
Where the filing goes, and which CSIRT is yours
You file once. Article 14(1) and (3) require simultaneous notification of ENISA and the CSIRT designated as coordinator in your Member State, and Article 16 makes the SRP the channel for both. The European Commission's reporting obligations page confirms the SRP has been operational since 11 September 2026 and that manufacturers must submit through it. ENISA's launch release describes the flow: the coordinating CSIRT that first receives a notification disseminates it to CSIRTs in the other Member States where the product is available.
Which CSIRT depends on your "main establishment" under Article 14(7): the Member State where decisions about the cybersecurity of your products are predominantly taken. If that can't be determined, it's the Member State where you have the most employees in the EU. Manufacturers with no EU establishment work down a fixed order: the Member State of the authorised representative acting for the largest number of their products, then the importer, then the distributor, then the Member State with the most users. Decide this once, record the reasoning, and put the answer in the runbook. It should not be a question anyone researches at hour 19.
What the platform does and doesn't do at launch
ENISA calls the current release "initial operating capability" and says functionality will expand over the coming months based on operational experience. Reporting by Help Net Security, drawing on ENISA's SRP FAQ, fills in the operational detail that matters for a runbook (reported, not independently tested by xSypher):
Registration runs on an EU Login account with multi-factor authentication.
Each manufacturer gets one Primary Assigned Representative and up to 20 Secondary Assigned Representatives; the coordinating CSIRT validates the association. A representative whose association is still pending can file a limited number of notifications before verification becomes mandatory.
There is no API in this release. Notifications go through the web form, one per event, and a company with several subsidiaries has to coordinate so exactly one goes in.
Two further limits come from ENISA's SRP FAQ. Open-source software stewards' reporting under Article 24(3) only applies from 11 December 2027, so at launch the platform serves manufacturers' mandatory Article 14 notifications. And voluntary reporting under Article 15 is not yet available through the SRP; ENISA has indicated it arrives in a later phase. If your process assumed a "when in doubt, file voluntarily" safety valve on the platform, it doesn't exist yet as of early October 2026.
The workflow from detection to final report (MERMAID)
The runbook below has one design principle: the 24-hour clock starts at awareness, so the awareness decision is the step you engineer hardest. Everything upstream exists to get credible signals to the decision-maker fast. Everything downstream is filing on a schedule.
Step 1: Define "aware" before you need it
The regulation says the 24 hours run from the manufacturer "becoming aware". It doesn't say which human, or what evidence standard. Leave that open and you get the worst of both worlds: engineers who sit on a customer report for three days because they aren't sure it counts, and a regulator who later argues awareness began when the first support ticket arrived.
Write a one-page awareness policy and get legal to sign it. It needs four things:
A named role that can declare awareness, with a 24/7 deputy. In most organisations this is the PSIRT lead or the on-call security incident manager. Give the role authority to declare without waiting for a VP.
An evidence standard that mirrors Article 3(42). For the vulnerability track, that's reliable evidence of malicious code execution without permission on a system running your product: forensic artefacts from a customer, your own telemetry, a trustworthy third-party report, or your product appearing in an exploitation catalogue with corroborating detail. For the incident track, map the Article 14(5) tests to your own asset list: build systems, update servers, signing keys, cloud back ends the product depends on.
A decision log with timestamps: when the signal arrived, when triage started, when awareness was declared or declined, and why. This log is your defence if a regulator later disputes your clock.
A target. We suggest triage-to-decision within four hours of a credible signal. That is an xSypher engineering recommendation, not a legal requirement, and it leaves 20 hours of margin for the filing.
Step 2: Route every exploitation signal into one queue
Exploitation evidence rarely arrives through the channel you planned for. Put every path into a single triage queue that pages the awareness role.
Customer and field reports. Support, account managers and field engineers need a one-line instruction: any mention of compromise, malware or unexplained behaviour in your product goes to the PSIRT queue the same hour. Most 24-hour failures will start with a ticket that sat in a general inbox.
Your coordinated vulnerability disclosure intake. Tag reports that mention in-the-wild exploitation so they bypass the normal CVD timeline.
Product telemetry and crash data, where you have it and where your privacy basis allows security use.
Exploitation catalogues. The US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities (KEV) catalogue and ENISA's European Vulnerability Database (EUVD), launched in May 2025, both flag exploited CVEs. A listing for a component you ship is a strong signal, but check whether the exploited code path is reachable in your product before declaring awareness.
Upstream advisories, matched against your software bill of materials. A machine-readable SBOM covering more than top-level dependencies is what makes this step take minutes rather than a manual search across repositories.
Timing note: the CRA's vulnerability-handling requirements in Annex I, Part II (SBOM, CVD policy, coordinated disclosure) and the Article 13(6) duty to report component vulnerabilities to their maintainers apply from 11 December 2027, not today. Build them now anyway. They're the plumbing that makes Article 14 workable, and the reporting duty doesn't wait for them.
Step 3: Make the severity decision in a fixed order
Run the same questions every time, in this order, and record each answer.
Is the affected software or hardware a product with digital elements we place on the EU market, or a component of one? If not, close with a record.
Is there reliable evidence of malicious code execution without permission? If yes, you have an actively exploited vulnerability. Declare awareness and go to Step 4.
If not, does the event meet either Article 14(5) test for a severe incident? Compromised signing infrastructure, a tampered update, or an intrusion that reached data or functions the product is supposed to protect are the common cases. If yes, declare awareness on the incident track.
If neither, log the reasoning and continue ordinary handling. Revisit if new evidence arrives; the clock starts when the evidence standard is met, not when the first report came in.
Resist letting the decision depend on patch readiness. Whether a fix exists affects what you put in the 72-hour notification; it doesn't change whether the 24-hour clock has started.
Step 4: File the 24-hour early warning with what you know
The early warning is deliberately thin. For a vulnerability, Article 14(2)(a) requires only that you flag the exploited vulnerability and, where applicable, the Member States where the product has been made available. For an incident, Article 14(4)(a) adds whether you suspect unlawful or malicious acts. You are not required to have root cause, an exploit analysis or a fix.
What slows teams down is not the content but the lookups. Pre-build these:
A product registry mapping every product and version to the Member States where it's made available, with a named owner who can confirm it in minutes. If you sell EU-wide through distributors and genuinely can't narrow it, say so rather than guess.
An early-warning template holding your SRP account identity, coordinating CSIRT, product identifiers, a one-paragraph description and the Member State field, stored in the same system as the decision log so timestamps line up.
A sign-off path of at most two people: the awareness role and a legal or compliance reviewer with a hard 60-minute response target. If the reviewer is unreachable, the runbook should let the awareness role file anyway.
Step 5: The 72-hour notification is where analysis belongs
By 72 hours you need general product information, the general nature of the exploit and vulnerability (or the nature and initial assessment of the incident), the corrective or mitigating measures you've taken and the ones users can take, and an indication of how sensitive you consider the information.
That sensitivity flag is not decoration. Under Article 16(2), the coordinating CSIRT that first receives your notification may, in exceptional circumstances and on justified cybersecurity grounds, delay wider dissemination for the time strictly necessary. The Commission has now set the conditions in Delegated Regulation (EU) 2026/881, adopted 11 December 2025 and published in the Official Journal on 20 April 2026. It gives the CSIRT three grounds: the sensitivity of the notified information, including where a notification could enable an exploit without further research; a receiving CSIRT's inability to keep it confidential; and the security of the platform itself. The CSIRT is allowed to delay, not required to, and it must tell ENISA its reasons and intended dissemination date.
The practical lesson for engineering: you can request a delay, but you don't control it. Write the 72-hour notification assuming it will reach every CSIRT in every affected Member State, and put your exploit-enabling detail only where the form asks for it. Your legal reviewer should read Article 4 of the delegated regulation before you build embargo assumptions into the runbook.
Practical content for this stage: affected versions, the condition under which the vulnerability is reachable, interim mitigations (configuration changes, network restrictions, feature disablement), your estimated fix timeline, and what you know about targeting. Label estimates as estimates.
Step 6: Tell users, and make the advisory machine-readable
Article 14(8) is the obligation engineering teams most often miss because it's not a filing. After becoming aware of an actively exploited vulnerability or severe incident, the manufacturer must inform the impacted users, and where appropriate all users, about it and, where necessary, about risk mitigation and corrective measures they can deploy. The regulation adds that this should, where appropriate, be in a structured, machine-readable format that is easily automatically processable.
Two implementation choices follow:
Format. The Common Security Advisory Framework (CSAF) 2.0, an OASIS standard, is the obvious machine-readable choice, and its VEX profile lets you state that a product is or isn't affected by a component CVE. Publishing CSAF alongside a human-readable advisory satisfies both the "inform users" and "machine-readable" parts.
Timing. Article 14(8) has no fixed deadline beyond becoming aware, and full public disclosure of a fixed vulnerability is a separate act that the regulation allows you to delay in justified cases. Informing impacted users of an exploited vulnerability is not the same as publishing a full write-up; a targeted notice with mitigations can go out while details stay restricted. Your legal reviewer should define the line.
Keep a channel inventory: in-product notifications, a security advisories page with a stable URL, mailing lists, and contractual contacts for enterprise customers. The runbook should state which channels count as "informing users" for each product line.
Step 7: Close the record with the final report
For a vulnerability, the final report is due within 14 days after a corrective or mitigating measure is available. It must at least describe the vulnerability including severity and impact, give any available information on the actor exploiting it, and detail the security update or other corrective measure. For an incident, the final report is due within one month of your 72-hour notification and covers a detailed description, severity and impact, the likely threat type or root cause, and applied and ongoing mitigations.
Two operational notes. First, "a corrective or mitigating measure is available" can be earlier than "the patch has reached every customer": a published mitigation may start the 14 days. Record the date you consider the measure available and why. Second, the coordinating CSIRT can request intermediate status updates under Article 14(6), so keep the incident channel staffed until the final report is in, not just until the fix ships.
Three clocks that look alike and don't merge
If your company is also an essential or important entity under the NIS2 Directive, or processes personal data, the CRA filing doesn't discharge those duties.
personal data, the CRA filing doesn't discharge those duties.
Regime | Trigger | Recipient | First deadline |
CRA Article 14 | Actively exploited vulnerability in, or severe incident affecting, a product you make | Coordinating CSIRT and ENISA via the SRP | 24-hour early warning |
NIS2 Article 23 | Significant incident affecting an essential or important entity's own services | National CSIRT or competent authority | 24-hour early warning |
GDPR Article 33 | Personal data breach | Supervisory data-protection authority | 72 hours where feasible |
Source: Regulation (EU) 2024/2847; Directive (EU) 2022/2555; Regulation (EU) 2016/679.
A single event, say a compromised update server that pushed malicious code to customers and exposed their account data, can start all three. Add a one-line check at awareness: which of the three apply, and who owns each filing. Different people, different portals, different content.
What to have ready before the first signal arrives
An SRP account on EU Login with multi-factor authentication, Primary and Secondary Assigned Representatives named and validated by your coordinating CSIRT, and the Article 14(7) reasoning written down
The awareness policy from Step 1, signed off by legal, with a 24/7 roster for the awareness role
A product registry mapping products and versions to EU Member States of availability
A machine-readable SBOM per product that triage can query against KEV, EUVD and upstream advisories
Templates for the early warning, 72-hour notification, user advisory (human-readable and CSAF) and final report, stored with the decision log
A tabletop exercise run against a realistic scenario on the real clock, and the gaps it exposed fixed
If you run only one exercise, make it a Friday 18:00 awareness declaration. The 24 hours end Saturday evening, and that's where most runbooks break.
Questions engineering teams are asking about Article 14
Does a researcher's proof-of-concept exploit make a vulnerability "actively exploited"?
Not on the text of the CRA. Article 3(42) requires reliable evidence that malicious code was executed on a system without the owner's permission. A researcher testing a system they control, with consent, isn't that. Handle the report through your coordinated vulnerability disclosure process and log the decision. If evidence of real-world exploitation appears later, the 24-hour clock starts at that point.
Do we report under the CRA if the exploited bug is in an open-source library we ship?
Yes, if the vulnerability is contained in your product and the exploited code path is reachable in it. The obligation attaches to the product, not to who wrote the code. Open-source software stewards have their own, narrower reporting role under Article 24(3), but ENISA's SRP FAQ confirms that duty only applies from 11 December 2027; until then the SRP serves manufacturers' mandatory notifications.
We're a US company with no EU office. Which CSIRT do we notify?
Article 14(7) sets a fixed order for manufacturers without a main establishment in the EU: the Member State of the authorised representative acting for the largest number of your products, then the importer placing the most of your products on the market, then the distributor, then the Member State with the most users. Work it out now, document it, and register on the SRP against that coordinating CSIRT.
Does the 24-hour deadline pause over weekends and holidays?
No. Article 14 says "without undue delay and in any event within 24 hours" of becoming aware, with no business-day qualifier. That is why the awareness role in this runbook needs a 24/7 roster and the authority to file without escalating. Treat a Friday-evening signal as the design case for your process, not the edge case.
Can we ask the CSIRT to keep our notification confidential?
You can flag sensitivity in the 72-hour notification, and under Article 16(2) and Delegated Regulation (EU) 2026/881 the coordinating CSIRT may delay dissemination to other CSIRTs on defined cybersecurity grounds for the time strictly necessary. The decision is the CSIRT's, not yours, and ENISA still learns that a notification exists. Plan your content as if it will be shared.
The runbook you can run tomorrow
Strip this down and the working version fits on two pages: a signed awareness policy with a named role, a validated SRP account, a single triage queue, a four-question severity decision, four templates, a product-to-Member-State registry, and a reminder that the three legal clocks don't merge. The SRP will keep changing through ENISA's build-out, and an API may arrive in a later phase, so the runbook owner should re-check field mappings each quarter and after each real filing.
The success state is boring: a credible signal at hour zero, a logged awareness decision by hour four, an early warning filed with margin to spare, users told what to do, and a final report that closes the record. If a signal ever sits in a general inbox past hour four, that is the failure route, and the fix is in Step 2, not in a faster form.
Discussion
Loading discussion…