Since 11 September 2026, software makers must report actively exploited vulnerabilities within 24 hours. What that changes for the vendors you buy from, and what to ask them now.
A Tuesday morning advisory
A security team learns from a public advisory that a file-transfer product used by three of their departments has a vulnerability being exploited in the wild. They email the vendor. The reply, two days later, is a link to a patch note.
Since 11 September 2026, that vendor has a legal clock of its own if it makes the product available in the EU. Under the Cyber Resilience Act, it has to warn the authorities within 24 hours of becoming aware of an actively exploited vulnerability, and it has to tell the people using the product what to do. Buyers can now ask how that process works before the next advisory, not after it.
What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets cybersecurity requirements for products with digital elements made available on the EU market: hardware and software products, including their remote data processing solutions. It entered into force on 10 December 2024 and applies in stages.
The obligations fall on the manufacturer, meaning the company that develops or has the product developed and markets it under its own name, with lighter duties for importers and distributors. If you buy software or connected devices, your vendors are the ones in scope. You are not, unless you also put such products on the market yourself.
What has applied since 11 September 2026?
Article 14, the reporting obligation. A manufacturer must notify any actively exploited vulnerability in its product, and any severe incident affecting the security of the product, through the single reporting platform run by ENISA. The notification goes to the CSIRT designated as coordinator in the relevant Member State and to ENISA.
Article 69(3) makes the reporting obligation apply to all products in scope, including those placed on the market before 11 December 2027. Older products you already run are covered; there is no grandfathering for reporting.
What are the reporting deadlines?
For an actively exploited vulnerability, Article 14(2) sets three steps:
- Early warning: without undue delay and in any event within 24 hours of the manufacturer becoming aware of it.
- Vulnerability notification: within 72 hours, with general information about the product, the nature of the exploit and the vulnerability, and any corrective or mitigating measures taken or that users can take.
- Final report: no later than 14 days after a corrective or mitigating measure is available, including a description of the vulnerability, its severity and impact, and the security update or other measure released.
What about severe incidents and the users?
For a severe incident having an impact on the security of the product, the clocks are 24 hours for an early warning, 72 hours for an incident notification, and one month after that notification for a final report.
Article 14(8) adds the part buyers feel most: after becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform impacted users, and where appropriate all users, about it and about any risk mitigation and corrective measures they can deploy, where appropriate in a structured, machine-readable format that is easy to process automatically. In practice, that is the message your security team should be receiving.
Which of your vendors are in scope?
Most installed software, firmware, agents, desktop and mobile apps, and connected devices sold in the EU fall under the CRA. Pure software-as-a-service generally does not, because the CRA covers remote data processing only where it is part of a product with digital elements and needed for one of its functions. Products covered by their own sectoral rules, such as medical devices and motor vehicles, are also excluded.
So the question is not only whether a vendor is in scope, but which of its products are. A SaaS provider with a desktop client, a browser extension or an on-premise agent may have part of its offering covered. For services outside the CRA, NIS2 and DORA remain the frameworks that reach them through your contracts; our earlier posts on NIS2 supply chain security and the DORA Article 30 checklist cover those.
What arrives on 11 December 2027?
The main obligations: the essential cybersecurity requirements in Annex I, conformity assessment and the CE marking for products placed on the market from that date. Annex I Part II sets the vulnerability handling requirements, including documenting the components of the product, drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies, having a coordinated vulnerability disclosure policy, and providing security updates without delay, where technically feasible separately from feature updates.
Article 13(8) requires manufacturers to set a support period that reflects how long the product is expected to be used, and in principle at least five years, during which vulnerabilities are handled. That end date has to be stated clearly at the time of purchase.
What should buyers ask software suppliers now?
None of this needs a new questionnaire. Add a few questions to the vendor reviews you already run for software and devices:
- Which of your products, versions and components are in CRA scope, and who is the manufacturer for each?
- How do you detect actively exploited vulnerabilities, and who owns the 24-hour early warning?
- How and where will you inform us as users, and can we receive advisories in a machine-readable format?
- Can you provide an SBOM for the product we use, at least for top-level dependencies? (The CRA requires manufacturers to draw it up; sharing it with customers is their choice, so ask.)
- What is the support period for our version, and when does it end?
- Do you ship security updates separately from feature releases, and how do we get notified?
- Does our contract require you to notify us of exploited vulnerabilities and incidents, and within what time?
Why put it in the contract as well?
The CRA duty runs from the manufacturer to the authorities and to users in general. It does not give you, the buyer, an individual right to a timeline, a contact or a remediation plan. A notification clause, a defined support period and an obligation to provide security updates turn the regulation's minimum into something you can enforce. If you are a financial entity, the incident and notification terms in your DORA Article 30 contract review are the natural place for it.
What to prepare if you are the vendor being assessed
- A list of your products and versions with their CRA scope status and declared support periods.
- A written process for the 24-hour, 72-hour and final reports, with a named owner and access to the single reporting platform.
- A customer advisory template and a channel to reach impacted users quickly, ideally machine-readable.
- An up-to-date SBOM and a decision on how you share it with customers.
- A published coordinated vulnerability disclosure policy and a single point of contact for vulnerability reports.
See how vendor documents turn into findings
The ProcureCortex demo at procurecortex.com/explore (self-serve: email sign-in link, no sales call) shows vendor reviews where each finding points to the document and clause it came from, with a recorded reviewer decision. All vendors and findings in the demo are sample data, and the demo labels findings against SOC 2, ISO 27001, GDPR and contract clauses; mapping them to the CRA is your own team's analysis.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14, 69 and 71, Annex I: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- European Commission, Cyber Resilience Act: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- Directive (EU) 2022/2555 (NIS2): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulation (EU) 2022/2554 (DORA), Article 30: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Get the vendor review guide
One email a month with a worked example like this one. Nothing else.