Annex I Part II (7) Secure update distribution: CRA evidence

What Annex I Part II (7) secure update distribution requires

Annex I Part II point (7) requires a manufacturer to provide mechanisms that distribute updates securely, so vulnerabilities are fixed or mitigated in a timely manner, and to make security updates automatic where that is applicable. For a manufacturer or an open-source-based vendor, this means the update channel itself is part of the product's security case. It is not enough to patch the code. You must show that an update reaches users intact, from the right source, at the right time, and that the path is documented as a technical solution in your technical documentation under Annex VII point 2(b). The risks are concrete: an attacker who swaps an update in transit or on a build server, a signing key that leaks, or a fix that sits in a release pipeline while users run a known-vulnerable version. Each of these defeats the purpose of the requirement even when the patch itself is correct. The product-side counterpart sits in Annex I Part I point (2)(c), which expects security updates to be automatic by default where applicable, with an opt-out, update notifications and the option to postpone. Point (7) is the manufacturer's delivery obligation that makes that user-facing behavior possible. Practically, your team should confirm which update types are security updates in its own classification, which default setting ships with each product line, and who can approve a deviation from automatic delivery. Ask your engineering leads to write down how a security update is signed, where the signing keys live and who can use them, and how a client verifies a package before installing it. Those answers belong in the documentation an assessor will read. The hard part is the support period. Signing keys must be rotated and stored under access control for years, not for one release. Dependencies you ship will change their own advisories, so the process for deciding when a fix must reach users has to keep running after the first release. Update infrastructure, mirrors, and certificates also age and need maintenance. Organizations often outsource parts of this work, such as building a hardened signing pipeline, setting up certificate issuance with a self-hosted PKI, or testing the update path under attack conditions. The organization still owns the controls and the decisions, and an independent assessor still decides conformity. Ask any partner to show how the update path will be documented and tested across the full support period, not only at launch.

Which update paths in a product fall under secure update distribution

Annex I Part II (7) applies to every update path a manufacturer delivers for a product with digital elements, not only the main application. The regulation applies from 11 December 2027, and the classification of the product decides how much of the update chain must be documented and assessed.

Firmware and OS images

Firmware and operating system images are the update paths most often missed in scoping, especially on embedded and industrial devices with their own boot chain. Each image that the manufacturer signs, publishes or pushes to devices is a distribution path the technical documentation must describe. Check who signs the images, where signing keys are held, and whether devices verify signatures before installing. Confirm this with your engineering team, since device-side verification often sits outside the software team's usual scope.

Application and library updates

Application releases and the library updates shipped inside them form a second path, and each one needs a documented route from build to user. Where a third-party library is updated to fix a flaw, the manufacturer must still be able to show how that fix reaches installed copies. Map each application channel, including manual downloads, app stores and package repositories. Ask which channels can deliver a security fix without waiting for a feature release.

Container images and dependencies

Container images bundle an operating system layer, runtime and application code, so a single image can carry dependencies from several sources. Rebuilding and redistributing an image to fix a base-layer flaw counts as a security update path even when the application code is unchanged. Track which image tags customers pull, how base images are rebuilt, and whether an SBOM for each image is produced at release. Scanning tools such as Trivy can identify the OS packages and dependencies in an image, which helps confirm what each rebuild changed.

Cloud-hosted backends

Some products depend on a vendor-run backend that the customer never installs, such as sync services, licensing servers or device management consoles. Patches applied to these services change the product's behavior without a customer-side update, so they still fall within the update picture the documentation must describe. Confirm with the team that operates the backend whether those changes are documented as part of the product's support period. Record which changes reach customers automatically and which require an action from them.

Third-party components

Components supplied by others, such as an embedded runtime or a vendor's driver, can receive fixes on their own schedule. The manufacturer remains responsible for getting those fixes into the product, so each supplier's update channel is part of the distribution chain. Check whether suppliers notify you of fixes, how long you need to integrate them, and whether you can ship the fix without waiting for the supplier's next major release. Keep a record of which component versions each release contains.

