Zero-days and the CRA 24-hour early warning: a manufacturer workflow

Under Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847), a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements must send an early warning within 24 hours, a vulnerability notification within 72 hours, and a final report no later than 14 days after a fix or mitigation is available, all through ENISA's Single Reporting Platform. That obligation has applied since 11 September 2026, and it covers products already on the market. The workable answer for a zero-day is a rehearsed workflow that turns "is this in our product, and where did we ship it?" into a minutes-long lookup, so the 24 hours go to judgement and drafting rather than to searching spreadsheets.

This post lays out that workflow phase by phase, from the moment an exploitation signal lands to the final report, and shows where Safeguard helps on the response side: knowing which products and versions contain an affected component, ranking what is reachable, blocking vulnerable builds, opening fix pull requests and publishing machine-readable exploitability statements. It also says plainly what Safeguard does not do, starting with this: Safeguard does not file your notification for you, and it does not decide for you whether a vulnerability meets the legal test.

Key takeaways

• The clock is short and it is already running. Article 14 applies from 11 September 2026, more than a year before the rest of the CRA applies on 11 December 2027, and it reaches products placed on the market before that date.
• Three deadlines for an exploited vulnerability: an early warning within 24 hours of awareness, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
• Severe incidents run on a parallel track: 24 hours, 72 hours, then a final report within one month of the incident notification.
• Users must be told too. Article 14(8) requires informing impacted users, and where appropriate in a structured, machine-readable format.
• Most manufacturers will meet zero-days through their components. A publicly reported exploited flaw in a library or base image you ship can be the trigger, which makes component inventory the first thing you need at hour zero.
• Safeguard capabilities used in this workflow, all GA: SBOM generation and analysis, SCA and vulnerability management with EPSS and CISA KEV signals, reachability analysis, policies and gates, autonomous remediation (ships switched off, every category set to Manual), CSAF and VEX upload, the Safeguard CLI, and the Safeguard connector in Claude and ChatGPT directories. Gold Open Source is free.
• What stays with you: the legal determination, the Single Reporting Platform submission, the content of the notifications, the fix for code you wrote and the decision to tell users.

What Article 14 actually requires

The binding text is the Official Journal version of Regulation (EU) 2024/2847. EUR-Lex returned an automated challenge page with no content to our command line fetch on 25 October 2026, so the quotations and clause numbers in this post come from the EUR-Lex HTML of the regulation as archived by the Internet Archive on 1 January 2026. The text is the published regulation; check the live EUR-Lex page before you rely on any wording in a contract or a policy.

Actively exploited vulnerabilities: Article 14(1) and 14(2)

Article 14(1) says a manufacturer "shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of", simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform set up under Article 16.

Article 14(2) then sets three submissions:

1. Early warning, 14(2)(a). Without undue delay and in any event within 24 hours of becoming aware. It must indicate, where applicable, the Member States where the manufacturer knows the product has been made available.
2. Vulnerability notification, 14(2)(b). Unless the information has already been provided, without undue delay and in any event within 72 hours of becoming aware. It gives general information, as available, about the product concerned, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken, corrective or mitigating measures users can take, and how sensitive the manufacturer considers the information to be.
3. Final report, 14(2)(c). Unless already provided, no later than 14 days after a corrective or mitigating measure is available. At least a description of the vulnerability including severity and impact, information about any malicious actor exploiting it where available, and details of the security update or other corrective measures made available.

Two details in that text matter more than they first appear. The 72-hour and 24-hour clocks run from awareness, but the final report clock runs from the availability of a fix or mitigation. A zero-day with no fix for three weeks therefore produces an early warning on day one, a notification by day three, and a final report about five weeks out. And the phrase "unless the relevant information has already been provided" means a thorough early warning can reduce what the later submissions need to repeat, though it never removes the deadlines.

Severe incidents: Article 14(3) to 14(5)

Article 14(3) applies the same simultaneous CSIRT and ENISA routing to "any severe incident having an impact on the security of the product with digital elements". Article 14(4) sets the incident timeline: an early warning within 24 hours that says at least whether the incident is suspected of being caused by unlawful or malicious acts, an incident notification within 72 hours with an initial assessment, and a final report within one month after the incident notification, covering severity and impact, the likely threat or root cause, and applied and ongoing mitigation.

