Annex I Part II (8) free updates and advisories: CRA proof

What Annex I Part II (8) free security updates and advisories asks manufacturers to do

A manufacturer whose product is in scope has a patch ready for a flaw that customers are already worried about. Annex I Part II point (8) requires that available security updates are disseminated without delay and free of charge, and that each update comes with advisory messages giving users relevant information, including on potential action they should take. The duty is not met by publishing a patch in a private repository or on a support portal that customers must discover on their own. The manufacturer has to push the fix out, explain in plain terms why it matters and what the user should do, and do this for every security update issued during the support period.

The point has one exception. Where a product is a tailor-made product and the manufacturer has agreed otherwise with a business user, the free-of-charge obligation can be set aside by that agreement. Read the exception narrowly. It covers a bespoke product built for a specific business customer under contract, not a standard product sold to many buyers with a premium support tier. Legal and product teams should record which contracts rely on it, what was agreed about update delivery, and whether the product really is tailor-made. The dissemination and advisory duties still apply in substance, and the support period under Article 13 still governs how long updates must remain available. Article 13 requires security updates to stay available for at least 10 years after issue or for the rest of the support period, whichever is longer, and requires the support end date, including month and year, to be stated at the time of purchase.

The hard part is operational, not documentary. A policy that says updates are delivered promptly does not show that each release reached each installed version, with an advisory that a non-specialist can act on, across a support period that can run for years. Teams need a release-to-advisory workflow that ties every fix to affected versions, a template for advisory content covering impact and recommended steps, a channel that reaches active users, and records that show delivery dates. Confirm with your own engineering and support leads how your current release pipeline and customer notification channels would produce that evidence before the first in-scope product is placed on the market.

Which products, releases and users fall under the free updates duty

The free updates duty applies to products in scope of the regulation, for the length of their support period. The cards below cover the scoping decisions that change the work, from release timing and paid tiers to tailor-made agreements and third-party fixes.

Products placed on the market after 11 December 2027

The regulation applies in full to products placed on the market from 11 December 2027, so their free update and advisory obligations start from the first release. Map each product line to its first market placement date and record it in the technical file. Products already on the market follow a different rule, covered in the next card.

Older products after substantial modification

Products placed on the market before 11 December 2027 fall under the regulation only when they are substantially modified from that date. A major redesign or new functionality can therefore bring a legacy product into scope and start its update duties. Confirm with counsel which changes count as substantial before a release goes out.

Free and paid tiers of the same product

The duty requires security updates to be disseminated free of charge, so a paid tier cannot hold back a fix that users of a free tier also need. Decide which features sit behind a paywall and confirm that security fixes for the shared code reach every tier. Document how a paid add-on is separated from the security baseline.

Tailor-made products under separate agreement

The free-of-charge rule has one exception: a tailor-made product where the business user has agreed otherwise. Such an agreement must be made with the business user for that product, not assumed from a standard contract. Keep the signed terms with the product's technical file so the exception can be shown to a market surveillance authority.

Third-party component fixes you must pass on

When a vulnerability sits in a third-party component you ship, the fix released by its maintainer reaches your users only if you integrate and distribute it. Track top-level dependencies through your SBOM and set a process for passing on upstream patches. Confirm whether a component's license or vendor terms limit redistribution before you rely on it.

Support period and update retention window

The support period is the time window in which the free updates duty applies. Every security update issued in that window must remain available for at least 10 years after issue or for the rest of the support period, whichever is longer. Publish the end date, including month and year, at the time of purchase so users can plan.

How an assessor tests free security updates and advisories

This table compares five test areas an assessor applies to Annex I Part II (8), with the evidence each one asks for and the gaps that most often appear. The assessor tests what the manufacturer's own records show, so the main takeaway is that findings usually come from a difference between the written policy and the actual release history.

Test area	Assessor approach	Evidence requested	Common findings
Release pipeline timing	Sample security fixes and trace the time from fix merged to update published to users	Ticket, commit and build timestamps, release records and publication logs for a sample of fixes	Policy says without delay, but records show fixes held for batch releases with no documented reason
Advisory content	Review the advisory template and check sample advisories against what users need to decide on action	Advisory template, published advisories, version history and examples of user-facing messages	Advisories omit affected versions, required steps or the choice to wait, or are published only to a mailing list
Pricing and access terms	Confirm security updates are free of charge and reachable without an upgrade fee or paywall	Price lists, license terms, download portal access rules and any renewal or support tier conditions	Security fixes only offered in a paid tier, or access tied to an active subscription without disclosure
Tailor-made product exception	Check that the exception applies only where a signed agreement with a business user covers the product and its scope	Signed agreements, statements of work, defined product scope and records of any charges agreed	Agreement missing, unsigned, or scope wider than the custom product, so standard customers are excluded
Support end date and availability	Verify the end date (month and year) and the availability period are stated to users at purchase and in product materials	Product documentation, purchase terms, website statements and records of end-of-support notices	End date absent or vague at purchase, or updates removed before the stated date with no notice