Security updates versus functionality updates

Annex I Part I point (2)(c) expects security updates to be automatic by default where applicable, with an opt-out, notifications and the option to postpone. Defining which releases count as security updates decides which path must be automatic and which may stay under user control. Write a classification rule that marks a release as security-related, and apply it consistently across channels. Ask legal and product owners to agree the rule before the release process is built around it.

How an assessor tests secure update distribution

This table sets out what an assessor examines for Annex I Part II (7), the test method, the evidence requested and the findings that most often delay conformity. Read each row as a step in the assessment, and note that the manufacturer owns the update mechanism while the assessor only tests it.

Test area	What the assessor does	Evidence requested	Common findings
Design review of the update mechanism	Walks through how an update moves from build to the installed product, identifying each hand-off, storage location and trust decision	Architecture diagrams of the update pipeline, distribution endpoints and update client, with named owners for each stage	Update channels that were never documented, or a manual step that bypasses the pipeline without a recorded control
Verification of signing and integrity checks	Confirms that the product checks the origin and integrity of an update before installing it, and that signing keys are controlled	Signing procedure, key custody records, a demonstration of a rejected tampered package, and the verification code path	Signature checks that run only on some platforms, or keys stored with build credentials that many staff can reach
Review of automatic-update defaults and opt-out	Checks whether security updates install automatically where that applies, and how users can disable, postpone or be notified	Default configuration for each product version, user-facing settings, and notification text	Automatic behavior depends on an undocumented setting, or postponement removes security updates entirely
Sampling of past releases	Selects a sample of recent security releases and traces each from the fix to the delivered package and the installed version	Release records linking the vulnerability, the fix, the build, the signed artifact and the date it reached users	Gaps between the fix date and availability, or releases that cannot be traced to a specific build
Testing of rollback and failed-update handling	Observes how the product behaves when an update fails or is interrupted, and whether it can return to a known state	Test results for interrupted installs, rollback procedures and logs showing the outcome	No tested recovery path, leaving devices partly updated or unable to start
Review of the Annex VII technical documentation	Compares the documented solution for secure update distribution with what the product and pipeline actually do	The technical documentation section describing the chosen solution, version-controlled and matched to the release history	Documentation that describes a previous design, or that omits the signing and distribution tools in use
Supporting tooling and dependency checks	Confirms that the tools used to build, sign and distribute updates are themselves identified and kept current	Component inventory for the update pipeline, such as an SBOM produced by a tool like Trivy, and version records	Build and signing tools missing from the inventory, or running versions with known vulnerabilities
Key and certificate lifecycle	Tests how certificates used to validate updates are issued, renewed and revoked	Issuance and renewal logs, revocation procedure and a record of the last rotation	Expired or unmanaged certificates that force a choice between blocking updates and accepting unverified ones

How to build a secure update distribution pipeline step by step

This sequence turns the Annex I Part II (7) requirement into a working update channel: signed releases that devices verify, security fixes that reach users in time, and documentation an assessor can trace back to the regulation. Each step ends with an output you can check before moving on.