Article 14(5) defines severe. An incident is severe where it 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 where it has led, or is capable of leading, to malicious code being introduced or executed in the product or in a user's network and information systems.

A zero-day can trigger both tracks. If an attacker exploits a flaw in your update server to push code to customer devices, you likely have an actively exploited vulnerability and a severe incident at once. Run the two tracks in one war room, with one timeline document, and decide early whether you are filing one or both.

Intermediate reports, routing and users: Article 14(6) to 14(8)

• 14(6): the CSIRT that first receives the notification may ask for an intermediate report with status updates. Plan for it; do not assume silence between 72 hours and the final report.
• 14(7): notifications go through the single reporting platform using the electronic notification end-point of the CSIRT designated as coordinator in the Member State of your main establishment in the Union. Main establishment means where cybersecurity decisions about your products are predominantly taken; failing that, the Member State with the most employees. A manufacturer with no main establishment in the Union follows a fallback order: where the authorised representative for the most of its products is established, then the importer placing the most of its products on the market, then the distributor, then the Member State with the most users.
• 14(8): after becoming aware, the manufacturer "shall inform the impacted users" and, where appropriate, all users, of the vulnerability or incident and of any risk mitigation and corrective measures they can deploy, "where appropriate in a structured, machine-readable format that is easily automatically processable." If the manufacturer does not inform users in time, the notified CSIRTs may do it themselves.

What "actively exploited" means

Article 3, point (42), defines an actively exploited vulnerability as one "for which there is reliable evidence that a malicious actor has exploited it" in a system without the owner's permission. Three words carry the weight: reliable, evidence and malicious. A proof of concept on a public code host is not exploitation. A researcher's controlled test is not malicious. A rumour on social media is not reliable evidence. A government catalogue listing based on observed exploitation, a vendor advisory that says the flaw is exploited in the wild, your own incident response findings, or a credible threat intelligence report usually is. Your legal team should write down, before an incident, which sources your company treats as reliable evidence, so the decision at hour two is a lookup and not a debate.

When the obligations apply

Article 71(2) says the regulation applies from 11 December 2027, but "Article 14 shall apply from 11 September 2026". Article 69(3), in the transitional provisions, adds that the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027. In other words, the reporting duty covers the products you already sell, not only new ones.

The penalty ceiling

Article 64(2) puts non-compliance with Annex I and with Articles 13 and 14 in the highest fine band: up to EUR 15 000 000 or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 64(10)(a) carves out one thing: administrative fines do not apply to microenterprises or small enterprises for failing to meet the 24-hour early warning deadline in Article 14(2)(a) or 14(4)(a). That is a carve-out from fines for a missed early warning, not an exemption from reporting. Open-source software stewards are outside the fines entirely under Article 64(10)(b).

Article 14 deadlines at a glance

The rest of the CRA that feeds the 24-hour clock

Article 14 does not stand alone. Four other provisions decide whether you can meet it.

Annex I, Part II (vulnerability handling). Manufacturers must identify and document vulnerabilities and components, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies" (point 1); address and remediate vulnerabilities without delay, with security updates separate from functionality updates where technically feasible (point 2); test regularly (point 3); publicly disclose fixed vulnerabilities once an update is out (point 4); put in place and enforce a coordinated vulnerability disclosure policy (point 5); provide a contact address for vulnerability reports (point 6); distribute updates securely, automatically where applicable for security updates (point 7); and disseminate security updates without delay, free of charge in most cases, with advisory messages (point 8).

Article 13(6), components. A manufacturer that identifies a vulnerability in a component, "including in an open source-component", must report it to whoever manufactures or maintains that component and remediate it under Annex I Part II. If the manufacturer writes a fix, it must share the relevant code or documentation with the maintainer, where appropriate in a machine-readable format.

Article 13(7), documentation. Manufacturers must systematically document relevant cybersecurity aspects of their products, including vulnerabilities they become aware of and information from third parties, and update the risk assessment where applicable.

Article 13(8), support period. Vulnerabilities of the product, including its components, must be handled effectively for the support period. A zero-day in a version you still support is your problem even if you stopped selling it.

