Resources
What is EU CRA Article 14 for security teams?
Article 14 of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) is the manufacturer reporting duty for actively exploited vulnerabilities and severe incidents affecting products with digital elements — including software and agentic systems placed on the EU market.
Security teams that ship connected products, firmware, cloud-connected software, or AI agents need a reporting and fix workflow before a 24-hour clock starts. This checklist is an operational AppSec guide, not legal advice. It focuses on evidence, notification, user impact, and remediations that preserve product intent. An SBOM helps name components; it does not replace Article 14 evidence.
Essentials checklist
- 1
Confirm whether you are the manufacturer
Identify who places the product with digital elements on the EU market and where cybersecurity decisions are taken. Article 14 notifications are submitted via the single reporting platform to the coordinating CSIRT of the manufacturer's main establishment in the Union (or the designated path if you have no EU establishment).
- 2
Stand up a 24 / 72 / final-report clock
For an actively exploited vulnerability: early warning without undue delay and within 24 hours of becoming aware; a vulnerability notification within 72 hours with product, exploit, and mitigation detail; a final report no later than 14 days after a corrective measure is available. For a severe incident impacting product security: early warning within 24 hours, incident notification within 72 hours, and a final report within one month.
- 3
Define 'becoming aware' for agentic and connected products
Write down how you detect active exploitation and severe incidents: customer reports, runtime telemetry, MCP or agent tool abuse, SBOM/CVE feeds, and CSIRT notices. Agentic software can be exploited through tools and context as well as classic CVEs, so include prompt-injection, credential theft, and unsafe tool execution in the intake path.
- 4
Treat the SBOM as inventory, not the Article 14 packet
Keep an SBOM so you can name versions and affected components. Do not file the SBOM as proof you handled an exploited vulnerability. The packet still needs awareness timestamps, exploit or incident nature, mitigations, user notices, and a path to a shipped corrective measure.
- 5
Prepare the single reporting platform packet
Draft the fields you will need under pressure: product identity and versions, Member States where you know the product is available, nature of the exploit or incident, sensitivity of the information, mitigations already taken, and mitigations users can apply. Route the packet to CSIRT and ENISA through the CRA single reporting platform — not a one-off email thread.
- 6
Notify affected users, then all users where appropriate
Article 14 also requires informing impacted users and, where appropriate, all users about the vulnerability or incident and the measures they can take. Pair the regulatory notice with a product advisory that states what changed, what did not change, and how to update safely.
- 7
Collect runtime evidence, not only scanner tickets
Keep logs that show which agent or tool was involved, what was blocked, and when. Scanner theater — open findings with no runtime trail — is what fails customer and auditor reviews. Gateway in your network is built to export that operational evidence.
- 8
Map each in-scope finding to a reviewable PR
Reporting without a shippable fix leaves users exposed. Capture the finding, write a constrained fix spec (behavior that must stay the same), and land a reviewable change. For agentic products, the spec should cover tool permissions, MCP server config, and workflow logic — not only library bumps. Finding → Fix Spec → PR is a scoped remediation POC; Gateway self-serve is the log and control plane.
- 9
Retain evidence for the support period
Store awareness timestamps, report copies, user notices, and the diffs that remediated the issue. CRA vulnerability handling is broader than Article 14, but this evidence is what you will need when a CSIRT, auditor, or customer asks how you responded.
Frequently asked questions
- What is EU CRA Article 14 for security teams?
- For security teams, Article 14 of Regulation (EU) 2024/2847 is the operational reporting clock: when you become aware of an actively exploited vulnerability or a severe incident affecting a product with digital elements, you notify through the CRA single reporting platform, inform users, and keep evidence of what you knew and what you shipped. It is a manufacturer duty, not a scanner feature.
- What is Article 14 of the EU Cyber Resilience Act?
- Article 14 of Regulation (EU) 2024/2847 requires manufacturers of products with digital elements to notify actively exploited vulnerabilities and severe security incidents. Reports go through the CRA single reporting platform to the coordinating CSIRT and ENISA, with early warning, follow-up, and final-report deadlines.
- When do CRA reporting obligations apply?
- The European Commission states that manufacturers must report actively exploited vulnerabilities and severe incidents from 11 September 2026. Broader CRA product requirements have later application dates. Confirm the current official timeline for your product category rather than treating any vendor page as legal advice.
- Does an SBOM satisfy CRA Article 14?
- No. An SBOM is a software inventory. Article 14 is a reporting duty for actively exploited vulnerabilities and severe incidents, plus user notification and a corrective measure. An SBOM can help you name versions in a packet; it does not prove awareness time, what you blocked, whom you notified, or that a fix shipped. See Does an SBOM satisfy CRA Article 14?
- What vulnerability-handling evidence do CRA auditors expect?
- AppSec teams should expect to show: when you became aware, which product and version, what the exploit or incident was, what you blocked or mitigated, copies of reports and user notices, and the pull request that implemented the corrective measure. Ticket dumps and scanner PDFs without timestamps or shipped diffs are usually not enough. This is practical evidence, not a legal determination of CRA scope.
- CRA vs scanner theater — what fails audits?
- Scanner theater is a backlog of findings with no awareness clock, no runtime trail, and no merged fix. Audits fail when you cannot show what happened on the agent or product, what you notified, and which reviewable change closed the issue. Open CVE counts are not Article 14 evidence.
- How does CRA readiness map to remediation PRs?
- Readiness is not a slide. Each in-scope finding should become a constrained fix spec and a pull request you can cite as the corrective measure. Gateway can keep the runtime log; Finding → Fix Spec → PR is a scoped remediation POC, not the self-serve Gateway SKU.
- Does agentic software count as a product with digital elements?
- If you place software on the EU market that includes data processing, remote connectivity, or AI agent features, it can fall in scope as a product with digital elements. Agentic products that call tools, MCP servers, or external APIs still need vulnerability handling, incident reporting, and a way to ship security fixes without breaking intended behavior. Have counsel classify your product.
- Is this checklist a guarantee of CRA compliance?
- No. This is an operational checklist for security and product teams. Compliance depends on your legal classification, conformity assessment, support period, and documentation. Use it to prepare reporting and remediation workflows; have counsel review your specific obligations.
Keep CRA-ready logs in Gateway
Start free on Gateway to log and export evidence for vulnerability handling and Article 14-style duties. Talk to us for Enterprise retention and CRA readiness help. Remediation PRs are a scoped POC, not the self-serve SKU.