Define update channels and signing roles
Start by listing every way an update reaches a user: firmware, application packages, container images, library updates and cloud backend changes. For each channel, name the team that builds it, the team that approves it and the people who can trigger a security release. Decide which releases are security updates and which are functionality updates, because Annex I Part I point (2)(c) treats them differently. The output is a channel register that maps each channel to its owner, its signing key and its update method. Confirm the register with product management and security before any signing work begins.
Set up signing keys and certificate management
Generate signing keys in a controlled environment, ideally an HSM or a secrets engine with audit logging, and never on a developer workstation. Separate the keys for each channel and restrict who can use them. For certificates that secure update endpoints, an internal certificate authority such as the one in FreeIPA, which uses Dogtag, or an OpenBao PKI secrets engine can issue short-lived X.509 certificates without manual CSR handling. Record the key lifecycle: generation, storage, rotation, revocation and destruction. The output is a key inventory with owners, rotation rules and a tested revocation procedure.
Build signed and verified delivery
Configure the build pipeline so every release artifact is signed with the channel key and published with its hash and signature metadata. Client software or devices must check the signature and reject artifacts that fail verification before installation. Require transport over authenticated, encrypted connections, and confirm the update server accepts only artifacts from the approved build pipeline. Pair this step with the software bill of materials produced for the release, so the delivered version can be traced to its components. The output is a reproducible test release that installs only when its signature verifies and fails closed when it does not.
Automate security updates with user control
Where automatic delivery is applicable to security updates, configure the client to download and apply them by default, as Annex I Part I point (2)(c) describes. Build in the user-facing options the same point names: update notifications, an opt-out for the automatic behavior, and the ability to postpone installation. Keep functionality updates on a separate path so a feature change never rides along with a security fix. Confirm with legal and product counsel which products, if any, fall outside automatic delivery. The output is a test matrix showing automatic install, notification, opt-out and postponement behaving as designed on each supported client type.
Test rollback and failure paths
Simulate the failures that will happen in production: an interrupted download, a failed signature check, a bad release that must be withdrawn, a revoked signing key and a device that is offline for an extended period. For each case, confirm the client keeps a working version, reports the failure and retries under controlled rules. Document how a bad update is rolled back and who authorizes that action. Run these tests on the same pipeline used for real releases, not a separate lab build. The output is a signed test report listing each failure path, the observed behavior and any defect raised for remediation.
Document the chosen update solution
Write the technical description that Annex VII point 2(b) expects in the technical documentation. Cover the update channels, the signing and verification design, key management and rotation, automatic update behavior with its user controls, and the rollback procedure. Link each claim to the test evidence and the configuration files that produced it, such as pipeline definitions and key policies. Ask an independent reviewer to confirm the document matches the running system. The output is a versioned update distribution document kept with the product's technical file and updated whenever the pipeline changes.

How signing, certificates and automatic delivery fit together

Secure distribution of updates rests on a trust chain that the manufacturer must design, operate and document. The manufacturer's update signing key is the root of trust: a device should install an update only when the update package can be verified against that key, and the key should never sit on the same systems that build or publish packages. Most teams separate the roles of signing, building and publishing, so that compromise of a build pipeline or a download server does not hand an attacker the ability to sign new code. Confirm with your engineering leads exactly which systems hold signing material, who can trigger a signature, and what approval step sits between a build and a signed release.

Certificates and keys for the update service also need a lifecycle. Services that serve updates, sign metadata or authenticate clients need certificates that are issued from a controlled internal authority, renewed before expiry and rotated when a key may be exposed. Platforms such as FreeIPA include an integrated certificate authority based on Dogtag, and OpenBao's PKI secrets engine can issue short-lived X.509 certificates to services without a manual key and certificate request cycle. Whichever tool you choose, ask how revocation works, how long each certificate lives, and how a rotation is tested before it reaches production devices.

On the product side, Annex I Part I point (2)(c) expects security updates to be automatic by default where applicable, with an opt-out, update notifications and the option to postpone. The client must therefore verify signatures and certificate chains before it installs anything, and the postponement and opt-out behavior must not weaken that verification. Document the update client's verification steps, the trust anchors it ships with, and how it handles a failed check, alongside the server-side signing and rotation design. Annex VII point 2(b) asks for the technical solutions in your technical documentation, so the two descriptions should be written together and checked against each other before a product is placed on the market.

Evidence that passes an assessment for update distribution

Annex I Part II (7) asks for a secure, timely and, where applicable, automatic update mechanism, and Annex VII requires the technical documentation to describe the solution chosen. The cards below cover the artifacts that show the mechanism exists, works and is maintained, and how to refresh each one between assessments so it reflects the product as it actually ships.

Documented update architecture

This is the written description of how an update moves from build to device: the build pipeline, the signing step, the distribution endpoints, the client that verifies and installs, and the fallback path when a download fails. It is the first thing an assessor reads to judge whether the technical documentation under Annex VII describes the chosen solution. Review it at every release that changes the pipeline, hosting or client logic, and compare it against the running system at least once per cycle.