How to implement free security updates and advisories, step by step

This sequence turns the Annex I Part II (8) requirement into a working process: who publishes updates, how fast each fix reaches users, what every free update and exception looks like on paper, and how the whole path is proven before a real vulnerability tests it. Each step closes with a document or check you can show an assessor.

Define update channels and publishers
List every route by which a security update reaches users, such as product download portals, package repositories, in-product update mechanisms, and vendor-managed deployments. For each channel, name the team or role allowed to publish to it and the approver who signs off. Engineering, product security and support should agree on this together. The output is a channel register that lists channel, publisher, approver, and the user groups each channel serves. The step is done when every channel that can deliver code to a user appears in the register, with no unowned route left.
Write the dissemination standard tied to risk
Write a short standard that sets how quickly each class of fix must be disseminated once it is available, and how that speed follows the risk assessment of the vulnerability. Annex I asks for dissemination without delay, so the standard should explain what triggers an expedited path and who decides the risk rating. Legal and product security should review the wording. The output is a signed, version-controlled standard that the release team can follow without interpretation. The step is done when a reviewer can take any open fix and state which path it follows and why.
Set the free-of-charge rule and document exceptions
Confirm that security updates are delivered free of charge to all users, and create a single exception list for the only permitted departure: tailor-made products where the business user has agreed otherwise. Each exception entry should name the product, the customer, the agreed terms in writing, and the approving signatory. Commercial and legal teams own the list, and product security reviews it before each release cycle. The output is a signed exception list, and the step is done when every paid update traces to a dated, signed agreement. Confirm with counsel how your contracts define tailor-made products before relying on the exception.
Create the advisory template and approval path
Build a standard advisory template that tells users what the issue is, which versions are affected, whether the fix is available, and what action to take, including workarounds if the update cannot be applied immediately. Set the approval path, naming the author, the technical reviewer, and the person who authorizes publication. The template should accept plain-language text so that operators without security training can act on it. The output is an approved advisory template and a written approval workflow. The step is done when a sample advisory for a hypothetical flaw passes review, and the reviewer confirms it answers the question of what users must do.
Link advisories to release and vulnerability records
Connect each security update to the vulnerability record it fixes, the release that ships the fix, and the advisory that describes it. Use one identifier that appears in the ticketing system, the release notes, the advisory and the update package metadata, so an auditor can trace a single fix end to end. If your team uses a vulnerability management tool such as DefectDojo or Greenbone Community Edition to track findings, record the finding identifier there too. The output is a traceability matrix or a set of linked records. The step is done when you can pick any published advisory and reach its fix, its release and its original finding within a few clicks.
Run a dry run of the full path
Test the complete path with a simulated vulnerability that runs from identification through the approval path, release, advisory publication and user notification. Time each handoff, record where the process stalled, and note any step that required an informal workaround. Confirm that the update is reachable on every channel in the register and that the advisory appears where users will see it. Fix the gaps and rerun the test until the path completes without ad hoc steps. The output is a dry-run report with findings and corrective actions. The step is done when the report is approved and the corrected process is recorded as the current version of the standard.
Keep the process current across the support period
Schedule a periodic review of the channel register, the dissemination standard, the exception list and the advisory template, and rerun the dry run after material process or product changes. Record each review with its date, reviewer and changes made. The support period under Article 13 can run for years, so the review cadence should be set by the product owner and documented. The output is a maintained review log that shows the process reflects how the product is supported today. The step is done when the most recent review is current and every change since the last review is recorded.

What a compliant advisory message has to tell users

An advisory message has to give the user enough information to decide what to do next, so the core test is simple: could an operator who has never read a CVE entry understand whether they are affected and what they must do today? The message needs to say which product and versions are affected, what the vulnerability could allow in plain terms, and whether a fix exists. Where the user can act, the advisory must name the action: install the update, apply a configuration change, disable a feature or stop using the product until a fix is available. Each action should be stated as a concrete step, with the version number or setting name the user will see on their own screen. Your product team should confirm the exact version identifiers and settings with the engineers who ship the fix, because a vague instruction such as "update as soon as possible" leaves most operators guessing.

