The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to handle vulnerabilities throughout the support period and, where security updates are available, disseminate them without delay and free of charge. This page covers update-delivery mechanics across embedded, standalone, SaaS, and hybrid architectures. For duration mechanics see support period basics; for pre-purchase disclosure see end-of-support disclosure.
Summary
- Security updates are not feature updates. A change that addresses a vulnerability follows the security-update duties; a change that adds new capability does not.
- Security fixes must not sit behind paid tiers. Available security updates should be disseminated without delay and free of charge, with advisory messages telling users what the update addresses and what action to take, except where otherwise agreed for tailor-made business products.
- Automatic where applicable. Automatic security updates are the default design where they make sense, with secure update-distribution mechanisms and clear user controls.
- Patch targets should track severity. Industry-standard operating targets are days for actively exploited critical issues, 30 days for high severity, 90 days for medium, and the next regular cycle for low.
- Architecture changes the delivery model. Embedded firmware, standalone software, SaaS, and hybrid products each have distinct update mechanics that the technical file must document.
- Reporting interacts with the update lifecycle. When an actively exploited vulnerability is detected, the 24-hour early warning to the coordinating CSIRT and ENISA runs in parallel with the patch process; the update mechanism must feed the reporting workflow.
The four anchors of CRA security-update compliance: cost rule, distribution preference, update availability, and penalty model.
For penalty tiers, see the penalties and enforcement guide.
What counts as a security update
The update duty starts from the product cybersecurity-risk assessment and the security properties that apply to the product. Secure-by-default configuration, confidentiality, integrity, and availability determine whether a change is security-relevant. The manufacturer then needs to handle vulnerabilities effectively throughout the support period.
A security update under the CRA is a change that addresses a vulnerability, a weakness in the product that could be exploited to compromise confidentiality, integrity, or availability. The distinction from a feature update matters for two reasons: available security updates must be free of charge and must be disseminated without delay, whereas feature updates carry neither obligation.
| Update type | Security-update obligation | May be charged? |
|---|---|---|
| Patch fixing a known CVE | Yes (security update) | No |
| Hardening change reducing attack surface | Yes (security update) | No |
| New feature with no security relevance | No | Yes |
| Major version with new capabilities | No (unless it includes security fixes) | Yes |
| Dependency update to eliminate a known vulnerability | Yes (security update) | No |
| Configuration change to close a security gap | Yes (security update) | No |
Without delay is not defined numerically in the regulation. Manufacturers should still set severity-based operating targets so patch decisions are consistent, documented, and explainable. The diagram below shows a practical patch window per severity tier, measured from the moment the manufacturer becomes aware of the vulnerability:
| Severity | Practical operating target |
|---|---|
| Critical (actively exploited) | Days, not weeks |
| High (easily exploitable remotely) | Within 30 days |
| Medium | Within 90 days |
| Low | Included in the next regular update cycle |
These are not CRA-mandated deadlines. They are internal targets that help the manufacturer prove that delay was controlled, risk-based, and documented.
How to deliver CRA security updates
Automatic updates
Where technically feasible and appropriate, automatic security updates are the preferred design. A compliant automatic-update model should enable security updates by default, provide a clear opt-out mechanism, notify users when updates are available, allow temporary postponement where appropriate, and distribute updates securely.
A robust automatic update mechanism should provide:
- Secure download channel (TLS, signed packages)
- Integrity verification before installation
- Rollback capability if an update fails
- Graceful handling of connectivity issues
- User visibility into update status
The user must retain the ability to opt out of automatic updates, with a clear warning about the security consequence of doing so. For critical security updates, the manufacturer should document any non-deferrable design choice in the risk assessment and technical file.
Manual updates
Products that cannot receive automatic updates (air-gapped industrial systems, embedded devices without connectivity, certain medical or safety-critical equipment) require a manual update delivery process:
- Downloadable update packages with clear versioning
- Cryptographic signatures and published public keys for verification
- Installation documentation
- Notification through all available channels (email, web portal, product interface, physical notice if necessary)
Embedded and SaaS: different update models
The update delivery mechanism differs substantially depending on product architecture:
| Product type | Update model | Key CRA consideration |
|---|---|---|
| Embedded firmware (IoT, industrial) | Manufacturer pushes signed firmware; customer applies | Must have OTA capability or documented manual process; long device lifetimes may require support beyond five years |
| Standalone software (desktop, server) | Manufacturer releases package; customer installs | Automatic update agent preferred; version pinning by enterprise customers creates multi-version support burden |
| SaaS / cloud-hosted | Manufacturer controls the environment; updates are transparent to user | Confirm first whether the service is in scope as a product with digital elements or remote data processing solution |
| Hybrid (on-prem agent + cloud backend) | Agent updates are manufacturer-controlled; backend updates are transparent | Each component has its own support period clock; the agent is the product with digital elements and that clock governs |
For broader vulnerability handling beyond update delivery (CVD policy, public disclosure, third-party reporting), see the vulnerability handling guide.
Reporting obligations during update delivery
CRA reporting imposes time-bound obligations for actively exploited vulnerabilities and severe incidents that affect product security. The update process should collect the facts needed for those reports, because the final vulnerability report must include details about the security update or other corrective measures made available.
The key interaction is operational:
| Trigger | Update-workflow duty |
|---|---|
| Actively exploited vulnerability | Capture awareness time, affected products, exploitation facts, mitigation status, and security-update details for the 24h, 72h, and final-report sequence. |
| Severe incident | Capture incident impact, suspected unlawful or malicious cause, initial assessment, mitigation measures, and user-facing corrective actions. |
| User notification | Prepare clear risk-mitigation and corrective-measure instructions for impacted users, and where appropriate all users. |
Do not treat reporting as a separate downstream task. Awareness inside support, PSIRT, telemetry, customer-support, or deployment workflows must route quickly to the reporting owner when a reportable threshold may be met.
For the full reporting timeline mechanics, including what each report must contain and how the two reporting streams differ, see the vulnerability reporting guide.
Security-update availability after release
Making a patch available once is not enough. Each security update made available to users during the support period must remain available after issue for at least 10 years, or for the remainder of the support period, whichever is longer. That requirement changes release operations: old packages, advisories, signatures, hashes, and installation instructions need durable hosting and version traceability.
The public user information also needs to tell users what technical security support is offered and the support-period end date during which they can expect vulnerabilities to be handled and security updates to be received. For the pre-purchase disclosure model, see end-of-support disclosure.
Common mistakes
Ignoring transitive dependencies. Most vulnerabilities in connected products originate in third-party libraries and components, not in first-party code. The vulnerability-handling obligation covers the whole product, including components. An SBOM is the prerequisite. See the SBOM cluster guide for the dependency-tracking framework that makes transitive vulnerability monitoring operational.
Charging for security updates. Bundling security fixes into a paid support tier conflicts with the basic CRA update model unless the tailor-made business-product exception applies. Basic security patches must be free.
Frequently asked questions
Must security updates always be free?
Yes, available security updates must be free unless the narrow tailor-made business-product exception applies. A manufacturer cannot bundle a vulnerability fix inside a paid subscription, a premium support tier, or a paid major-version upgrade and still treat that as normal CRA compliance. Feature updates, new functionality, and professional services can be charged separately. The line is whether the change addresses an identified security issue in the product.
How quickly must a manufacturer release a security update under the CRA?
The CRA does not set a fixed patch deadline, so manufacturers need documented severity-based targets. Critical actively exploited vulnerabilities should be treated in days, high severity in roughly 30 days, medium severity in roughly 90 days, and low severity in the next regular cycle unless the risk assessment justifies a different target. Track actual time-to-patch per vulnerability so delay is visible, risk-based, and explainable.
Are automatic updates required by the CRA?
Not in all cases. Automatic security updates are required where applicable, and the product should also notify users of available updates and allow temporary postponement. For reliable consumer-connected products, automatic updates are usually the expected design. For air-gapped industrial systems, certain medical devices, or safety-critical equipment, a documented manual process can be justified. The technical file should explain the chosen approach and the user instructions should explain how automatic installation can be turned off.
Does a SaaS product have a CRA support period?
It depends on whether the service is in scope as a product with digital elements or remote data processing solution. Pure standalone SaaS that is not tied to hardware, downloadable software, or manufacturer-responsible remote data processing is generally outside this update model. If the offer includes an on-premises agent, downloadable client, hardware gateway, or covered remote processing, map the support period and update mechanism for the in-scope component. The user information still needs the support type and end date.
What happens to security updates after the CRA support period ends?
The ordinary vulnerability-handling duty is tied to the support period, but updates already issued must stay available. Each security update made available during the support period must remain available for at least 10 years after issue or for the remainder of the support period, whichever is longer. Manufacturers should clearly communicate end-of-support in advance and keep user instructions available for the required period. Avoid saying that reporting can be ignored after end-of-support without a case-specific legal check.