Article 16, the single reporting platform. ENISA establishes and runs the platform; Member States and ENISA put their own electronic notification end-points on it. The receiving CSIRT disseminates the notification to the CSIRTs of the Member States where you said the product was made available. Dissemination can be delayed in exceptional circumstances on justified cybersecurity grounds, including at the manufacturer's request in light of the sensitivity it indicated, and Article 16(2) lists "particularly exceptional circumstances" in which only limited information goes to ENISA at first. Article 16(3) sends the notified information on to market surveillance authorities.

How ENISA describes the Single Reporting Platform

ENISA's SRP page describes the platform as the online tool ENISA develops, operates and maintains so manufacturers, and once applicable open-source software stewards, can meet their CRA reporting obligations. It states that from 11 September 2026 manufacturers are required to submit the mandatory notifications through the SRP, and that the platform lets users "report once through a single platform." The page links to user registration guidance for Assigned Representatives (ARs), guidance on notification submission and update, guidance on particularly exceptional circumstances, a user manual, a glossary of SRP data fields, terms and conditions, a platform status page and the list of CSIRTs designated as coordinators. It also notes that on 20 October 2026 the SRP was upgraded to version 1.2.1, with a different process for inviting secondary Assigned Representatives or backups.

Two practical points follow. Register and assign roles before an incident, not at hour 20. And build your templates from ENISA's glossary field names, not from a summary. We cover the platform itself in more detail in ENISA's CRA single reporting platform, and the article by article reading of the reporting duty in CRA Article 14 reporting: the 24 and 72 hour deadlines. This post is about the operational workflow behind those filings when the trigger is a zero-day.

Why zero-days make 24 hours hard

A zero-day, in the definition Google Threat Intelligence Group (GTIG) uses, is a vulnerability maliciously exploited in the wild before a patch was publicly available. By definition you learn about it late, often from someone else, and without a fix to point users at.

The numbers are not falling. GTIG tracked 75 zero-day vulnerabilities exploited in the wild in 2024, down from 98 in 2023 but up from 63 in 2022, and describes the trend as gradual growth. The mix matters for manufacturers: GTIG reports that 44% of 2024 zero-days targeted enterprise products, up from 37% in 2023, with security and networking software and appliances accounting for over 60% of enterprise zero-day exploitation. If you build appliances, gateways, agents or management software, you are in the part of the market where exploitation is growing.

Google Project Zero's "0-days In-the-Wild" project keeps a public tracking sheet of detected zero-day exploits and publishes root cause analyses for many of them.

CISA's Known Exploited Vulnerabilities (KEV) catalog describes itself as the authoritative source of vulnerabilities that have been exploited in the wild. For CRA purposes it is one strong input to the "reliable evidence" question, though not the only one, and not a legal definition. KEV entries now point federal agencies to Binding Operational Directive 26-04, issued on 10 June 2026, "Prioritizing Security Updates Based on Risk", which supersedes and revokes BOD 22-01 and sets risk-based remediation timelines in its Table 1; the fixed two-week style deadlines of 22-01 are history, not current guidance. KEV due dates apply to US federal agencies, not to CRA manufacturers.

FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and publishes a score every day for every CVE. EPSS is a prediction, not evidence of exploitation, so a high EPSS score alone does not trigger Article 14. It is useful for the other side of the problem: deciding which non-exploited vulnerabilities to fix first so fewer of them become your next Article 14 case.

The awkward fact for most software manufacturers is that the zero-days that reach them are rarely in code they wrote. They are in an open source library, a vendored SDK, an operating system package inside a container image, or a firmware component. When the evidence arrives, the first question is "do we ship this, in which products, versions and Member States?" That question is where most of the 24 hours disappear.

A zero-day workflow for the Article 14 clock

The phases below are a template, not legal advice. Adapt them with your counsel and your PSIRT. Times are hours from the moment your organisation became aware, which is the moment your legal team should be able to name and defend.

Phase 0: before any zero-day (readiness)

Everything that can be done in advance should be.