Write for operators who are not security specialists. Lead with the consequence and the action, then give the technical detail in a separate reference section for administrators who want it. Avoid unexplained identifiers as the main message, and define severity in terms of what happens to the business, not only a score. Test the draft with someone outside the security team, and keep a consistent template so users learn where to look. Advisories and the disclosure of fixed vulnerabilities covered by Annex I Part II point (4) are related but not the same. The advisory goes to users with the update and tells them what to do; the public disclosure record describes the fixed vulnerability for the wider market. Make sure both carry the same facts so the story does not change between channels.

Sometimes no fix or workaround exists yet. In that case the advisory should still be issued promptly, state that the issue is known, explain what the user can do to reduce exposure in the meantime, and commit to telling users when a fix is available. Do not publish a message that implies a remedy you have not verified. Agree with your coordinated vulnerability disclosure contacts how long the report may stay private and when a holding advisory is appropriate. Keep a record of each advisory, its version, the date issued and each update, so you can show an assessor how the messages were produced and how users were informed during the support period.

Evidence that proves free security updates and advisories are delivered

Annex I Part II (8) is tested by records, not by intent. An assessor or market surveillance authority will want to see that each fix reached users without delay, at no charge unless a tailor-made exception applies, and with advice on what to do. The artifacts below are the records that connect a fix to its advisory and show the policy was followed.

Release records linked to advisories

Each security fix should trace from the vulnerability record to the release that contains it, the date the update was made available, and the advisory published with it. Self-hosted tools such as DefectDojo can hold these links, since it imports findings from more than 500 security tool report formats and deduplicates them using per-tool hashcode fields. Confirm that the tool fits your own release process before relying on it. Check that every fix has a publication date that falls after its release date.

Free-of-charge access policy

Keep a written policy stating that available security updates are provided free of charge, plus the configuration that enforces it. This includes the product's pricing settings, licensing terms and any paid tier that could gate patches. Assessors will compare the policy against what customers can actually download. Confirm that no security patch sits behind a paywall, a subscription check or a support contract.

Signed tailor-made exception agreements

The free-of-charge rule has one exception: a tailor-made product whose terms were otherwise agreed with a business user. Each such exception needs a signed agreement that names the product, the business user and the agreed terms for security updates. Without these records, a paid patch arrangement is hard to defend. Confirm that exceptions are limited to products that were genuinely tailor-made, not standard offerings sold with custom terms.

Sample advisories with approval history

Keep sample advisories that show what users were told: the relevant information and the potential action they should take. Store the approval trail for each one, including who drafted it, who reviewed it for accuracy and when it was published. Advisories that lack a clear instruction or an approval record are weak evidence. Confirm that the advisory template covers the action users must take, not only a description of the flaw.

Support period and availability notices

Record the end date of each support period, stated at least by month and year, as shown to buyers at the time of purchase. Keep the notices sent when support ended, where that was technically feasible. These records prove that users knew how long they would receive updates and when that window closed. Confirm that the stated end date matches the support period in your engineering plans and public documentation.

Retention of prior updates

Keep each security update issued during the support period available for at least 10 years after issue, or for the remainder of the support period if that is longer. Store the binaries, checksums and release notes together so an old update can be re-verified. Storage of this kind is usually a recurring cost that grows with the product catalog. Confirm the retention period with your legal team, since the longer of the two rules applies.

What meeting free security updates and advisories costs

This table compares the cost components of delivering free security updates and advisories under Annex I Part II (8), showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to shape a written quote, since no fixed amounts are published here and each figure depends on your product portfolio and release pattern.

