Annex I (2)(c) Security updates: CRA requirements

What the CRA security updates requirement asks for in practice

Under point (2)(c) of Annex I Part I, a manufacturer must make sure vulnerabilities in its product can be fixed through security updates for as long as the product is supported. In practice that means three duties that work together. First, the product must be designed so that a vulnerability found after release can be addressed by an update. Second, where automatic security updates apply, they must be on by default, with a clear and easy way for the user to opt out. Third, the user must be told when updates are available and must be able to postpone them temporarily. Each duty depends on the manufacturer's cybersecurity risk assessment under Article 13(2), which decides where automatic updates are appropriate and where they are not. The Commission's FAQ 4.3.3 notes that automatic updates do not apply to products intended primarily for integration as components, or to products where users would not reasonably expect them, such as professional ICT networks and industrial environments. The reader's first task is therefore to record, for each product, whether automatic updates are expected at all and why. The requirement is hard to meet for reasons that have little to do with writing a patch. A product that runs on many hardware variants, operating systems or customer-managed servers will drift across versions, so the team must know which build is running where before it can ship a fix. The update channel itself must be trustworthy, and the signing keys, distribution servers and rollback path need to be designed and tested before a vulnerability forces their use. User consent is the other difficulty: the default-on setting, the opt-out and the postponement option each change the experience, and each must be explained in the product's documentation. Annex II points 8(c) and (e) make that documentation a requirement in its own right, since users must be told how security updates are installed and how the default automatic installation can be turned off. Before committing to an update design, confirm three points with engineering, product and legal. Identify every component that is delivered to an integrator and decide whether automatic updates apply to it. Record the postponement limits so that a user cannot defer a critical fix indefinitely without the product making that risk visible. Finally, check that the software bill of materials and vulnerability tracking can tell you which versions are deployed, since an update you cannot target is an update you cannot prove you delivered. Annex I Part II points (7) and (8) cover secure distribution and timely advisory messages, and those duties are covered on their own pages.

Which products and update paths fall under automatic update expectations

Automatic security updates are not expected for every product. The scope decision depends on how the product is integrated, where it runs and what users would reasonably expect, and each decision belongs in the cybersecurity risk assessment with its reasoning recorded.

Products intended for component integration

The Commission's FAQ 4.3.3 states that automatic update requirements do not apply to products primarily intended for integration as components. A library, module or board delivered to an integrator usually falls here, because the integrator controls when the product is rebuilt and redeployed. Check the intended use in the risk assessment, and document how security updates reach the integrator so the handover is not left to chance.

Consumer products and default automatic updates

Consumer products are where users reasonably expect updates to arrive without action. For these products, automatic security updates should be enabled by default, with a clear and easy opt-out. Confirm that the default, the opt-out path and the notification text are described in the user instructions required by Annex II.

Professional ICT networks and industrial environments

Professional ICT networks and industrial environments are named in the guidance as settings where users would not reasonably expect automatic updates. Operators there need to test patches before they touch production control or service systems. Record why automatic installation is not the default, and make sure notifications and the option to postpone still work so that the operator can schedule the change.

SaaS-hosted update paths

For a SaaS product, the manufacturer patches the hosted service, so the user does not install anything. The (2)(c) question is whether the vendor deploys fixes without delay and tells customers what changed. Decide whether any tenant-facing components, such as agents or client software, follow the automatic update rule, and record that split separately.

On-premises and self-hosted update paths

On-premises software is installed in the client's own infrastructure, so the manufacturer depends on the operator to apply patches. Document the delivery channel, the signed update packages, the release notes and any manual steps. Where the operator controls timing, the risk assessment should explain how advisory messages and postponement windows keep security fixes moving.

Embedded and firmware update paths

Embedded devices often have limited connectivity, storage and power, which affects how updates are downloaded, verified and installed. Decide whether the device updates itself, waits for a maintenance window or needs a technician. Each path needs a recorded reason, a safe rollback behavior and a way to tell the user that an update is available.

How an assessor tests security update capability

This table sets out each test an assessor is likely to run against Annex I Part I point (2)(c), the evidence requested for it and the findings that most often cause problems. Read each row as a question the manufacturer must be able to answer with documents and a demonstration, not just a product statement.

