Article 13(8) of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to deliver security updates free of charge and without undue delay throughout the support period. 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 is governed by Article 13(8) cost and cadence rules; a change that adds new capability is not.
- Free of charge under Article 13(8). Manufacturers cannot bundle security fixes inside paid subscriptions, premium tiers, or major version upgrades.
- Automatic where feasible under Annex I Part II. Item (7) requires secure distribution mechanisms with automatic delivery where applicable; item (8) requires dissemination without delay.
- "Without undue delay" tracks severity. Industry-standard expectations 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.
- Article 14 reporting interacts with the update lifecycle. When an actively exploited vulnerability is detected, the 24-hour ENISA early warning runs in parallel with the patch process; the update mechanism must be wired into the reporting workflow.
The four anchors of CRA security-update compliance: cost rule, distribution preference, cadence expectation, and penalty ceiling.
Charging for security updates is one of the most direct routes to a finding of non-compliance. If a fix that addresses a vulnerability is only available to customers on a paid support tier, behind a premium subscription, or inside a major version upgrade priced as a new release, that arrangement does not satisfy Article 13(8). Basic security patches must be available to all users of the product as placed on the market, at no additional cost, for the full duration of the support period. Feature releases, professional services, and optional capabilities can still be charged. The dividing line is whether the change addresses a vulnerability.
What Counts as a Security Update
Article 13(2) of the CRA requires manufacturers to design and produce products that are "secure by default" and that ensure "the confidentiality, integrity and availability of data." Article 13(8) then requires that vulnerabilities discovered after market placement are handled for the duration of 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: security updates must be free of charge and must be delivered without undue delay, whereas feature updates carry neither obligation.
| Update type | Article 13(8) 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 undue delay" is not defined numerically in the regulation, but the general expectation from market surveillance authorities and ENISA guidance aligns with industry practice. The diagram below shows the patch window per severity tier, measured from the moment the vulnerability is disclosed (T0):
| Severity | Industry-standard expectation |
|---|---|
| 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 timelines, but they represent the standard against which "without undue delay" will be assessed in enforcement proceedings.
How to deliver CRA security updates
Automatic Updates
Where technically feasible and appropriate, Article 13(8) and Annex I Part II favour automatic security updates. The product should be able to receive and apply updates without requiring the user to take manual action.
Requirements for a compliant automatic update mechanism:
- 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 may design the system to apply the update without deferral. Article 13(8) supports this when the risk justifies it.
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 push expected-in-use period close to 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 | Clock still starts at market placement; support period is meaningful mainly for on-premises or hybrid components; API versioning creates its own support commitments |
| 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 Annex I Part II vulnerability handling beyond update delivery (CVD policy, public disclosure, third-party reporting), see the vulnerability handling guide.
Vulnerability reporting obligations during and after the support period
Article 14 imposes time-bound reporting obligations on manufacturers for actively exploited vulnerabilities and severe incidents. These obligations apply during the support period.
The key interaction:
| Phase | Article 14 reporting duty |
|---|---|
| During support period | Full Article 14 applies: 24h early warning, 72h notification, 14d final report for actively exploited vulnerabilities; 24h / 72h / 1-month for severe incidents. Via ENISA Single Reporting Platform. |
| After support period ends | No Article 14 reporting duty for vulnerabilities discovered post-EOL. If the manufacturer becomes aware of a critical, actively-exploited vulnerability in an unsupported product affecting a large installed base, there is no mandatory reporting. Responsible disclosure and user notification are strongly advisable for reputational and market-surveillance cooperation reasons. |
The support period end date is therefore also the Article 14 horizon. Once the support period lapses, the manufacturer has no obligation to investigate, patch, or report vulnerabilities discovered in that product version. Market surveillance authorities may still investigate under Article 58 if the product presents a significant cybersecurity risk, but the ongoing vulnerability-management obligation under Article 13(8) has ended.
For the full Article 14 timeline mechanics, including what each report must contain and how the two reporting streams (actively exploited vulnerabilities and severe incidents) differ, see the vulnerability reporting guide.
Common Mistakes
Ignoring transitive dependencies. Most vulnerabilities in connected products originate in third-party libraries and components, not in first-party code. The Article 13(8) obligation covers the whole product, not just the code the manufacturer wrote. 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 violates Article 13(8). Basic security patches must be free.
Frequently Asked Questions
Must security updates always be free?
Yes. Article 13(8) requires security updates to be provided free of charge. A manufacturer cannot bundle a security fix inside a paid subscription, a premium support tier, or a major version upgrade and claim Article 13(8) compliance. Feature updates, new functionality, and paid professional services are separate and may be charged normally. The obligation is limited to updates that address vulnerabilities: changes that fix a security weakness in the product as placed on the market.
How quickly must a manufacturer release a security update under the CRA?
The CRA's Article 13(8) requires security updates "without undue delay" but does not numerically define a deadline. Market surveillance authorities and ENISA guidance align with industry practice tied to severity: critical actively-exploited vulnerabilities should be patched within days, high severity within roughly 30 days, medium within 90 days, and low severity bundled into the next regular update cycle. These are not CRA-mandated timelines but represent the standard against which "without undue delay" will be assessed in enforcement. Manufacturers should track actual time-to-patch per CVE so deviations from this baseline are visible and defensible.
Are automatic updates required by the CRA?
Not in all cases. Annex I Part II item (7) requires manufacturers to provide secure distribution mechanisms with automatic delivery "where applicable". For products with reliable connectivity and no operational reason to defer, automatic updates are the expected default. For air-gapped industrial systems, certain medical devices, or safety-critical equipment where automatic patch installation could disrupt operations, a documented manual update process is acceptable. The Annex VII technical file must justify the chosen approach. Users must retain the ability to opt out of automatic updates with clear warnings about the security consequences, except where the risk justifies a non-deferrable critical fix.
Does a SaaS product have a CRA support period?
It depends on whether the SaaS product falls within the CRA's scope as a product with digital elements. Pure SaaS services that are not bundled with a hardware component or downloadable software agent are generally out of scope under Article 2(1). Where a SaaS product includes an on-premises agent, a downloadable client, or a hardware gateway that is placed on the EU market, that component is in scope and its Article 13(8) support period clock starts at market placement. The cloud-hosted backend, when under the manufacturer's control and continuously updated, typically satisfies the "without undue delay" patching obligation through transparent deployment, but the manufacturer must still document the support commitment in the Annex II information for the in-scope component.
What happens to security updates after the CRA support period ends?
Article 13(8) obligations end with the support period. Once the disclosed end date passes, the manufacturer has no CRA obligation to investigate, patch, or distribute security updates for that product version, and Article 14 reporting duties also expire because they apply only during the support period. Market surveillance authorities may still investigate under Article 58 if the product presents a significant cybersecurity risk after end-of-life, but the day-to-day vulnerability-management duty has ended. Manufacturers should clearly communicate end-of-support to users in advance; the Annex II item (k) end-date disclosure is the user-facing instrument for that. Continuing to provide goodwill patches after EOL is permitted but not required.