Cost component	Who is paid or who bears it	One-time or recurring	What drives cost up or down
Engineering time to build the dissemination path	Internal platform or product engineering, plus any implementation partner for scoped work	One-time, with later changes	Number of products, number of distribution channels, and whether updates reach users automatically or by manual download
Advisory workflow design	Internal product security team, with legal or documentation staff reviewing wording	One-time setup, then recurring upkeep	Number of advisory templates, languages required, and how many user roles must receive different guidance
Advisory writing and approval	Internal product security and documentation staff; reviewers in engineering and legal	Recurring, scales with release volume	Release cadence, number of supported product versions, and how often advisories need legal sign-off
License spend on distribution and tracking tools	Software vendors for commercial tools; no license fee for most open-source options	Recurring where commercial tools are used	Choice of self-hosted open-source tooling can remove most license spend, but platform team time to operate it remains
Platform team operating time	Internal platform engineering for hosting, patching and access control of update and advisory systems	Recurring	Number of hosting environments, update volume, and whether advisories are published from the same system as updates
Tailor-made contract handling	Legal and account teams; product security to confirm the exception applies	Recurring per contract	Share of customers on negotiated tailor-made terms, since each agreed exception needs documented scope and confirmation
Evidence upkeep and archiving	Internal compliance or quality staff; storage costs for the archive	Recurring, with a long retention period	Retention period for each security update under Article 13(9), volume of archived advisories, and audit trail detail expected by the assessor
External review of advisory wording or readiness assessment	Independent reviewer or consultant, paid per scoped review	Optional, one-time or periodic	Number of advisory types, new product categories, and whether the organization has no prior internal review practice
Assessor or certification body time	Independent conformity assessment body, paid under its own engagement terms	Periodic, tied to assessment cycle	Scope of products assessed, number of evidence samples requested, and readiness of records at the time of assessment

Who does what for free security updates and advisories

The manufacturer owns the obligation. Under point (8), security updates must be disseminated without delay and free of charge, unless a tailor-made product was agreed otherwise with a business user, and every update must come with advisory messages that tell users what to do. Those choices are legal and commercial, so they cannot be delegated to a vendor or a tool.

Policy ownership: Approve the written update dissemination policy, including what counts as an available security update and the target time for disseminating one.
Release decisions: Decide when a fix is ready to ship and record who approved it.
Free-of-charge terms: Set the commercial position for every customer tier and document any tailor-made exception agreed in writing with a business user.
Advisory approval: Review and sign off every advisory message, including the guidance on potential action users should take.
Support period records: Keep the end date of the support period, stated at least by month and year, consistent with what was shown at purchase.

Check that each of these decisions has a named owner and a dated record before an assessor asks for it.

Where manufacturers fall short on free updates and advisories

Annex I Part II (8) asks for security updates to reach users without delay, free of charge unless a tailor-made product was agreed otherwise, with advisories that explain what users should do. The gaps below are where manufacturers most often fail that test, and each one leaves a gap in the evidence an assessor or market surveillance authority would ask to see.

Fixes gated behind paid tiers

Security fixes are released only to customers on a premium plan, support contract or enterprise edition, while standard customers must pay to get them. Unless a tailor-made product was agreed in writing with a business user, the default expectation is that available security updates are free of charge. Check your price list and entitlement logic against your release notes, and record any tailor-made agreement that justifies a different arrangement.

Advisories that omit user action

Advisory messages name the flaw and the version that fixes it but never tell the user what to do next, such as upgrading, restarting a service, rotating a credential or applying a workaround until the update is installed. The requirement calls for information on potential action to take. Test each advisory template by asking whether a system administrator could act on it without opening a second document.

No link between fix and release date

Teams track tickets and commits but cannot show which released version contains a given fix or when that version was made available to users. Without this record, you cannot prove updates were disseminated without delay. Keep a fix register that ties each vulnerability identifier to the build, the release date and the advisory that announced it.

Support end dates missing at purchase

Product pages, invoices and onboarding material give no end date for security support, or give only a vague phrase such as long-term support. Article 13(19) requires the end date of the support period, including at least month and year, to be clearly specified at the time of purchase. Confirm that every sales channel, including resellers and marketplaces, shows the same date and that a notice is planned when support ends.

Archived updates removed early

Old installers, patches and update packages are deleted during storage cleanup or when a new major version ships, even though users may still depend on them. Article 13(9) requires each security update issued during the support period to remain available for at least 10 years after issue or for the remainder of the support period, whichever is longer. Set retention rules in your release repository from the start and audit them before any cleanup job runs.

Upstream fixes never shipped

A bundled open-source library or third-party component is patched upstream, but the manufacturer assumes the upstream project will reach its customers and never rebuilds, retests or redistributes the product. The obligation attaches to the manufacturer's product, so each dependency fix needs a rebuild, a release and an advisory where relevant. Use your SBOM to find every component you ship and assign an owner who watches its advisories and triggers updates.

Questions buyers ask about free security updates and advisories

Can a manufacturer charge for security updates under the Cyber Resilience Act?

Generally no. Annex I Part II point (8) requires available security updates to be disseminated without delay and free of charge. The only exception is a tailor-made product where the manufacturer and a business user have agreed otherwise in writing. That exception covers bespoke products built for one customer, not standard products sold with an add-on support tier. Charging for updates on a mass-market product is the situation the requirement is designed to stop, so any commercial model that places updates behind a paywall should be reviewed by counsel before the product is placed on the market.