Test element	What the assessor checks	Evidence requested	Common finding
Update design review	Whether the design can deliver fixes for known vulnerabilities across the support period, including how updates are packaged, signed and delivered	Update architecture document, release process, signing and delivery design, support period statement	Update mechanism described only in marketing terms, with no link to the risk assessment
Default setting verification	Whether automatic security updates are enabled out of the box where the requirement applies, tested on a clean install	Install logs or screenshots from a clean install, default configuration baseline, list of product variants tested	Automatic updates off by default with no documented exception
Opt-out verification	Whether a user can turn automatic updates off through a clear, easy route, and whether the setting persists after restart and upgrade	Step-by-step opt-out procedure, test records across versions, settings export	Opt-out buried in advanced menus or only available through a configuration file
Postponement test	Whether users can temporarily defer an update, and whether the deferral has a defined limit	Postponement design, configurable duration, behavior when the deferral expires	Postponement with no time limit, so unpatched exposure can continue indefinitely
Notification test	Whether users are told that an update is available, and whether the message is clear enough to act on	Sample notification text, trigger logic, delivery records, screenshots of user prompts	Updates installed silently with no notice, or notices that do not explain the security content
Review of user instructions (Annex II 8(c) and (e))	Whether the instructions explain how security updates are installed and how the default automatic installation can be turned off	Current user manual, install and update guide, version match to the tested release	Instructions describe an older update flow or omit the opt-out steps
Exception and scope review	Whether products excluded from automatic updates, such as components for integration or professional and industrial environments, are justified	Documented exception with rationale, product classification, reference to the risk assessment	Exclusion claimed without a written reason, or applied to consumer-facing products
Consistency across versions	Whether the behavior tested matches the released versions in scope and the documentation issued with them	Test matrix by version and platform, release notes, change records for update settings	Behavior changed in a later release without updated documentation

How to implement security updates in a product release cycle

This sequence turns the Annex I Part I (2)(c) requirement into an engineering and documentation process that runs from the risk assessment to the release. Each step produces a record an assessor can trace back to the requirement, and the final steps show how exceptions and user instructions stay consistent with what the product actually does.

Define the update capability and its scope
Start from the cybersecurity risk assessment to decide which components can receive security updates, how each update is delivered, and which parts of the product must be updated separately, such as bundled libraries, firmware, cloud services or container images. Product engineering and the security lead own this step, with input from the people who support the product in the field. It is done when a design record names every updatable component, its update path and the owner responsible for shipping fixes for it, with the support period taken from the regulation's requirements.
Decide automatic update defaults by product type
For each product type, decide whether security updates install automatically by default, which applies where that is expected and applicable, and which products are excluded. Consider the Commission's guidance that the automatic update requirement does not reach components intended for integration or environments where users would not reasonably expect automatic updates, such as professional ICT networks and industrial environments. Ask legal and product management to confirm each classification with the reasoning written down. The output is a decision matrix by product type, signed off by the product owner and the compliance lead.
Build opt-out and postponement controls
Where automatic updates are on by default, build a clear and easy way for users to turn them off, and a separate option to postpone installation temporarily. Test that the control is reachable from the normal settings path, that it survives upgrades and that administrators can manage it centrally where the product supports fleet management. Engineering owns the build and the test cases. It is complete when test results show the opt-out and postponement behave as documented on clean and upgraded installs.
Build update notification and advisory messages
Implement notifications that tell users when a security update is available, what it addresses in plain language, and how to install it or postpone it. Annex I Part II also expects security updates to be disseminated without delay, free of charge and with advisory messages, so align the notification content with the vulnerability handling process. Product and security teams own the message templates. The output is a message catalog and a test log showing that each notification type is triggered by the update pipeline.
Write user instructions for installing and disabling updates
Document how security updates are installed, and how the default automatic installation can be turned off, as Annex II requires for user instructions. Write the steps for each supported interface, such as the product UI, command line or administrator console, and keep the wording tied to the actual settings names in the build. Technical writers and the engineers who built the controls review the text together. Done means every instruction has been walked through on a current build and the review record is filed with the technical documentation.
Test on clean and upgraded installs
Test the full update path on fresh installations and on installations upgraded from previously supported versions. Verify that automatic updates, opt-out, postponement, notifications and rollback behave as designed and as documented, and that updates reach products that were not updated manually. Quality assurance runs the tests, and the security lead signs off on any open defects. The output is a test report with pass or fail results, defect tickets and a release checklist entry that lists the update tests as a release gate.
Use SBOM tooling to confirm updatable components
Generate a software bill of materials for each release and compare it against the component list from the design record, so that every component you claim can be updated is actually present and traceable. Tools such as Dependency-Track can consume and produce CycloneDX SBOMs and track known vulnerabilities in those components, while Trivy can produce an SBOM from a target and scan existing SBOMs. Product security owns the pipeline and reviews any gaps. The output is an SBOM per release and a reconciliation note showing that the update inventory matches the shipped product.
Record exceptions and approve the release
For every product or component excluded from automatic updates, record the reason, the risk assessment entry that supports it, the user instructions that apply and the approver. Compile these exceptions with the test reports, SBOM reconciliation and user instruction review into a release record, then obtain sign-off from the product owner and the compliance lead before shipment. The release is complete when the record can be reproduced from the repository and an assessor could trace each exception back to its justification.