1. Register on the SRP and assign roles. Follow ENISA's AR registration guidance, assign a primary Assigned Representative and backups, and confirm they can log in.
2. Fix your CSIRT routing in writing. Using Article 14(7), record which Member State is your main establishment, or the fallback order if you have none in the Union, and which CSIRT designated as coordinator that points to, from ENISA's published list.
3. Know where each product was made available. The early warning asks for Member States where applicable. Sales and distribution data should map product and version to Member State, and it should be queryable at 3 a.m.
4. Keep an SBOM per released version. Annex I Part II point 1 requires at least top-level dependencies. For zero-day response you want the full transitive tree, because exploited flaws often sit several layers down.
5. Write down your "reliable evidence" sources. Decide which feeds and advisories your company treats as evidence of active exploitation, and who signs off.
6. Pre-draft templates. An early warning, a vulnerability notification, a final report, a user advisory and an incident early warning, each mirroring the SRP glossary fields.
7. Publish a CVD policy and a security contact. Annex I Part II points 5 and 6. Some zero-days will arrive as a report to that address.
8. Choose your machine-readable user channel. Article 14(8) points at structured, machine-readable formats where appropriate. CSAF advisories and VEX statements are the common open formats for this.
9. Rehearse. Run a tabletop with a fictional exploited component and time each phase.

Phase 1: hour 0 to 2, intake and the two questions

A signal arrives: a KEV addition, a vendor or maintainer advisory saying a flaw is exploited in the wild, a CSIRT contact, a customer report, or your own detection. Open an incident record, timestamp it and assign an owner. Then answer two questions in order.

Question 1: is the vulnerable component or code contained in any product we have made available? This is an inventory question. If the answer is no, record the evidence and close. If yes, carry on.

Question 2: is there reliable evidence of malicious exploitation? Apply your written source list. If the evidence is only a proof of concept or a high EPSS score, record that, treat it as a high priority fix, and keep watching; it may become an Article 14 case later, at which point the awareness clock starts.

The trap in this phase is starting the clock without noticing. If an engineer saw the advisory at 09:00 and the PSIRT heard at 15:00, your counsel needs to decide which time is awareness. Record both.

Phase 2: hour 2 to 12, scope and exposure

Now you need the facts the early warning and the notification will ask for.

1. Products and versions. Every product and supported version that contains the affected component at an affected version. Include versions still in their support period even if no longer sold (Article 13(8)).
2. Member States. Where each affected product has been made available.
3. Reachability and configuration. Whether your product actually calls the vulnerable code path, and whether the vulnerable feature is enabled by default. This shapes the user measures you will recommend. It does not decide whether you report: a vulnerability that is exploited and contained in your product is reportable on the plain text even if you believe your configuration blocks it, so get counsel's view before relying on unreachability.
4. Interim mitigations. Configuration changes, feature flags or network controls users can apply before a fix exists.
5. Fix availability. Whether a fixed upstream version exists, how far it is from your pinned version, and what it would take to ship.

Phase 3: hour 12 to 24, the early warning

Draft and submit the early warning through the SRP using your coordinator CSIRT's end-point. Keep it factual and short. At minimum it should identify the product, state that you are aware of an actively exploited vulnerability, and list the Member States where you know the product has been made available. Add the sensitivity indication if you intend to ask for delayed dissemination under Article 16(2).

Phase 4: hour 24 to 72, the vulnerability notification and users

The notification under 14(2)(b) needs general information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures you have taken, measures users can take, and your sensitivity assessment. In parallel, prepare the user communication required by Article 14(8): who is impacted, what they should do now, and where to watch for the update. Publish it in a human-readable advisory and, where appropriate, in a machine-readable format users can process automatically.

If the CSIRT asks for an intermediate report under 14(6), answer from the same timeline document.

Phase 5: fix, release and the 14-day final report

Ship the security update, separately from functionality changes where technically feasible (Annex I Part II point 2), distribute it securely (point 7) and free of charge with an advisory message (point 8). When the corrective or mitigating measure is available, start a 14-day clock for the final report under 14(2)(c): description, severity and impact, any information on the malicious actor, and details of the update. After the update, disclose the fixed vulnerability publicly under Annex I Part II point 4.

Phase 6: component duties and the record