Signing and key management records

Assessors look for records showing which keys sign updates, who holds them, where they are stored, how they rotate, and what happens after a suspected compromise. Keep signing ceremony logs, access reviews for the signing role, and rotation records with dates. Confirm that signing keys sit in a hardware or managed key store and never in a build runner's file system, and record every exception with an owner and an end date.

Certificate issuance logs

Where update clients rely on TLS or device certificates, issuance logs show which certificate authority issued each certificate, for which hostnames or identities, and when each one expires. Automated issuance reduces the risk of lapsed certificates interrupting security updates, so record the issuance path and renewal events. Check the logs against the inventory of distribution endpoints, because a certificate missing from the inventory is a common gap during assessment.

Automatic-update configuration

Annex I Part I point (2)(c) expects security updates to be automatic by default where applicable, with an opt-out, notifications and a postponement option. Export the shipped default configuration for each product version and keep it under version control. Record every change to the default, the opt-out path and the postponement limits, and confirm that the configuration a customer receives matches what the documentation describes.

Release notes and advisories per update

Each security update should carry a record linking the fixed vulnerabilities, the affected versions, the severity and the remediation guidance. These records also support the disclosure duties under Annex I Part II (4) and (8). Generate them from the same tracker that feeds the SBOM and vulnerability data, so the advisory references the exact component versions that changed. Retain them for every version still in its support period.

Rollback and update test records

Assessors expect test evidence that an update installs correctly, fails safely and can be reversed on the targets it reaches. Keep test plans, device or environment matrices, pass and fail results, and the outcome of each rollback drill. Re-run the rollback tests whenever the client, the bootloader or the package format changes, and record which versions were tested together so the evidence matches what customers run.

Self-hosted open-source options for update trust and certificates

Secure update distribution depends on being able to show which keys and certificates vouch for update packages and the servers that deliver them. FreeIPA is an identity management platform that includes an integrated certificate authority built on Dogtag, so an organization running its own infrastructure can issue and manage certificates inside its own environment. The license is GPL-3.0-or-later. Whether FreeIPA fits depends on your directory, identity and certificate needs, so confirm it against your own environment before adopting it.

Scope of the CA: FreeIPA's Dogtag-based CA issues and manages certificates for hosts and services enrolled in the identity domain.
Root and key handling: Decide where the CA root key lives, who can request signing, and how the CA is backed up and recovered.
Revocation: Confirm how revoked certificates are published and checked by the systems that rely on them.
Documentation: Record the CA hierarchy, issuance policy and key lifecycle as part of the technical documentation for the update solution.

Confirm with the FreeIPA project documentation which certificate profiles and integrations your versions support.

What meeting secure update distribution costs

This table breaks down the cost components of building and evidencing secure update distribution under Annex I Part II (7), showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to scope internal work against outside help and to frame the questions you put to a partner or auditor. No figures are given because none are supplied for this requirement.

