What Annex I Part II (2) asks manufacturers to do with vulnerabilities
Annex I Part II (2) asks manufacturers to address and remediate vulnerabilities without delay and in proportion to the risk they pose, and to provide the security updates needed to do so. Where technically feasible, new security updates must be delivered separately from functionality updates. The requirement is process-based, not a promise to patch everything. Commission FAQ 4.3.1 states that the regulation does not require a patch for every vulnerability found during the support period. The remedy depends on the risk and may be an immediate patch, a workaround advisory, an updated manual, or configuration guidance that disables an affected feature. The reader's first task is therefore to define how the organization decides which of these responses fits each finding, and to document that decision.
Three things usually make this hard. The first is triage discipline. Findings arrive from scanners, bug reports, coordinated disclosures and third-party component advisories, and each needs a severity and exploitability assessment tied to the product's actual configuration, recorded in a way that shows why a fix was or was not shipped. Tools such as DefectDojo can consolidate findings from many scanners and deduplicate them, which keeps the triage record in one place. The second is release separation. Security fixes that ship inside a feature release slow down delivery to users and make the fix harder to audit. Build pipelines, release branches and customer communications should be checked for this separation before the first CRA-scoped release. The third is support period length. Under Article 13(9), each security update must stay available for at least 10 years after issue or for the remainder of the support period, whichever is longer, so artifact storage, signing keys and update channels need a lifecycle plan from day one. Confirm each of these with your own engineering and legal teams.
Which products, versions, components and teams fall under the remediation duty
The remediation duty attaches to specific products, versions and supply chains, not to the company as a whole. The cards below separate the scoping questions that change the work from the teams that carry it out, so the organization can decide early which releases and components are in play.
Products placed on the market after 11 December 2027
Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified from that date. For products placed on the market on or after that date, the remediation duty applies in full from the first release. Check the placing-on-the-market date for every product line, including products you still sell or distribute under older contracts. Confirm with counsel how your organization records the date each product was first made available in the EU.
Substantially modified products
A product placed on the market before the application date can still come into scope when a later change counts as a substantial modification. Engineering should log each major architectural change, new network interface or change in data handling, then ask legal and the product owner whether it alters the product's original cybersecurity properties. Treat this as a scoping decision with a written record, because it determines when the duty starts for that product.
Support period and older versions
The remediation duty runs across the support period, and it does not stop at the newest release. Product owners should define the support period for each product, then map which versions remain in service during that window. Under Article 13(10), software with successive substantially modified versions may be remediated only in the latest version, but only when earlier-version users can get that version free of charge without extra hardware or environment costs. Confirm that condition for each product before relying on it.
Third-party and open-source components
Remediation applies to vulnerabilities in the product, including those inherited from libraries, containers, firmware and cloud services built into it. Engineering needs a current component inventory, usually an SBOM, so that a newly disclosed flaw in a dependency can be matched to affected products and versions. Decide in advance who tracks upstream fixes for open-source components, and whether your organization will backport patches or wait for upstream releases.
Engineering and release management
Engineering writes and tests the fix, while release management decides how it reaches customers. These two teams must agree on whether a security update ships as a separate artifact from functionality updates where technically feasible. Release management should keep a documented branching model that allows a patch to be built for each supported version, not only for the main development branch. Ask who approves an out-of-cycle release and how long that approval takes.
PSIRT, customer support and legal
The PSIRT triages reports, assigns risk and sets remediation deadlines, which is the basis for the duty to act "without delay" in relation to risk. Customer support must recognize vulnerability reports and route them to the PSIRT, and it must tell customers what action to take. Legal reviews the scoping decisions, support period commitments and any tailor-made agreements. Document a named owner for each of these handoffs before a vulnerability arrives.
How an assessor tests remediation and security update practice
This table sets out what an assessor does, what evidence they ask for, and where findings usually arise when testing Annex I Part II (2). Read it as a checklist for preparing the vulnerability handling records and release history that the test will sample. The main takeaway is that the assessor tests whether your documented risk criteria were applied to real closed vulnerabilities, not whether every vulnerability was patched.
| Test step | What the assessor does | Evidence requested | Common finding |
|---|---|---|---|
| Process review | Reads the vulnerability handling procedure and checks how risk is assessed before remediation is scheduled | Written procedure, severity and risk criteria, roles for triage and release approval | Risk criteria are undocumented or exist only in practice |
| Closed vulnerability sample | Selects closed vulnerabilities and compares remediation dates with the assigned risk rating | Ticket or tracker export with discovery, rating, fix and release dates | Missing timestamps make it impossible to show remediation was without delay |
| Separate security releases | Checks whether security fixes shipped apart from feature changes where technically feasible | Release notes, changelogs and build records for recent versions | Security fixes bundled into feature releases with no stated reason |
| Workaround advisories | Verifies that vulnerabilities without a patch received a documented alternative such as configuration guidance | Published advisories, customer notices and the risk decision behind each one | Advisory exists but no record of the risk decision or follow-up patch plan |
| Latest-version rule | Where software is delivered in successive versions, confirms fixes were applied to the latest version and that earlier users could obtain it | Version support matrix, upgrade path records and cost-of-upgrade assessment | No evidence that the upgrade was free of hardware replacement costs |
| Traceability to users | Samples whether affected users were informed of the fix and the required action | Advisory distribution records and channel used for notification | Advisories published but not linked to the affected product versions |
| Ownership and consistency | Checks that the same process was followed across the sample and by the people named in the procedure | Role assignments, meeting or review logs, exception approvals | Exceptions approved informally with no reason or expiry date |
How to build a remediation process that satisfies the requirement
The sequence turns Annex I Part II (2) into a repeatable process: each vulnerability is triaged by risk, given a remediation target, fixed through a defined update channel, closed with the right remedy type, and recorded so an assessor can trace the decision. The output is a set of documents and records that show remediation followed the manufacturer's own risk logic.
Define a risk-based triage method
The product owner and the security lead agree how each vulnerability is scored, including the inputs that matter for the product: exploitability, exposure of the affected function, data and safety impact, and whether the flaw sits in a first-party or third-party component. Engineering reviews the method so it can be applied to real findings. The output is a written triage standard with defined severity classes and the named role that assigns each finding to a class. The step is done when a sample of past findings can be classified by two reviewers with the same result.
Set remediation targets by risk class
For each severity class, the manufacturer sets a remediation target that states what must happen and how quickly, such as a fix, a mitigation or a documented acceptance. The requirement is to act without delay in relation to risk, so the targets should be expressed as internal commitments that the organization can justify, not as public promises. Ask your legal and product teams to confirm any customer contract terms that already fix timelines. The output is a remediation target table approved by management and linked to the triage standard.
Establish a separate security update channel
Where technically feasible, security updates must reach users separately from functionality updates. Engineering defines a release pipeline with its own branch or build path, its own signing and test gates, and a release process that can ship a fix without bundling new features. Platform teams confirm the delivery mechanism for each deployment model, such as self-hosted packages, container images or managed updates. The output is a documented release pipeline definition and a short note on where separation is not technically feasible and why. The step is done when a security fix has been shipped through the channel in a test run.
Decide the remedy type for each finding
The Commission's FAQ states that not every vulnerability needs a patch. For each finding, the product owner chooses among an immediate patch, a workaround advisory, an updated manual, or configuration guidance that disables the affected feature, and records the reason. Risk drives the choice, so a remedy that closes the exposure quickly may come before a full code fix. The output is a remedy decision field in each finding record and a list of standard remedy patterns the team reuses. Confirm with counsel how the chosen remedy will be described to users.
Document the latest-version rule where it applies
Article 13(10) allows a manufacturer of software with successive substantially modified versions to remediate only in the latest version, but only if users of earlier versions can obtain that version free of charge without additional costs to adjust their hardware and software environment. Legal and engineering review whether the rule applies to the product and test the cost condition against the Commission's reading that additional costs mean burdens such as mandatory new hardware or infrastructure replacement, not routine testing, configuration changes or dependency upgrades. The output is a written latest-version assessment with the evidence for each condition. If the rule does not apply, the record says so.
Create the remediation record template
Each vulnerability gets one record that links the source finding, triage class, remediation target, chosen remedy, release or advisory identifier, the date of availability for users, and the closing check. A vulnerability management tool can hold these records, and a ticketing system can carry the work items. Teams should define the mandatory fields before rollout so the record can answer an assessor's questions without reconstruction. The output is a template and a sample completed record. The step is done when every field has an owner and a source system.
Verify the fix and keep the evidence
Before a remediation is closed, a second person confirms the fix or mitigation works, typically by retesting the finding or reviewing the advisory. The closed record then keeps the update and advisory available for the support period, including the retention rule for security updates in Article 13(9). Schedule regular reviews of open items against the remediation targets. The output is a closed record with verification evidence and a monthly or periodic report on open versus overdue items. Confirm the retention and review frequency with your compliance lead.
Choosing the right remedy for each vulnerability
An immediate patch is the default remedy when a vulnerability carries meaningful risk and a fix can be built, tested and delivered within the risk-based timeline the manufacturer has documented. Annex I Part II (2) asks for vulnerabilities to be addressed without delay in relation to the risks posed, and where technically feasible, security updates must be delivered separately from functionality updates. The Commission's FAQ 4.3.1 confirms that the regulation does not require a patch for every vulnerability found during the support period, so the patch is the right answer when the risk justifies it, not every time a finding appears.
- Fit: Remotely exploitable flaws in internet-facing components, or flaws with known exploitation, usually warrant a patch.
- Evidence: Vulnerability record, risk assessment, build and test results, release notes and the update's distribution record.
- Separation: Ship the security fix as its own update where technically feasible, so users can apply it without accepting unrelated functionality changes.
- Cost reading: Routine regression testing, pipeline work and dependency upgrades are ordinary product costs under guidance C(2026) 5252, not additional costs for users.
- Ask your team: Confirm the internal target timelines for each risk level and who signs off an emergency release.
Before relying on this remedy, check that your update channel can deliver the fix to affected users promptly.
A workaround advisory fits when a patch cannot be produced or safely deployed yet, but the risk can be reduced by a documented change to configuration or usage. The advisory must tell users what to do, which versions and components are affected, and when a full fix is expected. The Commission's FAQ 4.3.1 lists workaround advisories and configuration guidance to disable affected features as acceptable remedies, provided they match the risk.
- Fit: A vulnerable feature can be disabled, restricted or isolated while the fix is developed, or a patch depends on a third-party release.
- Evidence: Advisory text, date of publication, the configuration keys or settings changed, and records showing the advisory reached users.
- Verification: Test that the workaround actually removes the exposure, since an advisory that does not work leaves the risk in place.
- Follow-up: Track the advisory until a security update replaces it, and document why the interim measure was accepted.
- Cost reading: Writing and publishing an advisory is a routine cost. A workaround that forces users to buy new hardware would count as an additional cost under the guidance, so it cannot be used to avoid a free update in that case.
Confirm with your product owners that every workaround is tested on the supported configurations before it is published.
An updated manual or configuration guide is the lightest remedy. It fits low-risk issues, hardening gaps that users must address through settings, or cases where the correct action depends on the user's environment. Because it changes documentation rather than code, its strength lies in clarity: the guidance must be specific enough that a competent user can act on it without outside help.
- Fit: Low-severity weaknesses, misconfiguration risks that the product cannot detect on its own, or secure-deployment practices that were previously undocumented.
- Evidence: Revision history of the manual, version-controlled changes, and a clear link between the new guidance and the vulnerability record.
- Limit: A manual rarely satisfies the requirement alone when the risk is significant, because it leaves the burden on users without removing the flaw.
- Cost reading: Documentation updates and review cycles are internal costs to the manufacturer. Asking users to adjust configurations is not in itself an additional cost, but the guidance treats mandatory new infrastructure as one.
- Ask your team: Confirm whether the manual is distributed with each update and how users are notified of changes.
Record the decision to use documentation instead of a fix so an assessor can see the risk reasoning behind it.
Article 13(10) allows manufacturers of software with successive substantially modified versions to remediate vulnerabilities only in the latest version, but only when users of earlier versions can obtain that version free of charge. The condition that matters is cost: the Commission's guidance C(2026) 5252 (section 5) treats additional costs as burdens such as mandatory purchases of new hardware or infrastructure replacement, not routine testing, configuration adjustments or dependency upgrades. If an earlier version runs on the same hardware and environment after an upgrade, the latest-version rule can apply.
- Fit: Software that ships successive major versions, where each version is supported only through its latest release.
- Condition: The upgrade must be free of charge and must not force users to replace hardware or infrastructure.
- Evidence: Versioning policy, a list of supported versions, records that the upgrade path is free, and an analysis of the cost reading for each version.
- Risk: If the upgrade requires a new platform, the rule does not apply and earlier versions must still be remediated.
- Ask your team: Confirm the upgrade path, licensing terms and hardware requirements for every version still in the field.
This remedy is a legal position, so have counsel review the cost analysis before relying on it.
Evidence that proves remediation and update separation
Annex I Part II (2) is tested through records, not intentions. The cards below cover the artifacts that show how vulnerabilities were judged, fixed, shipped and kept available, and how each one should be refreshed between formal reviews.
Triage records with risk rationale
For each vulnerability, keep a dated record of how the manufacturer assessed its risk to users, which affected versions and components were confirmed, and why the chosen response (immediate patch, workaround advisory or configuration guidance) was proportionate. Commission FAQ 4.3.1 confirms that not every finding needs a patch, so the rationale is what an assessor will read first. Check that every triage entry links to the product risk assessment and is reopened when severity or exposure changes.
Remediation tickets with dates
Track each remediation as a ticket with timestamps for when the vulnerability was identified, triaged, fixed, tested and released. The Annex requires remediation without delay in relation to risk, so the gaps between these dates are what demonstrate timeliness. Ticketing tools such as GLPI can hold this workflow, and DefectDojo can link findings to the tickets that resolve them. Confirm that ticket histories cannot be silently edited.
Release notes split by security and functionality
Maintain release notes that separate security updates from functionality changes for every release. Where technically feasible, Annex I requires new security updates to be provided separately from functionality updates, so a single mixed release is weak evidence. Keep a version-by-version list showing which security fixes each build carried and whether they were shipped as standalone packages. Ask engineering to confirm the split is produced by the build pipeline, not written by hand.
Update channel definitions
Document each channel through which security updates reach users, such as stable, long-term support or emergency patch channels, and state which products and versions each channel serves. Assessors check that the separation between security and functionality updates holds in every channel, not only the main one. Record who approves channel promotion and how users are told which channel they are on. Review the definitions whenever a product version reaches end of support.
Advisories and user notices
Keep the advisories issued for each fixed or mitigated vulnerability, including what users must do, which versions are affected and where the security update can be obtained. Where a workaround replaces a patch, the advisory and any updated configuration guidance become the remedy itself, so they need the same version control as code. Store published advisories with their publication dates to show when users were informed.
Availability records under Article 13(9)
Article 13(9) requires each security update to stay available for at least 10 years after issue or for the rest of the support period, whichever is longer. Keep a register of every published security update with its issue date, artifact location, checksum and calculated availability end date. Confirm with counsel how the support period is defined for each product, because the register is only as reliable as that definition. Review the register at each release and at each support-period milestone.
What meeting Annex I Part II (2) costs in money and effort
This table breaks the cost of meeting Annex I Part II (2) into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for building a quote, since no fees or durations are published for this requirement.
| Cost component | One-time or recurring | Who is paid, and what drives the cost |
|---|---|---|
| Triage and risk-based prioritization | Recurring | Internal staff or a service provider. Driven by the volume of reported vulnerabilities and how well severity is assessed against the product's actual risk. |
| Remediation engineering | Recurring | Internal developers or a partner. Driven by the number of affected components, the complexity of dependency upgrades and whether a fix or only a workaround is needed. |
| Separate security release pipeline | One-time build, then recurring upkeep | Internal platform engineers or a partner. Setting up a build path that ships security updates apart from feature releases, then maintaining it, is the main upfront item. |
| Ticketing and workflow tooling | Recurring | Open-source tools such as GLPI or Zammad remove license fees, but staff time to configure, host and maintain them still applies. Ask who administers the platform after handover. |
| Vulnerability scanning and findings management | Recurring | Open-source scanners and DefectDojo avoid license spend for core use. Cost moves with scan frequency, the number of assets and the time spent deduplicating findings. |
| Evidence upkeep | Recurring | Internal compliance or engineering staff. Driven by how well release records, advisory history and remediation timelines are captured automatically rather than assembled by hand. |
| External penetration testing or review | Recurring, with a periodic peak | Specialist testing firms. Driven by product scope, the number of release cycles and whether the test covers the update path as well as the code. |
| Independent assessor sampling | Recurring, at each assessment | The independent auditor or certification body, not DeployOpen. Driven by how many remediation cases and security releases they sample and how complete the records are. |
| Support period obligations | Recurring for the whole support period | Internal teams or a retainer. Driven by how long security updates must remain available, which Article 13(9) sets at 10 years or the support period, whichever is longer. |
Open-source tools that produce remediation evidence
DefectDojo is an open-source (BSD-3-Clause) vulnerability management application that collects findings from many security tools into one place. Its documentation lists support for more than 500 security tool report formats through the UI or API, including in the open source edition, and it offers a generic findings import for formats it does not parse natively. Findings are deduplicated using per-tool hashcode fields, which keeps the same weakness from appearing as new work every time a scanner runs. For Annex I Part II (2), the value is a record of each finding, its severity, its status and the date it was closed or accepted, which lets you show that vulnerabilities were addressed in relation to their risk.
- Finding history: Each finding keeps its state over time, so reimports show when a vulnerability was first seen and when it was resolved.
- Deduplication: Hashcode fields reduce duplicate records, which makes remediation metrics easier to interpret.
- Generic import: Findings from tools without a native parser can still enter the same tracking workflow.
- API access: Imports and status queries can be scripted, which supports repeatable evidence collection.
Confirm with your own team whether the open source edition covers the reporting, user management and integrations your process requires, and test the import of your real scanner output before you rely on it.
Greenbone Community Edition, built on OpenVAS, is licensed under AGPL-3.0-or-later. Its documentation describes gvmd as the vulnerability management service that consolidates scanning, stores results in PostgreSQL, manages users and permissions and schedules scan tasks. Users run scans and review results in the Greenbone Security Assistant web interface. The evidence this produces is a timestamped record of what was scanned, which tests were run, what was found and who reviewed it, which supports the link between identified vulnerabilities and the remediation work that follows.
- Scheduled scan tasks: Recurring tasks produce dated results that show scanning continued across the support period.
- Stored results: Scan data sits in PostgreSQL, so you control retention and backup of the records.
- Access control: User and permission management shows who could start scans and view results.
- Review trail: The web interface shows results used to decide which findings need a patch, a workaround or a documented risk acceptance.
Confirm the scan coverage for your products, including the network and application surfaces in scope, because a scanner does not replace the product-specific testing and review covered by other Annex I Part II requirements.
GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For remediation, the relevant objects are the problem record, which groups the root cause of one or more vulnerabilities, and the change record, which documents the security update being deployed and its approval. Together they produce the timeline an assessor will ask for: when the vulnerability was known, who prioritized it, what change was made and when it was verified.
- Problem records: Link related vulnerabilities to one root cause and a single remediation plan.
- Change records: Document approval, implementation window and rollback steps for each security update.
- Statistics: Reports on open and closed work help you show time-to-remediation trends.
- Recurrent tickets: Scheduled tickets keep periodic reviews, such as risk reassessment, visible in the same system.
Confirm with your change advisory process whether GLPI's ITIL workflow matches how your organization approves security changes, and whether the statistics it produces meet the reporting you need.
Zammad is a web-based helpdesk licensed under AGPL-3.0-only. Its documentation describes bringing customer communication from email, chat, telephone and social media into one ticket system. For Annex I Part II (2), this matters where remediation depends on users applying a fix or a workaround. Ticket threads record what was communicated to which customer and when, including advisory messages telling users what to do. That record supports the claim that information reached the users affected by a vulnerability, and it sits alongside the technical evidence in the scanner and tracker.
- Single ticket history: Advisory emails, replies and follow-up calls stay attached to the affected customer or product.
- Multi-channel intake: Reports arriving by email or other channels enter the same queue.
- Customer-facing record: Threads show the workaround or update communicated to each user group.
- Reporting linkage: Ticket references can be cross-referenced with finding and change identifiers in your other tools.
Confirm the channels you actually need to support, how advisories are distributed to customers outside the ticket system, and whether your legal team accepts ticket threads as the record of notification.
Who owns remediation and who can help
The manufacturer owns remediation. Under Annex I Part II point (2), the duty to address and remediate vulnerabilities without delay sits with the manufacturer, and so do the decisions that follow from it: how severe a vulnerability is for the product's actual use, whether a patch, a workaround advisory or a configuration change is the right remedy, and how long the product's support period runs. An implementation partner can build the machinery that makes those decisions repeatable, such as a findings workflow, ticket routing, patch pipelines and a record of each decision. It cannot take over the decisions themselves, and a contract that hands them to a vendor does not move the legal obligation with them. Confirm in writing which named role in your organization approves each risk-based remedy.
Most of the work that can be outsourced is operational. Typical scopes include deploying vulnerability scanning and findings management, wiring build and release pipelines so security updates can be shipped separately from functionality updates where that is technically feasible, configuring ticketing for the remediation queue, and assembling the evidence file: timestamps, advisories issued, decision records and release notes. Ask a partner to show how each artifact is generated and where it is stored, and who can alter it. Keep the decision log in a system you control, because the record is only as credible as its custody.
Independence draws the line at the assessment. Conformity for most products is self-assessed under module A, but class I important products without full application of harmonized standards, class II important products and critical products need a notified body, and the notified body issues the conformity outcome (Article 32; Commission CRA FAQ 6.1 and 6.2). An implementation partner that designed your remediation process should not also sign off that the process conforms. Before engaging anyone, confirm which conformity route applies to your product, whether the relevant harmonized standards are available, and who is independent of the work being assessed. Our role is to prepare systems and evidence, never to certify them.
Where manufacturers usually fall short on remediation
Most remediation failures under Annex I Part II (2) are not technical. They come from missing written criteria, fixes buried in feature releases, and scanner output that never reaches a tracked remediation date. Each card below names one gap and the check that closes it.
No written risk criteria
Annex I Part II (2) ties the speed of remediation to the risks posed, so the timing has to be defined before a vulnerability arrives. Without written criteria, every severity decision becomes an ad hoc judgment that an assessor cannot test. Write down the factors you use, such as exploitability, exposure of the affected function, and the impact on users, and map each combination to a target response window. Ask whether the criteria were approved and when they were last reviewed.
Security fixes bundled with features
Where technically feasible, new security updates must be delivered separately from functionality updates. Manufacturers that ship fixes only inside feature releases force users to accept new functions to get protection, and they delay fixes until the next planned release train. Set up a separate patch path with its own build, approval and release record. Check whether your release calendar can publish a security-only update outside the feature schedule, and document the cases where separation is not technically feasible.
No record of workaround advisories
The Commission FAQ confirms that a fix is not always a patch. Remedies can include a workaround advisory, an updated manual, or configuration guidance that disables an affected feature. These are often given by email or support tickets and then lost. Keep a controlled log for each advisory with the vulnerability it addresses, the affected versions, the date issued, and the date a patch replaced it. Assessors look for this trail when a manufacturer chose not to patch.
Latest-version confusion
Article 13(10) lets a manufacturer remediate software vulnerabilities only in the latest version, but only when earlier version users can obtain that version free of charge without additional costs to adjust their hardware and software environment. Teams often assume this rule covers any upgrade they would like customers to take. Confirm the conditions in writing for each product line, and record which costs the Commission guidance treats as additional, such as mandatory new hardware or infrastructure replacement. Routine testing and dependency upgrades do not meet that bar.
Scanner findings without remediation dates
Vulnerability scanners and SAST tools produce long lists, and many manufacturers never link those findings to a fix date. Duplicate findings from several tools add noise, and nobody owns the decision to accept a risk. Import findings into a single tracker, deduplicate them, and assign each one a severity, an owner, a due date based on your written criteria, and a closure reference to the release or advisory that resolved it. Ask to see the open-finding aging report for each product.
Remediation tickets outside the security record
When a fix is triggered by a ticket in a general helpdesk, the link to the product security record is often broken. The ticket closes, but nobody can show which version carried the fix or who approved the risk decision. Route vulnerability tickets through a defined workflow with fields for affected version, risk rating, approval and release reference. Check that changes to the product go through the same change process as other ITIL-managed changes, and that the audit trail survives staff turnover.
Questions buyers ask about remediation and security updates
Does the Cyber Resilience Act require a patch for every vulnerability we find?
No. Annex I Part II point (2) requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks they pose, so the response depends on severity and exposure. The Commission's FAQ 4.3.1 confirms that a patch is not required for every vulnerability found during the support period. Remedies can include an immediate patch, a workaround advisory, updated manuals, or configuration guidance that disables an affected feature. Your risk assessment should record why each vulnerability received the response it did, because an assessor will ask for that reasoning as much as for the fix.
What counts as an additional cost under the latest-version rule?
Under Article 13(10), manufacturers of software with successive substantially modified versions may fix vulnerabilities only in the latest version, provided users of earlier versions can get that version free of charge without additional costs to adjust their hardware and software environment. The Commission's guidance in C(2026) 5252 reads additional costs as burdens such as mandatory purchases of new hardware or infrastructure replacement. Routine testing, configuration adjustments and dependency upgrades are not in that category. Before relying on the rule, confirm with your legal team and your product's technical lead that every supported customer can move to the latest version under those terms.
How do separate security updates work in practice?
Where technically feasible, Annex I Part II point (2) requires new security updates to be delivered separately from functionality updates, so customers can apply a fix without accepting unrelated feature changes. In practice this means your release pipeline needs a path for security-only builds, tested on their own, with their own release notes. Some architectures, such as tightly coupled monolithic appliances, may not allow this cleanly. In that case, document the technical reason and the closest workable alternative. Ask your engineers to confirm which products can ship security-only builds today and which need design changes.
How long does remediation work take, and what does the team need to provide?
No fixed duration is set in the regulation, so timing depends on the risk of each vulnerability, the component involved and how much testing a fix needs. The work usually draws on four groups: product engineers who write and test the fix, security staff who triage and confirm the risk, release managers who package and sign the update, and support staff who write the advisory. Plan for the work to recur for the whole support period, which Article 13(9) requires to be at least the longer of ten years after an update is issued or the remainder of the support period. Ask any implementation partner for a written scope that names these roles and the triage criteria they will use.
Can we do remediation in-house, or do we need an outside partner?
Most manufacturers can keep ownership of remediation in-house, since the obligation sits with them and cannot be transferred. What an outside partner can do is prepare the surrounding systems: a vulnerability tracking workflow, a findings pipeline that deduplicates results from scanners, and a ticketing process that links each finding to a fix and an advisory. DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own environment, and runs security testing that can feed this workflow. It does not issue attestations or certifications. Ask for a fixed scope listing which of these systems, runbooks and evidence are included, and which remain with your team.
Which open-source tools can support vulnerability tracking and advisory work?
Several self-hosted tools cover parts of the workflow, but none of them performs remediation for you. DefectDojo (BSD-3-Clause) imports findings from more than 500 security tool report formats, including in its open source edition, and deduplicates them using per-tool hashcode fields. Greenbone Community Edition (AGPL-3.0-or-later) schedules scans and stores results in PostgreSQL. GLPI (GPL-3.0-or-later) provides ITIL-style tickets, problems and changes with a Kanban view, and Zammad (AGPL-3.0-only) brings customer reports into one ticket system. Confirm each tool's licence terms and capabilities against its current documentation before you commit to an architecture.
What should we ask for in a quote for remediation support?
Ask for a written scope that separates one-time setup from recurring work. One-time items usually include workflow design, tool deployment, integration with your build and release systems, and runbook writing. Recurring items usually include triage, patch engineering, security-only release packaging, advisory drafting and support for the whole support period. Ask which systems are hosted in your infrastructure, who holds the admin credentials, which evidence the partner will produce, and what happens when a vulnerability needs a response outside business hours. Any figure should trace back to a named scope item, not a flat estimate.
How DeployOpen prepares remediation processes and evidence
DeployOpen starts this work with a written scope that names the products, release channels, support period and roles involved in remediation. The manufacturer keeps ownership of the decisions: which vulnerabilities get an immediate patch, which get a workaround advisory or configuration guidance, and who signs off on each. DeployOpen plans and implements the self-hosted tooling that records those decisions, inside the client's own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, so the deliverables and timelines are agreed in writing before work begins. DeployOpen does not issue reports, attestations or certifications. Only an independent assessor or certification body can do that.
On the tooling side, DeployOpen typically sets up a ticketing system such as GLPI's Assistance module or Zammad to hold each remediation record, with a link to the finding, the affected versions, the risk rationale and the release that fixed it. Scan and finding data can be consolidated in DefectDojo, which deduplicates findings using per-tool hashcode fields, and vulnerability scanning can run on Greenbone Community Edition. The configuration work covers release separation: security updates are built and published as their own artifacts, separate from functionality releases, where technically feasible. The client should confirm with its engineering leads which build and release pipeline steps can support that split for each product.
A remediation file is only useful if an assessor can follow it. DeployOpen can prepare exports of ticket histories, approval records, release notes and version metadata so the manufacturer can show when a risk was assessed, when a fix shipped and whether the fix reached users on the latest-version path. Before work begins, the client should decide who may close a remediation ticket, how long risk decisions are retained and how the records will remain available for the period the CRA requires. Those retention terms should be confirmed against Article 13 of the regulation and the Commission guidance before the evidence model is finalized.