If the flaw is in a component, report it to the maintainer under Article 13(6) if they do not already know, and share your fix with them if you wrote one. Update your documentation and risk assessment under Article 13(7).

Where Safeguard fits in the workflow

Safeguard is a software supply chain security platform. In this workflow it helps with the inventory, prioritisation, gating, fixing and machine-readable communication around components you build and ship. It does not replace your PSIRT, your counsel or the SRP. Every capability below is generally available (GA).

Step 1: keep an SBOM for every release (SBOM generation and analysis, GA)

Safeguard generates and analyses SBOMs in SPDX and CycloneDX, with many export formats. Connect your repositories, or run the Safeguard CLI (GA) in CI, so every release has an SBOM that covers the full dependency tree, not only top-level dependencies. That covers Annex I Part II point 1 and, more importantly for this post, gives you the inventory you need at hour zero. The SBOM generation and analysis post walks through the formats and the CRA mapping.

Safeguard's docs say it performs daily continuous scanning of all your projects to detect new vulnerabilities as they are disclosed. For zero-day response that matters: the newly disclosed, exploited CVE is matched against SBOMs you already have, rather than waiting for the next build.

Step 2: answer "do we ship it?" in minutes (SCA and vulnerability management, GA)

When the signal lands, open the vulnerabilities view. Safeguard's docs list filters for severity level, EPSS score range, exploitable status, component name, reachability status and CISA KEV. Filter by the component name, or by the CVE once it is published, to see every affected project. Because each project maps to a product and release in your own structure, this gives you the products and versions for Phase 2 directly.

From the CLI, Safeguard's docs describe safeguard scan as the command that builds an SBOM and matches it against vulnerability databases, so a release engineer can check out a specific tagged release and rescan it without waiting for the daily cycle. That is the quickest way to confirm an old, still supported version you no longer build every day.

If your team works in Claude or ChatGPT, install Safeguard from the connector directory (Safeguard is listed in the Claude connector directory as a community connector) and ask the question in plain language: which projects contain this component, and at what versions. The answers come from the same data, scoped to your account. The IDE and connector directory post shows the install route.

Step 3: rank exposure with reachability, EPSS and KEV (reachability analysis, GA)

Safeguard's reachability analysis classifies a vulnerability as reachable, conditionally reachable, unreachable or unknown, using static, dynamic and configuration reachability. Unknown is treated conservatively as potentially reachable. The docs show a priority model in which a reachable, KEV-listed vulnerability in production lands in the top band.

In this workflow, reachability does two jobs. It tells you which of your products are most at risk, so you can sequence fixes and tell users accurately which deployments need urgent action. And it gives your engineers a starting point for the "general nature of the exploit" in your product. It does not, on its own, decide whether Article 14 applies; that is a legal question about whether an actively exploited vulnerability is contained in your product. The prioritisation post covers the scoring in depth.

Step 4: stop new builds from shipping the vulnerable version (policies and gates, GA)

Safeguard policies and gates can block, warn or notify, and a blocked build can go ahead only through an approved exception. During a zero-day, add a rule that blocks builds that include the affected component at an affected version, so you do not ship new copies of the problem while you fix the old ones. You can write the rule in plain English; the policies to release gates post shows how. Start with warn on the first day if blocking would stop an emergency release, then switch to block once the fixed version is available.

Step 5: open the fix pull requests (autonomous remediation, GA, ships off)

When a fixed upstream version exists, Safeguard's Griffin models open tested, policy gated pull requests that move the dependency to the safe version, for one repository or in bulk across every affected project. Autonomous remediation ships switched off, with every category set to Manual, so for a zero-day you would typically trigger the pull requests deliberately and keep human review in the loop. The autonomous remediation post explains the categories and strategies. This shortens Phase 5, which shortens the time until the 14-day final report clock starts and, more importantly, the time your users are exposed.

Step 6: tell users in a machine-readable form (CSAF and VEX upload, GA)

Article 14(8) asks for user information, where appropriate, in a structured, machine-readable format. CSAF advisories and VEX statements are open formats built for this. Safeguard supports CSAF and VEX upload, so the statements you publish ("affected, update to version X", "not affected because the vulnerable code is not present") sit alongside the SBOMs for the products they describe. The VEX and CSAF post covers the workflow. The decision about what each statement says, and whether a "not affected" claim is defensible, stays with you.