Cost component	One-time or recurring	Who is paid or who carries it	What drives it up or down
Engineering to build signing and distribution	One-time, then recurring for maintenance	Internal engineers or an implementation partner under a fixed-scope written agreement	Number of products and update channels, how many build pipelines exist, and whether automatic delivery is already in place
Signing keys and certificate operations	Recurring	Internal security or platform team, with a partner if key management is outsourced	Number of signing identities, rotation frequency, and whether certificates are issued automatically (for example through OpenBao's PKI secrets engine) or by hand
Self-hosted open-source tooling	Licence spend removed, operations recurring	Internal platform team for hosting, patching, backup and upgrades of the tooling itself	Hosting footprint, number of tools deployed (such as Dependency-Track or FreeIPA), and how much upgrade work the team absorbs
Testing of update paths	Recurring with each release cycle	Internal QA, or a security testing provider for independent tests of signing, verification and rollback	Number of update paths, device or customer variants, and how often the update mechanism changes
Documentation upkeep for Annex VII technical documentation	Recurring	Product and compliance owners, with partner support for writing and version control	Number of products, change frequency, and whether documentation is generated from pipeline records or written manually
Independent assessment and auditor sampling	Recurring per assessment cycle	The independent assessor or notified body, not the implementation partner	Sample size chosen by the assessor, the number of distinct update channels, and how quickly evidence can be produced on request
Remediation of findings from tests or reviews	Variable, recurring	Internal engineering, with partner support if scoped in advance	Maturity of the existing update process and how early gaps are found before an assessment

Where teams fall short on secure update distribution

Annex I Part II (7) asks for update mechanisms that fix or mitigate vulnerabilities in a timely manner and, for security updates, deliver them automatically where applicable. The gaps below are where that promise usually breaks down, and each one can be checked before an assessor asks.

Unsigned or unverified artifacts

Update packages, container images and firmware images are often published without a signature the device or client checks before installation. A tampered or misdirected artifact then installs with the same trust as a genuine release. Check that every artifact that reaches a customer is signed with a key the manufacturer controls, that the signature is verified on the receiving side, and that a failed verification stops installation and raises an alert. Ask who can publish to the release channel and whether that access is logged.

Manual certificate handling that stalls updates

When signing and TLS certificates are requested by hand, renewed by hand and copied between systems, expiry or a missed step can block the update channel just when a fix is urgent. Teams then either bypass verification or delay the patch. Check whether signing keys and service certificates have a named owner, an issuance path that does not depend on a single person, and an automated renewal before expiry. Record each certificate's lifetime and rotation procedure in the technical documentation.

Automatic updates off by default without justification

Security updates are frequently left as a manual opt-in for convenience, even where automatic delivery is technically feasible. Annex I Part I point (2)(c) expects automatic security updates by default where applicable, with an opt-out, notification and a postpone option. Check the default setting for each product tier, record every product where automation is disabled, and write down the reason and the compensating measure, such as a required maintenance window or an advisory with a fixed deadline.

Undocumented update solutions

Teams often rely on a distribution setup that exists only in the heads of the engineers who built it. Annex VII point 2(b) requires the technical documentation to describe the technical solutions chosen for secure distribution, so an undocumented pipeline is a compliance gap as well as an operational risk. Check that the document names the signing method, the distribution hosts, the verification steps on the client, the automation rules and the owners for each component, and that it is updated when any of them changes.

No tested rollback path

An update channel that can push fixes but cannot reverse a faulty release turns one bad build into a fleet-wide outage. Teams often assume rollback works without ever running it against a real installed base. Check whether the previous signed version remains available, whether devices can return to it without manual recovery, and whether the rollback has been exercised in a staging environment with a recorded result. Keep the test record with the release evidence so an assessor can see that the path works.

Who owns secure update distribution and where a partner helps

Your organization is the manufacturer, so it owns the update distribution obligation, the signing keys, the release decisions and the technical documentation that describes the chosen solution. No partner can accept those duties on your behalf. Internally, the work spans product security, release engineering, and the legal or compliance function that signs the EU declaration.

Accountability: Name an owner for update distribution who can approve a security release and explain the design to an assessor.
Signing keys: Decide who holds release signing keys, where they are stored, how they are rotated and how a compromised key is revoked.
Automatic update policy: Decide which updates are security updates, which are automatic by default, and how users can opt out or postpone, consistent with Annex I Part I point (2)(c).
Release decisions: Decide when a fix is ready, which channels carry it and what the advisory tells users to do.
Documentation: Keep the Annex VII point 2(b) description of the chosen distribution technology current with each release.

Before engaging anyone, confirm that your team can name the person who would authorize an emergency update at 2 a.m. and show where that decision is recorded.

Questions buyers ask about secure update distribution

What does secure update distribution cost, and what drives the price?

Costs fall into three groups: internal engineering time to design the update pipeline, tooling and hosting to run it, and outside help for design, implementation and review. No figure has been supplied for this work, so treat any number as a question for a written quote. One-time costs include building the delivery pipeline, setting up signing keys and writing the technical documentation. Recurring costs include key rotation, update server operations, monitoring and staff time for each release across the support period. The main cost drivers are the number of product lines and release channels, whether devices update in the field or in managed environments, how much existing build tooling can be reused, and the number of certificates and signing keys to manage. DeployOpen does not publish prices. A quote follows from a written, fixed scope. Ask for separate line items for one-time build and recurring operation, the named documentation deliverables, and a statement of who holds the signing keys.

How long does it take to set up secure update distribution?

The duration depends mainly on how much of the update path already exists, and no supplied figure gives a typical duration, so ask for milestones in writing. Most projects move through five stages: inventory of current delivery paths, choice of signing and distribution mechanisms, implementation and testing, staged rollout with rollback, and documentation of the chosen solutions. The team usually needs a product owner who decides release channels and the support period, build and release engineers, a security engineer for keys and certificates, operations staff for hosting and monitoring, and a reviewer who can check the technical documentation. Timing also depends on the product's status. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date (Article 69(2) and (3)), so confirm with counsel when your planned changes start the clock.

Can our own team implement secure update distribution in-house?

Yes, if the team has release engineering and key management skills and can keep the work documented. The manufacturer owns this obligation under Annex I Part II point (7), and the technical documentation must describe the technical solutions chosen for secure distribution (Annex VII point 2(b)). No outside party can take that responsibility. The usual gaps for in-house teams are signing key custody, verification of update integrity on the device, safe rollback, automatic update logic for security fixes, and writing down design decisions in a form an assessor can follow. An implementation partner can prepare systems, configurations, test evidence and documentation drafts for your team to review and approve. Decide early which parts your staff will own after handover, including who runs the update pipeline during the support period.

Is open-source tooling acceptable for secure update distribution?

The regulation asks for mechanisms and documented technical solutions, not for particular products, so open-source tooling can be used if you can show how it is configured, maintained and tested. Several supplied tools support adjacent tasks. OWASP Dependency-Track (Apache-2.0) consumes and produces CycloneDX SBOMs and VEX and flags components with known vulnerabilities. Trivy (Apache-2.0) scans OS packages and software dependencies and can scan existing SBOMs before release. FreeIPA (GPL-3.0-or-later) includes an integrated certificate authority based on Dogtag. The OpenBao PKI secrets engine (MPL-2.0) issues dynamic X.509 certificates so services do not need manual key and CSR handling. These tools support update decisions and certificate issuance but do not replace your signing policy. Confirm each tool's capabilities against your own artifacts and document the version and configuration you run.

How do automatic updates interact with Annex I Part I (2)(c)?

Annex I Part I point (2)(c) is the product-side requirement: security updates are automatic by default where applicable, with an opt-out, update notifications and the option to postpone. Annex I Part II point (7) is the manufacturer's obligation to provide the distribution mechanisms that make this work, so the two must be designed together. In practice this means the default setting enables automatic security updates, users can opt out, users receive clear notices before and after installation, and postponement is bounded. A postponement limit needs a documented risk decision, especially for actively exploited vulnerabilities. Record how the mechanism handles each case in the technical documentation, and test the opt-out and postponement paths as part of release testing. The rule applies where automatic updates are applicable, so document why any security update is excluded from automatic delivery. Read the text in Annex I of the regulation before fixing the design.

What can a consultant or implementation partner not certify for us?

A partner cannot issue a conformity assessment, a certificate, an audit report or the EU declaration of conformity, and it cannot apply CE marking on your behalf. The manufacturer draws up the declaration and affixes the marking. Depending on the product's class and the harmonized standards applied, an independent notified body may be required (Article 32), and notified bodies are listed in the Commission's NANDO system. A partner also cannot promise that a market surveillance authority will accept your product or that every update will reach every device on time. What a partner can do is prepare systems, configurations, test evidence and draft documentation, then support your team through assessment. DeployOpen prepares systems and evidence for compliance assessments and does not issue reports or certificates. Independent auditors and certification bodies do that work.

Does the update duty apply to products already on the market?

It depends on whether the product is substantially modified on or after 11 December 2027. Products placed on the market before that date fall under the regulation only if they are substantially modified from that date (Article 69(2) and (3)). The application date for the main obligations is set by Article 71(2). Separately, the Article 14 reporting duty applies to all in-scope products whenever they were placed on the market, so a product sold before 2027 can still trigger reporting if it is in scope. Update distribution duties are tied to the product being in scope, so the modification question matters for planning. Ask counsel to confirm how your release plan affects each product's status, and record the reasoning in your compliance file. The Commission's non-binding guidance covers substantial modification and support periods and is worth reading before you decide.

Why buyers ask for update evidence before purchase

Procurement teams and security reviewers ask for update distribution evidence because a product that cannot be patched quickly is a standing risk for the buyer's own environment. Under Annex I Part II point (7), the manufacturer must provide mechanisms to distribute updates so vulnerabilities are fixed or mitigated in a timely manner, and automatically where that applies to security updates. Buyers want to see how that promise works in practice before they sign, not just a sentence in a contract. The useful question is concrete: how does a security fix reach an installed copy, who approves it, how is its integrity verified, and what does the customer have to do?

A buyer's review typically asks for the technical documentation extract that describes the update distribution solution, as Annex VII point 2(b) requires for technical documentation. Ask the vendor to show the signing and key management approach for update packages, the update channels and their access controls, the default update behavior for each deployment model (including whether automatic installation can be disabled, postponed or notified, which mirrors the product-side expectation in Annex I Part I point (2)(c)), and the release history for recent security updates. For self-hosted platforms, also ask which update artifacts the customer mirrors internally and how an air-gapped environment receives them. Confirm each item in writing rather than accepting a general description.

Be careful about what the vendor says about status. No document in this area is a certificate, and no vendor can confirm conformity with the Cyber Resilience Act through a supplier questionnaire, because conformity assessment is owned by the manufacturer and, where a route requires it, a notified body. Ask whether the vendor has completed its conformity assessment for the product, and if not, what date and route it is following, and whether the update evidence is a working artifact or a draft. Treat marketing statements about automatic updates as claims to verify. The DeployOpen implementation role is to prepare systems, update pipelines and evidence for the client's own assessment, not to issue a report that a buyer can rely on as proof of compliance.

How DeployOpen prepares update distribution for CRA evidence

DeployOpen plans, builds and documents the update distribution path for self-hosted open-source platforms inside the client's own infrastructure, so the manufacturer can show how security updates reach users. The organization owns its obligations and decisions, and an independent assessor reviews the evidence.

How we scope

Written scope lists which products, update channels and user populations the distribution work covers
Scope records who signs and publishes releases, and where the signing keys are held
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
Ongoing support and upgrades can be added later as a retainer

How we build

Design the release pipeline so security updates can be delivered separately from functionality updates where technically feasible
Configure signed artifacts and certificate issuance for update channels, using FreeIPA or OpenBao PKI where they fit the environment
Set up automatic delivery for security updates where applicable, with the opt-out, notification and postpone behavior the product requires
Test update delivery, rollback and failure handling in a staging environment before production release

How we hand over

Document the technical solutions chosen for secure distribution, as technical documentation under Annex VII point 2(b) expects
Deliver runbooks for signing, publishing, key rotation and emergency update procedures
Record test results and configuration baselines the manufacturer can give to its conformity assessment body or auditor
Confirm with the client which evidence the independent assessor will need and in what format

How we support

Keep documentation and update configurations current as the product and its dependencies change
Review update channels after new vulnerabilities are identified in components tracked by Dependency-Track or Trivy
Run update distribution tests again after upgrades, through a retainer where the client chooses ongoing support
Ask the client to confirm legal, regulatory and assessor requirements, since DeployOpen does not issue reports or certificates