The Cyber Resilience Act (CRA) establishes strict and detailed update and patch management requirements for all Products with Digital Elements (PDEs). These obligations ensure that products remain secure throughout their lifecycle, even after they are placed on the EU market.
This guide explains the complete set of update requirements introduced by the CRA, including secure delivery, lifecycle support, validation, rollback prevention, user communication and documentation duties under Annex II and Annex VII.
1. Why Update & Patch Management Matters Under the CRA
Historically, many IoT devices, embedded systems and software products received minimal or inconsistent security updates. The CRA addresses this gap by requiring manufacturers to:
- Deliver security updates throughout the product’s support period
- Ensure updates are secure, authenticated and verified
- Maintain an update policy and lifecycle security plan
- Document update procedures and evidence for authorities
Poor update practices are one of the main causes of long-term insecurity in digital products. The CRA makes update management a legal obligation.
2. Legal Basis for Update Requirements in the CRA
Update obligations appear in three main sections of the regulation:
2.1 Annex I – Essential Cybersecurity Requirements
Annex I mandates that:
- Updates must be delivered securely
- Update mechanisms must prevent unauthorized access
- Update validation must avoid introducing new vulnerabilities
- Rollback to insecure versions must be prevented
2.2 Annex II – Technical Documentation
Manufacturers must document:
- Update architecture
- Validation procedures
- Cryptographic protections
- Testing evidence for updates
2.3 Annex VII – Post-Market Monitoring
Manufacturers must maintain:
- Update history
- Patching timelines
- Verification logs
- Remediation evidence
3. CRA Update & Patch Management Requirements (Full Breakdown)
3.1 Updates Must Be Delivered Securely
Manufacturers must implement secure update delivery mechanisms that ensure:
- Authenticity (updates are signed by the manufacturer)
- Integrity (updates cannot be tampered with)
- Confidentiality where relevant
Unsigned or unverified updates constitute a direct CRA violation.
3.2 Updates Must Be Validated Before Deployment
Manufacturers must:
- Test updates for security regressions
- Validate compatibility with the product
- Document testing results
Annex II requires explicit evidence of update validation.
3.3 Rollback Prevention
Manufacturers must ensure:
- Devices cannot revert to insecure firmware
- Attackers cannot install outdated or vulnerable versions
This requires version control, signing enforcement and secure boot integration.
3.4 Update Transparency for Users
Users must be informed of:
- Available security updates
- The need to apply updates when manual action is required
- Critical vulnerabilities addressed by updates
In many cases, automatic updates are strongly recommended.
4. Lifecycle Support Requirements
One of the most misunderstood CRA obligations is lifecycle support. Manufacturers must:
- Provide security updates for the full support period
- Define how long the product will receive updates
- Communicate this period to users
Support periods must be “reasonable”, meaning aligned with product category and risk.
4.1 Examples of Support Periods
- Consumer IoT: typically 3–5 years
- Industrial controllers: 7–12 years
- Developer tools: until obsolete or replaced
- Automotive-adjacent PDEs: aligned with vehicle lifecycle
Under-supporting products is a risk for market surveillance action.
5. Secure Update Architecture (Recommended)
A secure update architecture typically includes:
- Cryptographically signed firmware/software
- Secure boot enforcing authenticity
- Encrypted update channels
- Fallback protection
- Atomic installation mechanisms
These are essential to prevent attackers from exploiting update mechanisms.
6. Update Lifecycle Workflow
- Identify vulnerability requiring a patch
- Develop update or mitigation
- Validate update for regressions
- Cryptographically sign update
- Deliver update securely to users/devices
- Verify installation success
- Document validation and deployment
- Monitor post-update security
This workflow is required for both Default Class and Critical Class products.
7. Relationship Between Updates and Vulnerability Handling
Update management is directly linked to vulnerability handling:
- Remediation relies on updates
- Incident reporting may trigger updates
- Annex VII documentation connects updates to vulnerabilities
Failure to provide timely updates can breach multiple CRA obligations simultaneously.
8. Documentation Requirements for Updates (Annex II & VII)
Manufacturers must keep:
- Update testing evidence
- Security validation logs
- Signing procedures
- Version history
- Remediation timelines
Authorities may request this documentation at any time.
9. Common Compliance Mistakes
- No signed updates
- No rollback protection
- Incomplete update history
- Insufficient testing logs
- No clear support-period definition
- Failure to notify users of required updates
10. How Regulus Helps Manufacturers
Regulus automates CRA update and patch management compliance with:
- Update policy templates
- Automated Annex I requirements mapping
- Version tracking and evidence logs
- Secure update architecture guidance
- Lifecycle support recommendations
Start here: CRA Applicability Checker
Conclusion
Update and patch management is one of the most critical CRA obligations. Manufacturers must implement secure update mechanisms, maintain rigorous documentation, define lifecycle support periods and validate updates before release.
For templates, checklists and guidance, explore: Cyber Resilience Act Resources