Who owns the update capability, the partner's role and the auditor's line

The manufacturer owns the product, its cybersecurity risk assessment and the decision about how security updates reach users. Under point (2)(c), the manufacturer must decide whether automatic security updates apply to the product, whether they are on by default, how users opt out, how notifications are delivered and whether users may postpone installation. Those choices should follow from the risk assessment and be recorded in the technical documentation. The manufacturer also signs the EU declaration of conformity and affixes the CE marking when the product's route allows self-assessment.

Design decisions: Set the default update behavior, the opt-out path and the postponement window for each product line.
User instructions: Write the Annex II instructions on installing security updates and turning off default automatic installation.
Exclusions: Document which products or deployment contexts fall outside automatic updates, such as components integrated by others or professional and industrial environments.
Declaration: Sign the EU declaration of conformity and keep the technical documentation available to market surveillance authorities.

Before relying on any partner output, confirm internally who approves each update policy and who signs off on the evidence.

Evidence that shows security updates work and stay current

Annex I Part I (2)(c) is only as credible as the records behind it. The artifacts below show what the manufacturer decided, how the update mechanism behaves in practice, and whether users actually received fixes, so each one needs an owner and a refresh trigger tied to releases.

Risk assessment entry for updates

The Article 13(2) risk assessment should record why automatic security updates are enabled, limited or excluded for each product variant, and which users or environments are affected. Check that the entry names the exception cases, such as components intended for integration or deployments where users would not reasonably expect automatic updates, and that it is reviewed whenever the product architecture or deployment model changes. Each release should confirm that the decision still holds.

Default configuration and test logs

Keep records showing that automatic security update installation is on by default in the shipped configuration, with the setting file, build artifact or deployment template as the source. Test logs should show a clean install, an upgrade and a failed update with rollback. Regenerate these logs for each release candidate, because a changed default in a Helm chart, installer or container image is a common reason an update path silently breaks.

Opt-out and postponement test records

Record tests that turn automatic updates off, confirm that the product stops installing them, and confirm that a user can postpone an update for a set period without losing the ability to install it later. Store the configuration key, the admin path or API call used, and the observed result. Repeat these tests after any change to the settings service, because opt-out is the control most likely to regress during refactoring.

Notification samples

Retain copies of each notification template sent when a security update becomes available, along with delivery logs showing which channels were used and when. Samples should show the update, its security relevance and the postponement option. Review the templates each release so they still match the fixes described in the advisory and the wording used in the user instructions.

Annex II user instructions

Annex II requires instructions explaining how security updates can be installed and how the default automatic installation can be turned off. Keep the current instruction set under version control, tie each revision to a product release, and verify each step against a clean installation. Instructions that describe a settings path the product no longer uses are a common finding, so walk through them with the release engineer before publication.

Release records showing updates reached users

Track which installed versions received each security update, the date of availability and the proportion of deployments that confirmed installation where telemetry allows it. Where the product runs in customer infrastructure, record what the customer was told, since telemetry may be unavailable. Reconcile these records with the vulnerability handling log so each fixed issue can be traced from report to user installation.

How SBOM and vulnerability tooling feed update decisions

A current inventory of components and known vulnerabilities is what tells the team which security updates are needed. Point (2)(c) asks that vulnerabilities can be fixed through security updates, but a team cannot patch what it has not listed. For each product, the engineering lead should maintain a software bill of materials (SBOM) that names every operating system package, library and bundled dependency in each release, and refresh it whenever a build changes. That inventory becomes the starting point for deciding which update channel to ship, which customers are affected and how quickly a fix must reach them.

OWASP Dependency-Track (Apache-2.0) can sit on top of that inventory. It consumes CycloneDX SBOMs, flags components with known vulnerabilities, outdated or modified components and license risk, and records license use by SPDX license ID. It can also produce CycloneDX SBOMs and Vulnerability Exploitability eXchange (VEX) statements, which record whether a listed vulnerability actually affects the product. VEX matters for update decisions because it lets the team separate a vulnerable component that is reachable from one that is present but not exploitable in the shipped configuration. Trivy (Apache-2.0) complements this by scanning container images, file systems and targets for OS packages and software dependencies, generating an SBOM from them or scanning an existing one. Confirm the exact input formats and scan targets for your versions in each project's documentation before you build a pipeline around them.

