3.5 Vulnerability Handling Requirements (Annex I Part II)
3.5.1 Overview
Annex I Part II of the CRA defines 8 vulnerability handling requirements that manufacturers must fulfill throughout the entire support period of a product with digital elements. While Part I governs the security properties of the product itself (Essential Security Requirements), Part II addresses the organizational and procedural obligations for handling vulnerabilities.
LEGAL BASIS
Annex I Part II CRA: Vulnerability handling requirements. Manufacturers of products with digital elements shall comply with the following requirements in order to effectively handle vulnerabilities of the product throughout the support period.
3.5.2 No. 1 – Identify and Document Vulnerabilities and Components
Requirement: The manufacturer shall identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials (SBOM) in a commonly used and machine-readable format covering at least the top-level dependencies of the product.
Implementation at BAUER GROUP:
- Automated SBOM generation in CycloneDX format with every release
- Complete coverage of all direct and transitive dependencies
- Daily CVE Monitoring of all active product SBOMs against NVD, GitHub Advisory Database, and OSV
- Multi-engine security scanning (Trivy, Grype, OSV-Scanner) in the CI/CD pipeline
- Dependabot for automatic detection of outdated or vulnerable dependencies
- Centralized inventory of all products and their component structure
Evidence: SBOM per release (CycloneDX JSON), CVE scan reports, dependency audit logs, component inventory
3.5.3 No. 2 – Address and Remediate Vulnerabilities Without Delay
Requirement: The manufacturer shall address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, security updates shall be provided separately from functional updates.
Implementation at BAUER GROUP:
- SLA-based Patch Management process with defined response times:
- P0 (Critical, actively exploited): Hotfix within 24 hours
- P1 (Critical): Hotfix within 48 hours
- P2 (High): Patch release within 7 days
- P3 (Medium): Minor release within 30 days
- Separation of security updates and functional updates in the release process
- Pre-Release Security Gate: No release with known Critical/High CVEs
- Automated dependency updates via Dependabot with automatic pull requests
Evidence: Patch logs with timestamps, release notes with security fix labels, SLA compliance reports
3.5.4 No. 3 – Effective and Regular Tests and Reviews
Requirement: The manufacturer shall apply effective and regular tests and reviews of the security of the product with digital elements.
WHAT "REGULAR" MEANS
Applying regular tests does not require the mechanical repetition, at fixed intervals, of an unchanged test campaign. It means regularly reviewing whether new input — newly identified threats or newly discovered vulnerabilities — requires the existing tests to be updated, and executing tests accordingly.
| Review outcome | Consequence |
|---|---|
| Relevant new input affecting the test set is identified | New or modified tests must be devised and executed on the product, so that no vulnerabilities remain unaddressed. This may include re-executing existing tests where a modification to the product makes such testing appropriate — for example regression testing. |
| No such input is identified | Additional tests need not be devised. Other vulnerability handling obligations, including addressing and remediating vulnerabilities in relation to the risks posed, continue to apply in parallel. |
The frequency, depth and content of the review must be proportionate to the cybersecurity risk profile of the product, its evolution over time, and the state of the threat landscape.
THE REVIEW ITSELF IS THE EVIDENCE
Because the obligation is to review whether the test set is still adequate, the record of that review — including reviews that concluded "no change required" — is the compliance evidence. A quarterly review that produced no new tests is compliant; an absent review is not.
Implementation at BAUER GROUP:
- Automated Testing: SAST, DAST, and SCA in every CI/CD pipeline
- Container Scanning: Trivy scan of all container images at build time and as scheduled jobs
- Dependency Scanning: Daily SBOM-based CVE scan
- Regular Reviews: Quarterly security reviews per product
- Penetration Testing: Annually for critical products, supplementary testing on substantial modifications
- Risk Assessment: Context-specific risk assessment for each new vulnerability
Evidence: CI/CD scan results, security review records, penetration test reports, risk assessment reports
3.5.5 No. 4 – Public Disclosure of Remediated Vulnerabilities
Requirement: Once a security update has been made available, the manufacturer shall publicly disclose information about fixed vulnerabilities, including a description of the vulnerability, information allowing users to identify the affected products, the impacts, the severity, and remediation measures. Where available, a CVE identifier shall be assigned.
Implementation at BAUER GROUP:
- Publication of Security Advisories via GitHub Security Advisories
- Each remediated vulnerability includes:
- CVE ID: Assigned via GitHub CNA or MITRE
- Description: Clear explanation of the vulnerability and affected versions
- Severity: CVSS v3.1/v4.0 score and rating
- Affected Products: Exact version information
- Remediation: Reference to the security update and recommended actions
- Release notes contain a dedicated security section
- Coordinated disclosure in accordance with Disclosure Policy
Evidence: GitHub Security Advisories, release notes, CVE entries in NVD/OSV
3.5.6 No. 5 – Coordinated Vulnerability Disclosure Policy
Requirement: The manufacturer shall put in place and enforce a policy on coordinated vulnerability disclosure.
Implementation at BAUER GROUP:
- Comprehensive Disclosure Policy in accordance with ISO/IEC 29147:2018
- Defined reporting channels:
- GitHub Security Advisories (preferred)
- Dedicated email address (security@bauer-group.com)
- SECURITY.md in every repository
- Binding response times for incoming reports (initial response within 48 hours)
- Coordinated disclosure period (default 90 days)
- Safe harbor clause for good-faith security researchers
- Recognition program (Security Hall of Fame)
Evidence: Disclosure Policy (published), SECURITY.md in repositories, report tracking log
3.5.7 No. 6 – Facilitate Sharing of Vulnerability Information
Requirement: The manufacturer shall take measures to facilitate the sharing of information about potential vulnerabilities in its product and in third-party components contained therein, including by providing a contact address for the reporting of vulnerabilities.
Implementation at BAUER GROUP:
- Contact Point: Dedicated security contact address in every product and repository
- Upstream Communication: Active reporting of vulnerabilities in utilized open-source components to upstream maintainers
- ENISA Reporting Process: Structured reporting of actively exploited vulnerabilities to ENISA per reporting process
- Internal Communication: Security-relevant information shared through defined channels (communication plan)
- Industry Cooperation: Participation in relevant information sharing initiatives (ISACs, security communities)
Evidence: Contact point documentation, upstream reporting logs, ENISA reports, communication records
The scope and limits of the upstream reporting duty under Art. 13(6) are set out in 3.5.11 below.
3.5.8 No. 7 – Mechanisms for Secure Distribution of Updates
Requirement: The manufacturer shall provide mechanisms to securely distribute updates for products with digital elements to ensure timely deployment. Security patches and updates shall be distributed through trusted channels.
Implementation at BAUER GROUP:
- Signed Artifacts: All release artifacts are signed with Cosign (Signing)
- Trusted Channels:
- Container images via signed registry (GHCR)
- Binaries via signed GitHub Releases
- Firmware updates via secured OTA channels
- Integrity Verification: Verification process using Cosign verify
- Update Mechanism: Automatic and manual update paths documented (Update Mechanism)
- Availability: Updates delivered through redundant infrastructure
- Rollback: Ability to revert to previous version on failed updates
Evidence: Signature logs, update architecture documentation, verification guide, rollback test records
3.5.9 No. 8 – Security Patches Without Delay and Free of Charge
Requirement: The manufacturer shall ensure that security patches are disseminated without delay and free of charge, accompanied by advisory messages providing users with relevant information, including on potential actions to be taken.
Implementation at BAUER GROUP:
- Free of Charge: All security patches are available free of charge throughout the entire support period
- Without Delay: In accordance with SLA requirements of Patch Management
- Advisory Messages: Every security update is accompanied by:
- Description of the remediated vulnerabilities
- Severity (CVSS score)
- Affected versions and upgrade path
- Recommended user actions (workarounds, configuration changes)
- Timeline for remediation (if delayed)
- Notification: Proactive notification of users about available security updates
- No Bundling: Security updates do not contain mandatory functional changes
IMPORTANT
Pursuant to Art. 13(8) CRA, security patches must be provided free of charge for the entire support period. Tying security patches to paid maintenance contracts is not permissible.
Evidence: Release notes with security section, advisory messages, download statistics, user notification logs
3.5.10 Known Exploitable Vulnerabilities (Annex I Part I)
Annex I Part I requires that, on the basis of the cybersecurity risk assessment under Art. 13(2) and where applicable, products with digital elements be made available on the market without known exploitable vulnerabilities. Although it is a Part I requirement, it is inseparable from vulnerability handling and is therefore documented here.
LEGAL BASIS
Art. 3(41) CRA: "'exploitable vulnerability' means a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions."
"Exploitable" — the practical-conditions filter
Not all vulnerabilities are exploitable. Some can only be exploited under theoretical conditions — in a lab or a simulation — or under conditions that would not occur in the product's operational environment. Those do not engage the requirement.
When is a vulnerability "known"?
The CRA does not define the moment. The guidance identifies three routes:
| Route | Detail |
|---|---|
| Public databases | The vulnerability is listed in a relevant publicly accessible vulnerability database — such as the European vulnerability database established by Art. 12(2) of Directive (EU) 2022/2555, or other prominent databases |
| Non-public information | Coordinated disclosure by a security researcher, or the manufacturer's own internal testing and analysis — expressly including the use of AI-powered services |
| Prominent media reporting | Publicly and prominently reported in reliable media outlets, including specialised cybersecurity publications or general mass media |
A REPORT IS NOT A CONFIRMATION
The mere fact that a vulnerability is reported or found does not in itself mean it is exploitable in practice or applicable to the specific product. The manufacturer must investigate and confirm the veracity of the information and its applicability to its own product. A limited period may therefore elapse between the first report and confirmation — with the emphasis, as with reporting, on prompt action.
The release decision
The obligation applies at the moment of placing on the market (Art. 13(1)). In practice, potentially exploitable vulnerabilities are sometimes discovered during the final stages of the development lifecycle, shortly before the product enters the distribution chain.
Because this is a risk-based obligation, it falls to the manufacturer to determine whether the product can be securely placed on the market, or whether the vulnerability must be fixed first.
| Factors in favour of fixing before release | Factors that may justify releasing |
|---|---|
| Severity of the vulnerability | The release also addresses other exploitable vulnerabilities |
| Exploitability under practical operational conditions | The release is necessary for the continued operation of critical systems |
| Potential impact | |
| Risks arising for the product once in use |
THE DECISION MUST BE RECORDED
Releasing with a known vulnerability is a documented risk decision, not an omission. Record which factors were weighed, the outcome of the risk assessment, and the planned remediation. Once the product is on the market, the manufacturer remains fully subject to the Annex I Part II obligations regardless of that decision.
3.5.11 Reporting Upstream and Sharing Security Fixes (Art. 13(6))
Art. 13(6) CRA requires manufacturers to (i) report vulnerabilities in integrated components to the person or entity manufacturing or maintaining that component, and (ii) share any software modification they developed to address such a vulnerability.
Scope of the reporting duty
| Rule | Detail |
|---|---|
| Version scope | Report only in respect of the version of the component that is integrated |
| Use the maintainer's channel | Where the maintainer has established security policies, coordinated vulnerability disclosure processes or designated reporting channels, report in accordance with them — particularly where premature disclosure of an unpatched vulnerability could increase cybersecurity risks |
| No duplicate reports | Manufacturers are not required to report upstream where they can confirm the maintainer is already aware of the vulnerability. They are encouraged to check publicly accessible vulnerability databases, project-specific security advisories and established issue trackers first — this expressly serves to reduce the burden on upstream maintainers, particularly in open-source projects |
| Component vulnerabilities only | Report only vulnerabilities that exist in the integrated component itself — not vulnerabilities arising from the integration between the component and the manufacturer's own code, or from the integration of other components |
| Unmaintained components | Not required where the component no longer has a maintainer, or where the manufacturer no longer relies on the original maintainer for new versions or security fixes |
TWO THINGS YOU ARE ENCOURAGED — NOT REQUIRED — TO DO
- Where integrating a component reveals behaviours, interactions or security-relevant characteristics that were not apparent in isolation, communicate that to the maintainer. It is not a component vulnerability, but it improves the security of the component ecosystem.
- Where a component is unmaintained, inform its users through reasonable alternative measures — existing community mechanisms such as mailing lists or issue tickets, or public vulnerability records.
Sharing the security fix
| Rule | Detail |
|---|---|
| Format | Where appropriate, provide the fix in a machine-readable format, in a manner that can be easily verified and, where appropriate, integrated by the maintainer |
| Licensing (FOSS components) | Share the fix in a manner compatible with the component's licence — for example under the same licence, or under a licence allowing the maintainer to distribute the fix under its own |
| Maintainer guidelines | Where the maintainer has guidelines on how security fixes should be shared, follow them |
What is not required
THE DUTY IS TO OFFER, NOT TO PREVAIL
- Manufacturers are not required to ensure their fixes are accepted by the maintainer.
- They are not required to ensure fixes are integrated into the component's repository — the maintainer may prefer a different solution.
- Conversely, manufacturers are not required to accept a fix proposed by the maintainer, and may mitigate the issue in another suitable way.
- Where the maintainer has already provided a fix but the manufacturer implements a different mitigation strategy — for instance a configuration change elsewhere in the system — the CRA does not require that modification to be shared upstream. Doing so is encouraged where it would help the maintainer.
3.5.12 Compliance Matrix
| No. | Requirement | Implementation Status | Evidence Location | Reference |
|---|---|---|---|---|
| 1 | Identify vulnerabilities and components (SBOM) | ✅ | SBOM archive, CVE reports | SBOM, CVE Monitoring |
| 2 | Remediate vulnerabilities without delay | ✅ | Patch logs, release notes | Patch Management |
| 3 | Effective and regular tests | ✅ | CI/CD reports, pen test results | CVE Monitoring |
| 4 | Public disclosure (CVE ID, severity) | ✅ | GitHub Advisories, NVD | Disclosure Policy |
| 5 | Coordinated vulnerability disclosure policy | ✅ | Disclosure Policy, SECURITY.md | Disclosure Policy |
| 6 | Facilitate sharing of vulnerability information | ✅ | Contact points, ENISA reports | ENISA Reporting |
| 7 | Secure distribution of updates | ✅ | Signature logs, update architecture | Update Mechanism, Signing |
| 8 | Patches without delay and free of charge | ✅ | Release notes, advisories | Patch Management |
Source and legal status of the interpretations in sections 3.5.4, 3.5.10 and 3.5.11: Commission Guidance on the CRA.