Cyber Resilience Act Vulnerability Handling: A Coordinated Disclosure Process for Vendors
Most teams tracking the Cyber Resilience Act have December 2027 circled in their calendar. That is the wrong date to worry about first. The CRA vulnerability disclosure and reporting obligations apply from 11 September 2026, which at the time of writing is three months away. From that day, every manufacturer of a product with digital elements on the EU market must report actively exploited vulnerabilities to ENISA and their national CSIRT within 24 hours of becoming aware of them. No CE mark is required yet. No conformity assessment. Just a working process, a security contact, and the ability to move fast when a researcher or an attacker finds something.
This post is a practical guide to building that process. If you want the bigger picture of the regulation, scope and CE marking timeline first, start with our overview of the Cyber Resilience Act and come back.
The September 2026 deadline most vendors are ignoring
The CRA (Regulation (EU) 2024/2847) phases in over three years. The substantive product requirements of Annex I Part I, the essential cybersecurity requirements, become enforceable together with CE marking on 11 December 2027. But Article 14, the reporting obligation for actively exploited vulnerabilities and severe incidents, applies from 11 September 2026.
That sequencing is deliberate. The legislator wanted the ecosystem-level early warning system running before the product-level requirements bite. The practical consequence for vendors is that the first CRA obligation you can actually fail is not a missing CE mark. It is a missed reporting deadline measured in hours, with fines for non-compliance with reporting duties reaching up to EUR 10 million or 2 percent of worldwide annual turnover.
A process you design in a panic after your first exploited vulnerability will not meet a 24-hour clock. One you design this quarter will.
What CRA vulnerability disclosure actually requires
Annex I Part II of the CRA lists the vulnerability handling requirements. Stripped of legal phrasing, manufacturers must:
- Identify and document vulnerabilities and components, including drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies of the product.
- Remediate without delay, and deliver security updates free of charge. For consumer products, updates must be separable from feature updates where technically feasible, so users are not forced to accept new functionality to get a fix.
- Test regularly. Effective and regular tests and reviews of product security are a standing duty, not a one-off pre-release gate.
- Publicly disclose fixed vulnerabilities once a security update is available, including a description of the vulnerability, its severity, and remediation guidance. Disclosure may be delayed only where the security risk of publishing outweighs the benefit.
- Operate a coordinated vulnerability disclosure (CVD) policy and provide a contact address where anyone, researcher or customer, can report vulnerabilities in your product.
- Distribute updates securely and ensure that mechanisms for distributing them protect integrity, so a compromised update channel does not become the vulnerability.
None of these are exotic. Together they describe what mature product security teams already do. The difference is that from 2027 they are auditable legal requirements, and the reporting layer on top of them arrives in 2026.
The reporting clock: 24 hours, 72 hours, 14 days
Article 14 sets up a three-stage reporting cascade for any actively exploited vulnerability in your product:
| Stage | Deadline | Content |
|---|---|---|
| Early warning | 24 hours from awareness | That exploitation is happening; which member states are affected if known |
| Vulnerability notification | 72 hours from awareness | General details, severity, exploitation status, corrective measures available or planned |
| Final report | 14 days after a corrective measure is available | Description, root cause where available, mitigation, and information on the update |
A parallel cascade applies to severe incidents having an impact on the security of the product, with the final report due one month after the incident notification. Reports go through the single reporting platform operated by ENISA, which routes them to the CSIRT designated as coordinator in your member state. For a vendor established in Germany, that is BSI.
Two details trip teams up. First, the clock starts when you become aware, not when you have finished investigating. The early warning is allowed to be thin; that is the point. Second, "actively exploited" includes exploitation of your product at a single customer. You need telemetry or support escalation paths good enough that exploitation reports reach the people who own the reporting duty, fast.
Building a coordinated disclosure process that holds up
A CVD process that satisfies the CRA has four parts. Most vendors can stand up all four in a quarter.
1. Publish a policy and a contact
Write a CVD policy and put it where researchers look: a /.well-known/security.txt file, a security page on your website, and a SECURITY.md in any public repository. The policy should state what is in scope, how to report (a dedicated mailbox such as security@ your domain, or a submission form), what reporters can expect from you and when, and that you will not pursue legal action against good-faith research. Commit to an acknowledgement deadline you can actually meet; 48 hours is a common and defensible choice.
2. Intake and triage
Every report needs an owner within one business day. Define a triage rota, a severity scheme (CVSS is the de facto standard and maps cleanly onto the CRA severity language), and one critical branch question: is there evidence of active exploitation? If yes, the Article 14 clock is running and the report escalates immediately to whoever files ENISA notifications. That person, and their deputy, should be named in the process document, not discovered during the incident.
3. Remediation SLAs
Annex I says "without delay", which auditors and notified bodies will read against your own documented targets. Typical defensible SLAs are 14 days for critical, 30 for high, 90 for medium and low. What matters more than the exact numbers is that you track them and can show the history. If your codebase makes a 14-day turnaround for a critical fix unrealistic, that is an engineering problem dressed up as a compliance problem, and it is worth an honest look at code quality and architecture before September rather than after.
4. Advisories and disclosure timing
Once the fix ships, publish an advisory: affected versions, severity, the fix version, and workarounds if updating is hard. Coordinate timing with the reporter; 90 days from report to publication is the convention researchers expect. If your product is a component other manufacturers build on, notify downstream integrators before public disclosure, because under the CRA they have their own obligations triggered by yours.
SBOM: the prerequisite that makes everything else possible
Every step above gets faster with an accurate SBOM and nearly impossible without one. When the next Log4Shell-class disclosure lands, "are we affected?" must be a query, not an archaeology project. Generate SBOMs in CycloneDX or SPDX format as part of CI on every release, store them per released version, and wire dependency scanning to them so new CVEs in shipped versions raise alerts automatically. The CRA only mandates top-level dependency coverage, but transitive coverage is what actually answers the question, and the tooling cost of including it is close to zero.
What this means for SaaS teams
Pure SaaS is mostly NIS2 territory, but CRA compliance for SaaS vendors becomes real the moment you ship anything installable: a desktop agent, a mobile app, a CLI, an SDK, a self-hosted edition. Those artifacts are products with digital elements, and their vulnerability handling falls under the CRA even while your cloud backend does not. The pragmatic move is to run one CVD process covering everything you ship, cloud and installable alike. A single intake, one severity scheme, one advisory format. Splitting processes by regulation multiplies the chances that the one report that mattered lands in the wrong queue.
If you are building new installable components now, design the update channel, SBOM generation and telemetry hooks in from the start. Retrofitting them is exactly the kind of work that competes badly against feature pressure, and it is where an experienced development partner earns their keep.
A 90-day plan to be ready by September
- Weeks 1 to 2: Name the process owner and deputy. Register for the ENISA reporting platform pathway via your national CSIRT. Create security@ and
security.txt. - Weeks 3 to 6: Write and publish the CVD policy. Define severity scheme, triage rota and remediation SLAs. Add SBOM generation to CI.
- Weeks 7 to 10: Wire exploitation signals: support escalation keywords, crash and auth anomaly alerts, researcher intake. Draft advisory and ENISA report templates so nobody writes from a blank page at hour 20.
- Weeks 11 to 13: Run a tabletop exercise: a researcher reports an actively exploited deserialization bug on a Friday evening. Walk the full chain from intake to 24-hour early warning to advisory. Fix what breaks.
FAQ
Do the September 2026 duties apply to products shipped before that date? Yes for reporting. Article 14 applies to actively exploited vulnerabilities in products you have on the market, regardless of when they were placed there.
Does an open-source dependency vulnerability trigger a report? Only if it is actively exploited in your product. But your Annex I duties from 2027 mean you must still remediate it without delay, which is why the SBOM pipeline matters now.
Can we outsource the process? You can outsource intake and triage to a platform or partner, but the legal duty and the reporting deadlines stay with the manufacturer.
Wolf-Tech helps SaaS vendors and software teams get audit-ready: vulnerability handling processes, SBOM pipelines, and the code-level fixes that make 14-day remediation SLAs achievable. If the September deadline is closer than your process maturity, write to hello@wolf-tech.io or visit wolf-tech.io for a first conversation.