These tools produce evidence that supports the requirement, but they do not satisfy it on their own. A dashboard full of findings does not show that the manufacturer ships timely fixes, notifies users, or offers a way to postpone or opt out, and the Commission's guidance on automatic updates still depends on the product's intended use. Keep the scanner output, the VEX decisions, the release records and the update notices together, and have your own compliance lead confirm which of these your assessor will expect. The licensing terms of both tools are Apache-2.0, so confirm that your own use, including any modifications or redistribution, meets your organization's license policy.

What meeting security update requirements costs

This table breaks down the cost components of meeting Annex I Part I point (2)(c) and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request that separates engineering work from assessment fees and tooling spend. No figures are given because none were supplied for this requirement, so the questions in the right-hand column are what to put to each supplier.

Cost component	Who is paid	One-time or recurring	What drives it, and what to request in a quote
Update engineering (signed update channel, rollout logic, postpone and opt-out controls)	Manufacturer's engineers or an implementation partner	One-time build, then recurring maintenance	Number of product variants and deployment models. Request a line item per variant and per update channel.
Notification and advisory tooling (update alerts, advisory messages)	Tooling vendor or internal engineering	Recurring licence or hosting, plus one-time integration	Number of user groups notified and channels used. Ask whether the quote includes license-free open-source options.
Test environments for updates	Infrastructure provider, plus engineering time	Recurring while updates ship	Number of supported versions and hardware or OS combinations. Ask how many environments are included.
User instructions for installing updates and turning automatic updates off	Technical writer or engineering team	One-time, with revision on each release	Number of languages, product editions and documentation formats. Confirm who approves the text.
External review or penetration testing of the update channel	Independent security testing provider	Usually per engagement, repeated over the support period	Scope of the update channel, number of endpoints and signing components. Request a written scope before pricing.
Assessor fees for conformity assessment	Independent assessor or notified body where required	Per assessment, with follow-up reviews	Product class and assessment route. Ask the assessor to state the scope in writing and the evidence it will sample.
Open-source tooling such as SBOM and vulnerability tracking	Self-hosted, so no per-seat licence fee; hosting and staff time are still paid	Recurring for hosting and maintenance	Infrastructure size and upgrade effort. Ask the supplier to itemize hosting, support and upgrade work separately.

Questions buyers ask about security update compliance

Are automatic security updates mandatory for every product under the Cyber Resilience Act?

No. Automatic security updates are required only where applicable, and the requirement in point (2)(c) is written that way on purpose. Where it applies, automatic updates must be enabled by default with a clear and easy opt-out, users must be notified of available updates, and they must be able to postpone them temporarily. Commission FAQ 4.3.3 states that the automatic update requirement does not apply to products primarily intended for integration as components, or to products where users would not reasonably expect automatic updates, such as professional ICT networks and industrial environments. Your risk assessment should record, product by product, whether automatic updates are applicable and why, because that record is what an assessor will read first.

How do we justify disabling automatic updates for industrial or professional products?

Justify it from the intended use and the user's reasonable expectations, not from convenience. The Commission's guidance points to professional ICT networks and industrial environments, where unplanned changes can affect availability or safety and where updates usually go through change control. Document the operating environment, who installs and approves updates, and how the user is still notified of security updates and given a way to install them. Annex II point 8 also requires user instructions on how updates are installed and how automatic installation can be turned off, so the justification must be visible to the customer, not only in your internal file. Have counsel or your conformity assessment body review the wording before you rely on it.

What effort does security update compliance take in practice?

Effort depends mainly on how the product is built and shipped today. The main work items are a delivery pipeline that can sign and distribute patches, update notifications and a postpone mechanism in the product, an opt-out control, and user instructions in the documentation. Expect the largest share to fall on engineering and release management, with smaller effort from security, legal and documentation teams. Ask any implementation partner for a written breakdown by work item, the systems in scope and the testing included, rather than a single total. The effort recurs with every release, so also ask how the process will run across the full support period.

Can an in-house team meet the security update requirements without outside help?

Often yes, if the team already runs a disciplined release process and has people who understand signing, distribution and product configuration. The gaps usually appear in three places: mapping the requirement to evidence, testing the opt-out and postpone paths across supported versions, and keeping documentation aligned with each release. An outside partner can prepare systems, pipelines and evidence, but it cannot own the controls or issue the conformity assessment. Organizations with a small product team, or with many products on different release cadences, usually find an external review of the process faster than building the full evidence set alone.

What does security update work need from engineering and product teams?