Requirement, Safeguard and what you still own

A worked example (illustrative)

The following is a fictional scenario to show the timing. It does not describe any real CVE, product or company.

A manufacturer sells a network management appliance and a companion agent. On a Tuesday at 08:40 Central European Time, an engineer sees a maintainer advisory saying a flaw in a widely used compression library is being exploited in the wild. The PSIRT is told at 09:10. Counsel records 09:10 as awareness, noting the 08:40 sighting.

At 09:20 the PSIRT filters the Safeguard vulnerabilities view by the library's component name. Four projects match: two appliance firmware lines and two agent releases, all still in their support period. Reachability marks the appliance's log upload path as reachable and the agent's use as unreachable. Sales data shows the appliance was made available in eleven Member States.

By 13:00 engineering confirms the vulnerable function is reachable from an authenticated management API on the appliance, and identifies an interim mitigation: disable compressed log upload. A policy is set to warn on any build containing the affected library version, then switched to block once the upstream fix is released at 15:30.

The early warning goes in through the SRP at 16:45 the same day, about seven and a half hours after awareness, naming the product and the eleven Member States. A fix pull request for each affected project is opened from Safeguard at 16:00 and merged after review the next morning. The vulnerability notification, with the general nature of the exploit, the interim mitigation and the upgrade path, goes in on Thursday morning, inside 72 hours. A user advisory and a CSAF document go out the same day; the agent gets a VEX statement explaining why it is not affected in its shipped configuration, after counsel agrees the evidence supports it.

The security update ships on the following Monday. The final report goes in eight days later, inside the 14-day window, and the team sends the library maintainers the small hardening patch it wrote, under Article 13(6).

What Safeguard does not do

• It does not file Article 14 notifications. Safeguard has no connection to ENISA's Single Reporting Platform. Registration, Assigned Representatives, CSIRT routing and every submission are yours.
• It does not make the legal call. Whether a vulnerability is "actively exploited" under Article 3, when your company "became aware", and whether an incident is "severe" under Article 14(5) are legal and factual judgements for your counsel and PSIRT.
• It is not your source of exploitation evidence. In this workflow Safeguard works on the response side, matching publicly disclosed vulnerabilities against your components. The evidence that a flaw is actively exploited comes from advisories, catalogues such as KEV, CSIRTs and your own investigation.
• It does not know where you sold the product. Member State availability comes from your sales and distribution records.
• It does not fix vulnerabilities in code you wrote by itself. Autonomous remediation upgrades dependencies to fixed versions; a flaw in your own source still needs your engineers. And it ships switched off, every category Manual, until you enable it.
• It does not cover hardware or code it cannot see. Components that are not in a repository, build, container image or SBOM connected to Safeguard will not appear in the lookup. Binary-only vendor modules need a supplier SBOM imported, as the supplier SBOM post describes.

Common mistakes

Starting the clock at the wrong time. Teams often treat awareness as the moment the PSIRT opens a ticket. If an engineer or a support agent knew earlier, a regulator may see it differently. Decide your awareness rule in advance and record every timestamp.

Waiting for a root cause before the early warning. Article 14(2)(a) asks for very little: the warning and the Member States. Root cause belongs in the 72-hour notification and the final report.

Treating unreachable as not reportable. Reachability is excellent for prioritising and for user guidance. On the plain text, an actively exploited vulnerability "contained in the product" is reportable. Get counsel's view before using reachability to skip a filing.

Confusing EPSS or a public proof of concept with exploitation. EPSS predicts exploitation in the next 30 days; a proof of concept shows exploitability. Neither is the "reliable evidence that a malicious actor has exploited it" the definition asks for.

Forgetting old versions. Article 13(8) and Article 69(3) both reach products already on the market. If you only keep SBOMs for your latest release, your lookup will miss the versions most likely to be unpatched in the field.

Skipping the user notification. Article 14(8) is a separate duty from the CSIRT notification, and if you do not inform users in time, the CSIRT may do it for you.

Citing BOD 22-01 timelines. BOD 22-01 was revoked and superseded by BOD 26-04. US federal deadlines are not CRA deadlines in any case.

