Patch Management

Patch management is the disciplined process of keeping software and firmware up to date by identifying applicable security updates, testing them for compatibility and regression issues, and deploying them to affected systems in a controlled manner. For manufacturers, patch management encompasses two separate responsibilities: outbound patch delivery — developing and releasing patches for vulnerabilities in their own products — and inbound patch management — applying upstream patches from third-party and open-source components to their products. Both are relevant under the CRA. Effective patch management requires a maintained SBOM to know which components are in scope, and a CVD policy to receive external vulnerability reports.

Annex I Part II of the CRA requires manufacturers to address vulnerabilities without undue delay, and to make security patches freely available to users. Article 13(1) requires manufacturers to exercise due diligence when integrating components. The CRA's Article 13(8) specifically states that manufacturers must inform users about vulnerabilities and available updates. Key implications:

• Security patches must be free of charge — manufacturers cannot monetise security fixes.
• Patches must be made available through a mechanism users can reasonably access — not requiring specialist tools or contractual arrangements.
• The patch delivery mechanism must be stated in the manufacturer's end-of-life policy and technical documentation.
• Patches must be accompanied by a security advisory explaining the vulnerability addressed.

The CRA does not mandate a universal patch SLA in hours or days, but requires patches 'without undue delay'. Industry norms and ENISA guidance treat the following as reasonable:

• Critical (CVSS 9.0+) vulnerabilities — patch or mitigation within 14–30 days.
• High (CVSS 7.0–8.9) vulnerabilities — patch within 60–90 days.
• Medium/Low vulnerabilities — addressed in regular release cycles.

Manufacturers must also define and publish a support period — the duration for which security patches will be provided. The CRA expects the support period to be proportionate to the product's expected use life. For Class I and Class II Important Products, the support period expectation is higher. At end-of-life, manufacturers must notify users in advance.

CRA non-compliance in patch management typically arises from:

• No SBOM — manufacturers who do not know their component inventory cannot identify which CVEs affect them, leading to missed patches in embedded libraries.
• Paid patch programmes — charging for security fixes is prohibited by the CRA; all security updates must be free.
• No firmware update mechanism — hardware products that cannot receive over-the-air or USB firmware updates cannot be patched at scale.
• Undefined support period — customers cannot plan without knowing when support ends; this also creates CRA documentation non-compliance.
• Patch without advisory — releasing a fix without a security advisory leaves users unable to assess urgency or verify they need the update.