What is Annex I Part II?
Annex I Part II of the Cyber Resilience Act defines how manufacturers must handle vulnerabilities in their products—from identification and tracking through remediation and disclosure.
Key Facts
- 8 vulnerability handling requirements
- Applies throughout the support period (minimum 5 years)
- Requires coordinated disclosure processes
- Mandates SBOM maintenance
Together with Annex I Part I (product security), these requirements form the complete security baseline for CRA compliance.
All Part II Requirements
Below are all 8 vulnerability handling requirements from Annex I Part II:
Identify and Document Vulnerabilities
Official Text:
"Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM)."
Plain English:
Maintain a complete inventory of your software components (SBOM) and track all known vulnerabilities affecting them.
Engineering Actions:
- Generate SBOM using CycloneDX or SPDX format
- Integrate SBOM generation into CI/CD pipeline
- Run automated vulnerability scanning against SBOM
- Maintain vulnerability tracking database
Remediate Vulnerabilities Without Delay
Official Text:
"In relation to the risks posed by the vulnerabilities, address and remediate vulnerabilities without undue delay, including by providing security updates."
Plain English:
Fix vulnerabilities promptly based on severity. Critical vulnerabilities require immediate attention; lower severity issues can follow normal release cycles.
Engineering Actions:
- Define SLAs based on vulnerability severity (e.g., Critical: 24-72h)
- Establish emergency patching procedures
- Build rapid deployment capability for security updates
- Track time-to-remediation metrics
Regular Security Testing
Official Text:
"Apply effective and regular tests and reviews of the security of the product with digital elements."
Plain English:
Conduct ongoing security testing—not just at release, but throughout the product lifecycle. This includes automated and manual testing.
Engineering Actions:
- Integrate SAST/DAST into CI/CD pipeline
- Conduct regular penetration testing (at least annually)
- Perform security code reviews
- Run dependency vulnerability scanning continuously
Disclose Information About Fixed Vulnerabilities
Official Text:
"Once a security update has been made available, publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product affected."
Plain English:
After you release a patch, publish security advisories. Include CVE IDs, affected versions, severity, and remediation guidance.
Engineering Actions:
- Create standardized security advisory template
- Request CVE IDs for significant vulnerabilities
- Publish advisories on website and security mailing lists
- Coordinate disclosure timing with patch availability
Vulnerability Disclosure Policy
Official Text:
"Have in place and apply a policy on coordinated vulnerability disclosure."
Plain English:
Publish a clear vulnerability disclosure policy so security researchers know how to report issues to you safely and responsibly.
Engineering Actions:
- Create a Vulnerability Disclosure Policy (VDP)
- Set up security@company.com contact
- Publish security.txt file on your website
- Consider a bug bounty program
Share Vulnerability Information
Official Text:
"Take measures to facilitate the sharing of information about vulnerabilities in the product and the third-party components contained in that product."
Plain English:
Make it easy to share vulnerability information with affected parties, including information about third-party components in your product.
Engineering Actions:
- Maintain up-to-date SBOM for sharing with customers
- Subscribe to security advisories from upstream suppliers
- Participate in industry vulnerability sharing groups (ISACs)
- Notify downstream users of relevant vulnerabilities
Secure Update Distribution
Official Text:
"Ensure that security updates are distributed securely and free of charge."
Plain English:
Security updates must be free and delivered through secure channels. You cannot charge users for security fixes.
Engineering Actions:
- Implement signed updates with cryptographic verification
- Use secure channels (HTTPS) for update delivery
- Separate security updates from feature updates if charging for features
- Ensure update mechanism cannot be used as attack vector
Timely Update Dissemination
Official Text:
"Ensure that, where security updates are available to address identified security issues, they are disseminated without undue delay."
Plain English:
Don't sit on security fixes. Once a patch is ready, push it out to users as quickly as possible.
Engineering Actions:
- Define maximum patch-to-release timelines
- Automate update delivery infrastructure
- Use push notifications to inform users
- Monitor update adoption rates
Don't Forget: ENISA Reporting
In addition to these Part II requirements, manufacturers must also report actively exploited vulnerabilities to ENISA under Article 14:
- 24 hours: Early warning of actively exploited vulnerability
- 72 hours: Detailed notification with CVE, affected products, mitigation
- 14 days: Final report with root cause and resolution
Related CRA Articles
Build Your Vulnerability Management Program
Use our tools to set up your vulnerability disclosure policy and tracking.