It needs decisions from both teams before the code is written. Product must decide, per product and per configuration, whether automatic updates apply, what the default is, how the opt-out and postpone options appear to users, and what is shown in notifications. Engineering must build the update mechanism, ensure updates can be verified and distributed securely, and make sure a security fix can ship without waiting for a feature release. Both teams need to agree on how vulnerabilities found in components are tracked to a fixed version. Connect this work to your SBOM tooling, for example by using Dependency-Track to track components with known vulnerabilities, so that a fix can be traced from advisory to shipped update.

What will an assessor sample when checking the security update requirement?

Assessors typically sample a small set of products or releases and ask for proof that each step works as documented. Expect requests for the risk assessment entry explaining whether automatic updates apply, the default and opt-out settings in a test build, sample update notifications, the postpone behavior, and the user instructions that describe installation and turning off automatic installation. They may also ask for the update distribution records, such as signed releases and timestamps, and evidence that security updates are delivered without delay and free of charge, which relates to Annex I Part II. Prepare one traceable package per product rather than a general policy, because that is how the sample will be checked.

Does the security update requirement apply to products already on the market?

Generally, a product placed on the market before 11 December 2027 falls under the regulation only if it is substantially modified from that date. Treat any significant change to update behavior, distribution or configuration as a point where the product must be reviewed against point (2)(c). Confirm the exact treatment for your product with the Commission guidance and your legal team, because the answer depends on how the product was placed on the market and what changed. Keeping a record of when each version shipped will make this question much easier to answer later.

Where security update compliance usually breaks down

The most common failure under point (2)(c) is not a missing update mechanism. It is a missing decision. Many manufacturers ship a product with automatic security updates switched on, but never record whether the product is one where automatic updates are expected at all. Commission CRA FAQ 4.3.3 says the automatic update requirements do not apply to products primarily intended for integration as components, or to products where users would not reasonably expect automatic updates, such as professional ICT networks and industrial environments. Close the gap by writing a dated decision per product variant that names the intended deployment context, states whether automatic updates apply, and cites the risk assessment that supports the conclusion. Confirm the wording of that decision with your compliance lead, because the reasoning must hold for the whole support period, not just at launch.

A second break point is the opt-out. Teams often satisfy the 'clear and easy opt-out' expectation on paper while burying the control three menus deep, or in a configuration file that only administrators can find. Postponement fails in a different way: a temporary delay is offered with no ceiling and no log of who postponed what, so a vulnerable build can stay in place indefinitely and nobody can prove it was a deliberate user choice. Close these gaps by testing the opt-out and postponement paths from the user's seat, timing how long each takes, and logging every postponement with the version, date and user identifier. Where the product exposes configuration keys, document them in one place so that the update and opt-out settings can be verified in each release candidate.

Notifications and user instructions are where documentation drifts. Update notices are often written once, never tested against real delivery channels, and not re-checked after a change to the update client. Annex II point 8(c) and (e) require instructions on how security updates are installed and how automatic installation can be turned off, and those instructions quietly go stale when the settings menu is renamed or a default changes. Close the gap by making the instructions a release gate: each release must pass a scripted walkthrough of the install and opt-out steps, notification delivery must be tested for every supported channel, and the results must be stored with the technical documentation. Ask your engineering team to confirm which channels are in use before the first assessment, because untested channels are the ones that fail first.

How DeployOpen works on this

DeployOpen helps manufacturers of self-hosted open-source platforms prepare the update mechanisms, configuration options and evidence that Annex I Part I (2)(c) asks for. The manufacturer keeps ownership of its update policy, its product decisions and its conformity assessment, while DeployOpen plans, builds and documents the technical capability within an agreed written scope.

How we scope

We define in writing which products, versions and update channels fall under the (2)(c) work.
We record which products fall outside automatic updates, such as components integrated by others, and why.
We agree how update notifications, opt-out and postponement will be documented before build work starts.

How we build

We configure automatic security update settings to default on where applicable, with a documented and easy opt-out.
We build update notification and postponement options so users can defer installs for a defined period.
We generate SBOMs with Trivy and track known vulnerabilities in Dependency-Track to decide which updates are security-relevant.

How we hand over

We deliver user instructions covering how security updates install and how automatic installation can be turned off.
We hand over test records showing update, opt-out and postponement behavior in the product's supported configurations.
We provide a documented evidence set that your team and independent assessors can review and retain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review update behavior again when the product changes, the risk assessment is revised or a new version ships.
Ask us to confirm in the written scope which support activities are included and how they are priced.

Annex I Part I (2)(c) Security updates