FAQ

When did CRA Article 14 reporting start?

Article 71(2) of Regulation (EU) 2024/2847 makes Article 14 apply from 11 September 2026. The rest of the regulation applies from 11 December 2027, and Chapter IV on notification of conformity assessment bodies applied from 11 June 2026.

What are the CRA reporting deadlines for an actively exploited vulnerability?

An early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours of becoming aware, and a final report no later than 14 days after a corrective or mitigating measure is available, each unless the information has already been provided.

Does the CRA 24-hour rule apply to products already on the market?

Yes. Article 69(3) says the Article 14 obligations apply to all in-scope products placed on the market before 11 December 2027.

What counts as an actively exploited vulnerability under the CRA?

Article 3, point (42), defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A proof of concept or a high EPSS score is not enough on its own.

Where do I submit a CRA vulnerability notification?

Through ENISA's Single Reporting Platform, using the electronic notification end-point of the CSIRT designated as coordinator in the Member State of your main establishment in the Union, or the fallback Member State under Article 14(7). ENISA's SRP page links the registration guidance and the list of coordinator CSIRTs.

Do I have to report a zero-day in an open source library I use?

On a plain reading, Article 14(1) covers any actively exploited vulnerability "contained in the product", which includes components. Article 13(6) separately requires reporting component vulnerabilities to the maintainer. Confirm your reading with counsel.

What are the fines for missing CRA reporting deadlines?

Article 64(2) sets fines of up to EUR 15 000 000 or 2.5% of worldwide annual turnover, whichever is higher, for breaching Article 14. Microenterprises and small enterprises are not subject to fines for missing the 24-hour early warning deadline under Article 64(10)(a), though the duty to report remains.

Can Safeguard submit my CRA report to ENISA?

No. Safeguard helps you find affected products and versions, prioritise, block vulnerable builds, open fix pull requests and publish CSAF and VEX documents. The SRP submission is yours.

Quick check

The fastest way to shorten every phase above is to fix vulnerable components the moment a fixed version exists, and to have a plan for when it does not. The block below is our standard guidance on closing both gaps; it applies to the open source dependencies and container images that most CRA zero-day cases will run through.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a JavaScript repository; the assistant reads the finding and advisory, asks before any command that changes something, edits the manifest, runs the install and tests, prints a summary and pushes nothing, then shows /permissions, /model and /scan .. In a zero-day, the same flow is how an engineer moves an affected component to its fixed version in one supported release line while the PSIRT drafts the notification.

Click through it at your own pace, or open it full screen.

The second demo connects Claude to Safeguard: you add Safeguard from Claude's connector directory, where it has a community listing, sign in with OAuth, and choose which tools Claude can use. Once connected, a PSIRT lead can ask which projects carry a given component version, or which findings are listed in CISA KEV, within the tools the administrator has enabled. That is the Phase 2 scoping question asked in plain language.

Click through it at your own pace, or open it full screen.

The third demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. For manufacturers whose firmware or product source cannot leave their own build network, this is how older supported releases get rescanned during an incident: the scan runs where the code already is, and only results go to the platform.

Click through it at your own pace, or open it full screen.

To try the response side of this workflow on your own repositories, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

Sources

• EUR-Lex: Regulation (EU) 2024/2847, Cyber Resilience Act (Internet Archive copy of the EUR-Lex HTML, 1 January 2026; live EUR-Lex returned an automated challenge to our fetch)
• EUR-Lex: Regulation (EU) 2024/2847, live page
• ENISA: Single Reporting Platform (SRP)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• Google Threat Intelligence Group: Hello 0-Days, My Old Friend, a 2024 zero-day exploitation analysis
• Google Project Zero: 0-days In-the-Wild
• Google Project Zero: 0-days In-the-Wild root cause analyses
• FIRST: Exploit Prediction Scoring System (EPSS)
• CVE Program: Overview
• NIST: National Vulnerability Database dashboard
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Vulnerabilities
• Safeguard docs: Generate SBOM
• Safeguard docs: Software Composition Analysis
• Safeguard docs: CLI
• Safeguard docs
• Gold Open Source
• Safeguard download

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.