What work does the free security updates requirement actually need from our team?

The requirement needs three things working together: a way to release fixes quickly, a way to publish them to every affected user, and advisory messages that tell users what to do. Engineering must be able to ship a security update separately from feature work where that is technically feasible. Operations must keep distribution channels available for the full support period. Product and security teams must write advisories that state the relevant information and any action users should take. Each of these needs an owner, a documented procedure and records showing when each update was issued and disseminated.

How long does it take to set up free security update distribution and advisories?

Setup time depends on scope and the number of products, the number of release channels, how much of the build and release pipeline already separates security fixes from feature work, and how many user groups need separate advisories. A single product with one update channel and an existing release process is a very different job from a fleet of products with several distribution paths. Ask any partner to break the estimate down by product, channel and deliverable, and to state which parts depend on your existing tooling. The fixed-scope agreement should state the timeline once the scope is agreed in writing.

Can an open-source tool produce the evidence for security update and advisory compliance?

Open-source tools can produce part of the evidence, mainly findings and tracking records, but they do not write advisories or decide what users must do. For example, DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats and deduplicates them using per-tool hashcode fields, which helps link a finding to the fix that resolved it. Greenbone Community Edition (AGPL-3.0-or-later) runs vulnerability scans and stores results in PostgreSQL. Neither tool replaces the release process, the advisory text or the distribution records. Confirm license terms and feature coverage against the current project documentation before relying on them in your evidence set.

What does a fixed-scope engagement with an implementation partner cover?

A fixed-scope engagement covers the deliverables, scope and timeline agreed in writing before work starts. For this requirement, that can include reviewing the release and distribution path, setting up or configuring the update and tracking tooling on the client's own infrastructure, drafting advisory templates and procedures, and assembling the evidence the organization will present to its auditor. DeployOpen prepares systems, controls and evidence for compliance assessments. The organization still owns its controls and its policy decisions, and only an independent auditor or certification body issues reports or certificates. Ongoing support, upgrades and testing are offered as retainers.

What should we ask for in a quote for this work?

Ask for a written scope that lists each product, each update channel and each deliverable, with the responsibilities split between your team and the partner. The quote should name the systems touched, the environments in which work happens, the tooling installed, the documents produced and the evidence handed over. Ask which items are one-time, such as setup and procedure drafting, and which recur, such as retainers for testing or upgrades. Confirm what is excluded, including legal review of commercial terms and the auditor's fees. DeployOpen does not publish a price list, so a quote follows from the written scope.

What will an auditor sample when checking free security updates and advisories?

An independent assessor typically samples recent security updates and checks each one against the dates and records that show when it was issued, to whom it was made available and whether it was free of charge. The assessor will also read a selection of advisories to confirm they give users relevant information and any action to take. For products with paid tailor-made arrangements, the assessor will look for the signed agreement with the business user. Prepare sample sets in advance, keep distribution logs and make sure the support period end date is recorded consistently with what users were told at purchase.

How do the Article 64 penalties relate to this requirement?

Article 64 sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of Annex I and Articles 13 and 14. Because Annex I Part II point (8) is part of Annex I, a failure to provide security updates free of charge or without delay falls within the highest fine tier. The maximums are ceilings, and the actual fine depends on the authority's assessment of the case. Confirm with counsel how the tier applies to your specific products and business model.

How DeployOpen scopes and prepares free security update evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the update distribution, advisory and release records for Annex I Part II (8) can be produced where the client operates them. DeployOpen prepares the systems and evidence, while the manufacturer owns the obligation and an independent assessor reviews it.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names which products, versions and update channels fall under the free update and advisory obligation.
Scope also records any tailor-made products and the business user agreements that may change the free-of-charge position.

How we build

We configure the update distribution path so security updates reach users without delay, with the release channel documented.
We set up advisory templates that tell users what the issue is, which versions are affected and what action to take.
We connect vulnerability findings from scanning and triage to the release and advisory workflow so each fix has a traceable record.

How we hand over

Handover includes runbooks for publishing a security update and its advisory, including who approves and who notifies users.
Evidence packs list update release records, advisory copies, dates of issue and the support period end date notices required by Article 13.
Documentation states what the client owns, what DeployOpen configured and what an independent auditor or assessor must still review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can keep the update channel, advisory process and evidence archive current as the product and its components change.
Clients should confirm with DeployOpen how support will cover the update retention period in Article 13(9) before signing.