The Cyber Resilience Act (CRA) introduces stringent vulnerability handling obligations for all Products with Digital Elements (PDEs). Under Annex I, Part II, manufacturers must implement continuous processes for identifying, assessing and remediating vulnerabilities throughout the support period of their product, and Article 14 adds the duty to report actively exploited ones.
This guide provides a detailed technical interpretation of every vulnerability handling requirement under the CRA, including reporting timelines, remediation expectations and documentation duties under Annex VII. If your product includes software, firmware or connectivity, these obligations apply to you.
Part of our guide to all 22 CRA essential requirements in Annex I.
1. What Vulnerability Handling Means Under the CRA
In the context of the Cyber Resilience Act, vulnerability handling refers to a structured, documented and continuous set of activities that ensure a product remains secure throughout its supported lifetime. These activities must include:
- Continuous vulnerability identification (internal + external sources)
- Assessment and prioritization based on risk and exploitability
- Mitigation and remediation without delay, in relation to the risks
- Secure deployment of patches and updates
- Communication of vulnerabilities to users when necessary
- Mandatory reporting of actively exploited vulnerabilities
- Record-keeping under Annex VII
This is more than a “best practice”: it is a legal obligation that applies to all manufacturers under the CRA.
In Regulus, free for manufacturers: work through all 22 Annex I requirements, each with its evidence.
2. Legal Basis: Where Vulnerability Handling Appears in the CRA
The CRA integrates vulnerability handling across several sections:
2.1 Annex I – Essential Cybersecurity Requirements
Part II mandates:
- Processes for handling vulnerabilities, including an SBOM and a coordinated vulnerability disclosure policy
- Mechanisms for secure update delivery
- Regular security testing and reviews
- Communication obligations toward users
2.2 Article 14 – Reporting Obligations
Manufacturers must report:
- Actively exploited vulnerabilities
- Severe incidents having an impact on the security of the product
Reports must follow strict timelines and have applied since 11 September 2026.
2.3 Annex VII – Technical Documentation
Annex VII requires the technical documentation to describe the vulnerability handling processes, including:
- The software bill of materials
- The coordinated vulnerability disclosure policy
- Evidence of a contact address for reporting vulnerabilities
- The technical solutions chosen for the secure distribution of updates
This documentation must be provided to authorities upon request.
Keep the 24-hour, 72-hour and final report deadlines in one place
Record a vulnerability or incident in Regulus and it works out each deadline, what goes in each report and what you have already sent to ENISA. Free for manufacturers.
3. CRA Vulnerability Handling Requirements (Annex I, Part II)
Below is a breakdown of each obligation in Annex I, Part II.
3.1 Continuous Vulnerability Identification
Manufacturers must continuously monitor:
- Internal testing and QA findings
- User-reported vulnerabilities
- Threat intelligence feeds
- Open-source vulnerability disclosures (for SBOM components)
- Supplier and third-party advisories
This implies the need for a formal intake process and a designated security contact point.
3.2 Assessment and Prioritization
Every identified vulnerability must be evaluated based on:
- Severity (CVSS or equivalent)
- Exploitability (public exploit, active exploitation)
- Impact (confidentiality, integrity, availability)
- Exposure (network vs local)
The CRA does not mandate CVSS specifically, but requires a structured and repeatable assessment methodology.
3.3 Remediation and Mitigation
Manufacturers must:
- Address and remediate vulnerabilities “without delay”, in relation to the risks they pose
- Apply temporary mitigations when necessary
- Document remediation decisions
Critical vulnerabilities, or those with active exploitation, require accelerated handling.
3.4 Deployment of Security Updates
Under CRA, updates must be:
- Delivered securely (for example signed and authenticated) and, where applicable, automatically
- Disseminated without delay and free of charge, with advisory messages for users
- Separate from functionality updates where technically feasible
Keeping a version history and a record of how each update was validated is good practice, and it is what you will use to show authorities that the process works.
3.5 User Notification Requirements
In certain scenarios, manufacturers must inform users:
- When a vulnerability is actively exploited or a severe incident occurs, together with any mitigation users can deploy (Article 14(8))
- When a security update is released, through advisory messages that explain any action users need to take
- Once a fix is available, by publicly disclosing information about the fixed vulnerability; in duly justified cases this can wait until users have had the chance to patch
4. Reporting Obligations: Vulnerabilities & Incidents
The CRA requires manufacturers to report:
4.1 Actively Exploited Vulnerabilities
If a vulnerability is being exploited in the wild, the manufacturer must notify, simultaneously and through the single reporting platform:
- ENISA
- The CSIRT designated as coordinator in the Member State of its main establishment
Article 14 sets the deadlines: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.
4.2 Severe Incidents
Manufacturers must report, on the same 24-hour and 72-hour clock and with a final report within one month, any incident having an impact on the security of the product that:
- Affects, or could affect, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions
- Has led, or could lead, to the introduction or execution of malicious code in the product or in the user’s network and information systems
5. Documentation Obligations (Article 13 and Annex VII)
Article 13 requires manufacturers to systematically document the vulnerabilities they become aware of, and Annex VII requires the technical documentation to describe the vulnerability handling processes. In practice that means keeping:
- A vulnerability register
- Assessment and prioritization records
- Mitigation steps taken
- Update verification logs
- Incident reports and timelines
The technical documentation must be kept for at least 10 years after the product is placed on the market, or for the support period if that is longer.
6. Vulnerability Handling Workflow (Recommended)
- Receive vulnerability report
- Validate and acknowledge
- Assess severity and risk
- Define mitigation or remediation plan
- Develop and test the patch
- Deploy securely to devices/users
- Document all actions
- Report exploited vulnerabilities
This workflow ensures full alignment with Annex I and Annex VII.
7. Relationship with SBOM and Supply Chain Security
Vulnerabilities in third-party libraries and open-source components (SBOM items) are the responsibility of the manufacturer, who must also report them to whoever maintains the component. You must:
- Monitor SBOM components for new CVEs
- Update libraries when fixes become available
- Document remediation
The SBOM must cover at least the top-level dependencies, and ignoring the vulnerabilities in those components puts you in breach of the vulnerability handling requirements.
8. Common Compliance Mistakes to Avoid
- No formal intake process for vulnerability reports
- Missing or incomplete vulnerability register
- No evidence of update validation
- Failure to monitor SBOM components
- Not documenting mitigations
- No post-market monitoring plan
- Not reporting exploited vulnerabilities
9. How Regulus Helps
Regulus, free for manufacturers, helps you organise vulnerability handling with:
- A vulnerability register with the Article 14 deadlines worked out for you
- SBOM import in CycloneDX format
- An Annex I checklist, requirement by requirement
- A cybersecurity risk assessment for each product
- The nine documents of the pack, in Word
Try the CRA Applicability Checker to determine requirements for your product.
Conclusion
Vulnerability handling is one of the most operationally complex aspects of CRA compliance. Manufacturers must adopt continuous monitoring, structured remediation processes, secure update mechanisms and strong documentation practices. Reporting has applied since 11 September 2026; the rest of the vulnerability handling requirements apply from 11 December 2027.
For templates and workflows, explore: Cyber Resilience Act Resources
