What vulnerability management process does the CRA expect you to run?
A customer questionnaire, a procurement clause or a market access requirement now asks how you handle vulnerabilities in your product. Article 13(8) requires manufacturers to handle vulnerabilities in the product and its components effectively and in line with Annex I Part II, for the whole support period. The regulation does not require a patch for every vulnerability you find. What it expects is a documented, risk-based process that decides what gets fixed, how fast, and how users are told about the rest. The right design depends on your product, how many third-party and open-source components it contains, how often you release, and how long you have committed to support it.
The organization owns this process. Your product security team, engineering leads and the people who approve releases make the decisions, and you must be able to show who made them and when. An implementation partner can help configure the tooling, write the procedures and assemble the records, but it does not decide your risk acceptances or sign off on your conformity. Where a notified body is required for your product, it assesses the process independently. Where it is not, the assessment is part of your own technical documentation and any market surveillance review. Confirm with your conformity assessment route which of these applies before you invest in the design.
The dates matter for planning. The Article 14 reporting obligations apply from 11 September 2026, so the process must already be able to identify actively exploited vulnerabilities and notify them. The regulation as a whole applies from 11 December 2027. Ask your assessor or counsel which products fall under the regulation before that date, because the Article 69 transition rules differ for products placed on the market earlier and for products that are substantially modified.
How a CRA vulnerability handling process runs across the support period
The sequence turns scattered vulnerability reports into a documented record of what was found, how it was judged, what was fixed and how users were told. Each phase leaves an artifact that an assessor or market surveillance authority can inspect for the whole support period.
Identify vulnerabilities from every known source
Collect candidate vulnerabilities from public vulnerability databases, coordinated disclosure reports sent to your security contact, internal testing such as code review and security testing, and reliable media reports. Commission guidance C(2026) 5252 (section 9.2.2) treats a vulnerability as known once it reaches any of these channels, so the intake has to cover all of them. Owner: the product security team, with component owners for dependency findings. Output: a findings register that records source, affected product version, affected component and date received for each item.
Deduplicate and map findings to affected components
Merge duplicate reports of the same flaw and link each finding to the exact component, version and product configuration it affects. This step depends on a current software bill of materials, because a finding in a third-party library only matters for the releases that ship it. Output: a consolidated register in which each entry names the affected product versions and whether the flaw sits in your code, a component or a third-party service.
Triage by severity, exploitability and impact
Assess each consolidated finding against severity, whether it is exploitable in your product's real configuration, and its impact on users. The guidance describes this as risk-based, so the triage must also consider the risks of delaying a release. Owner: product security with the engineering lead for the affected component. Output: a triage record per finding with the scoring method, the assessor's name and the date of the assessment.
Document the remedy decision for each finding
Decide whether the finding needs a security update, a workaround advisory, updated manuals or configuration guidance that disables an affected feature, or no change with a recorded reason. The CRA does not require a patch for every vulnerability found during the support period, so the decision must be justified, not assumed. Owner: the accountable product owner, with sign-off from security. Output: a signed risk decision that links to the triage record and states why the chosen remedy addresses the risk.
Develop and release the security update
Build and test the fix in a branch that is tracked against the findings register. Where technically feasible, release security updates separately from functionality updates so users can apply protection without taking new features. Verify the fix against the original finding before release. Output: a release record that ties the update to the finding identifiers, the affected versions and the test results, plus the update package made available to users.
Publish advisories and guidance to users
Inform users of the vulnerability, the affected versions, the remedy and any interim steps, using a published advisory or release note. Where no update is planned, publish the workaround or configuration guidance instead. Advisories should match the risk decision recorded earlier, not extend beyond it. Output: a published advisory with a stable identifier, linked from the register entry so the disclosure history can be reconstructed later.
Keep security updates available and close the record
Store every security update so that it stays available for at least 10 years after issue or for the remainder of the support period, whichever is longer. Re-check open findings as new dependency advisories arrive and as the support period runs. Confirm the retention period with your counsel and your support policy, since storage and retrieval plans depend on how you package and host updates. Output: an archive index of released updates and a register in which every finding has a closed status, a documented exception or an open risk owner.
How risk-based remediation works without patching everything
Annex I Part II point (2) asks manufacturers to address and remediate vulnerabilities without delay in relation to the risks they pose. The phrase that matters is the second half. The regulation does not ask for a patch for every finding, and the Commission's guidance (section 9.2.2 of C(2026) 5252) lets the manufacturer weigh severity, exploitability and impact against the risk of delaying a release. A critical flaw in an internet-facing authentication component and a low-severity issue in an admin-only report generator call for very different responses, and the process has to make that difference visible. Commission CRA FAQ 4.3.1 confirms that the remedy depends on risk and can take several forms: an immediate patch, a workaround advisory, updated manuals, or configuration guidance that disables the affected feature until a fix ships. For a product with a long support period, the last two options are often the right answer for a finding that is hard to exploit in your deployment. Your triage step should record which remedy applies to each finding, who approved it and when the customer-facing guidance was published.
Because the regulation leaves the judgment to the manufacturer, the decision record is the evidence an assessor will ask for first. For each vulnerability, keep the severity source, your exploitability and impact assessment, the affected versions, the chosen remedy, the reason any patch was deferred, and the date of the decision. Store these records in your vulnerability tracker so each one links to the finding and to the release that closed it. An assessor will test a sample of decisions against the risk you documented, so a decision that says "low risk" without reasoning will not hold up. To set this up, agree the scoring inputs and the approvers before the first finding arrives. Decide who may defer a fix, what evidence is required to defer, and how deferred items are reviewed at each release. Confirm the exact requirements with your assessor and with the Commission's guidance, since the regulation does not prescribe a scoring method. The workflow should also keep security updates separate from functionality updates where that is technically feasible, which Annex I Part II point (2) expects.
What must be in place before an assessor reviews the process
An assessor will test whether the vulnerability handling process works in practice, not just on paper. The six items below are the records and capabilities that connect the policy to real findings, decisions and releases across the support period.
Documented vulnerability handling policy
A written policy that states how the product's vulnerabilities are identified, assessed, prioritized, fixed and communicated, and which Annex I Part II requirements each step meets. Check that it covers components as well as the product's own code, that it names the support period, and that it has been approved by someone with authority to enforce it. Ask whether staff can describe the steps from memory when asked.
Current component inventory tied to the product
A bill of materials for each released version that lists every component, including open-source libraries and third-party services the product depends on. Check that each inventory maps to a specific release and is regenerated with each build, so an assessor can see which component versions shipped to customers. An inventory that reflects only the current main branch will not show what was on the market.
Named owners and decision rights
A named owner for triage, a named approver for risk decisions and a named release owner for security updates, each with written authority. Check that the decision record shows who decided not to patch a given finding, on what risk basis, and when it will be reviewed. Where responsibilities sit with a development team, a product manager or an outside partner, the assignment should still be explicit.
Findings register with dedupe and history
A single register where every finding from scanners, researchers and internal testing is recorded once, with its status history and the decision taken. Check that duplicate findings from different tools are merged, that reimports do not reopen closed items without cause, and that each entry links to the release it affected. Tools such as DefectDojo deduplicate findings using per-tool hashcode fields, so confirm how your chosen tool matches findings across scanner formats.
Separate security update channel and release procedure
A release path for security updates that runs apart from feature releases, where technically feasible, with its own approval, testing and customer notification steps. Check that a security fix can be built, tested and delivered without bundling new functionality, and that the procedure records which customers received each update. Confirm the rollback path before an assessor asks how a faulty update would be handled.
Update retention for the full period
A retention arrangement that keeps every security update available for at least 10 years after it is issued or for the rest of the support period, whichever is longer, as Article 13(9) requires. Check that artifacts, signed packages, release notes and checksums are stored in a location that survives staff turnover and infrastructure changes. Confirm the retention period with counsel, since the duration depends on each product's support period.
Open-source tooling to track findings: Dependency-Track and DefectDojo
OWASP Dependency-Track is an Apache-2.0 licensed platform that ingests software bills of materials and continuously checks the components they list against known vulnerabilities. It correlates components against several sources, including the NVD, GitHub Advisories, Sonatype OSS Index, Snyk, Trivy, OSV and VulnDB, so a single component is not judged by one feed alone. For a CRA program, its value is knowing which shipped components are affected when a new advisory appears, which is the starting point for the risk-based decision the regulation expects.
- Multi-source correlation: Components are matched against the listed sources, which helps reduce gaps where one database lags or omits an entry.
- Global policies: Organization-wide rules can flag components by security severity, license or operational criteria.
- Per-project policies: Individual products can carry their own rules, so a high-risk product is not judged by the same thresholds as an internal tool.
- Component-level view: Teams can see which products include an affected library or version, which supports scoping of a remediation.
- Self-hosted deployment: The platform runs inside your own infrastructure, so the component inventory of unreleased products stays under your control.
Confirm which sources are enabled in your version and how they are configured, since data feeds and integrations change over time. Check the current behavior in the Dependency-Track documentation before relying on it for evidence.
DefectDojo is a BSD-3-Clause licensed application for managing security findings from many scanners and testing activities. It is the place where findings are recorded, triaged, assigned and closed, so that each vulnerability has a traceable history. Its import capability matters most for a CRA program, because findings arrive from dependency checks, static analysis, dynamic testing and manual reports, and they need one consistent record.
- Broad report import: Findings can be imported and reimported from more than 500 security tool report formats through the UI or API, including in the open source edition.
- Generic import: A generic findings format covers tools and reports that have no dedicated parser, so internal or vendor reports can still be recorded.
- Hashcode deduplication: Per-tool hashcode fields are used to recognize the same finding across repeated scans, so the backlog reflects distinct issues rather than repeated alerts.
- Reimport tracking: Repeated scans update existing findings, which supports a timeline of when each issue appeared and was closed.
- Local accounts in the open source edition: SSO (SAML, OIDC, OAuth), LDAP, MFA, connectors for automatic import, Smart Upload and the Universal Parser are listed as Pro features, and the open source edition uses local accounts.
Confirm the feature split against the project's current supported tools list and repository before planning access controls, since the boundary between editions can change. The DefectDojo supported tools documentation is the natural starting point.
Dependency-Track and DefectDojo do different jobs and are often used together. Dependency-Track answers which components in a product are affected by a known vulnerability, while DefectDojo records what the organization decided about each finding and what it did. The CRA's risk-based approach depends on that record, because the decision not to patch immediately still needs a documented rationale, a workaround or a planned fix.
- Flow from inventory to record: Component findings from Dependency-Track can be carried into DefectDojo as a single tracked finding per product and version.
- Separate triage states: Each finding can be marked as fixed, accepted with a rationale, mitigated by a workaround or pending a security update.
- Product-level ownership: Findings are tied to the product and its support period, so responsibility stays clear over time.
- Audit-ready history: Imports, reimports and status changes build a record that an assessor or market surveillance authority can review.
- Integration effort: Connecting the two tools usually requires custom scripting or manual import, and the approach should be scoped in writing.
Before relying on this workflow, confirm with the project documentation how each tool exports and imports data, and test the pipeline against a sample product.
Which product and business model choices change the work
The shape of a vulnerability handling process depends on what the product is and how it is sold. The support period, the number of third-party components, the release cadence and the delivery model (on-premise software, a SaaS service or a hybrid of the two) each change how many findings arrive, who must act on them and how fast a fix can reach users. A product with a long support period and a large dependency tree carries the heaviest monitoring load for the longest time, so that is where the process needs the most automation and the clearest ownership. Before scoping the work, the manufacturer should write down the support period it intends to commit to, count the components it ships, and record how often it releases. Those three numbers set the size of the monitoring and update pipeline.
Timing decides which products need the full process first. The regulation applies from 11 December 2027, and products placed on the EU market before that date fall under it only if they are substantially modified from that date. The reporting duty in Article 14 is different: it applies to all in-scope products whenever they were placed on the market, and it started on 11 September 2026. A product already on the market therefore needs an operational route for actively exploited vulnerabilities now, even if its full Annex I obligations are not yet in force. Teams should confirm with counsel or their market surveillance contacts which of their products count as substantially modified, because a planned major release may bring an older product into scope.
For SaaS products, the manufacturer runs the software on infrastructure it controls, so it can patch the running service directly, but it still has to decide how dependencies and third-party cloud services feed into the process. For on-premise or self-hosted software, the update reaches customers' environments only when they install it, so the process must include release packaging, a clear update channel and guidance for customers who cannot upgrade immediately. Ask which of these models applies to each product line, who will own the findings register for it, and whether the team can produce a separate security update without bundling new features. Those answers determine the tooling and the staffing, and they should be written down before the process is designed.
What a CRA vulnerability management process costs and who is paid
This table compares the cost components of running a CRA vulnerability handling process, who is paid for each, whether the cost is one-time or recurring, and what drives it up. Use it to structure requests for line-item quotes, since the components are usually bought from different parties.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Internal engineering and security staff time for triage and fixes | Your own staff (salaries), or contractors you engage directly | Recurring across the support period | Number of components in the product, vulnerability volume, severity mix and how many product lines are supported |
| Tooling licences or hosting for the findings tracker | Commercial vendor, cloud or hosting provider; open-source options carry no licence fee but need hosting and configuration | Mostly recurring; initial setup is one-time | Edition or tier chosen, SSO and MFA requirements, number of users and projects, and whether the tool is self-hosted |
| Implementation partner fees for process design and tooling setup | Implementation partner, paid under a written fixed scope | One-time for the initial build, with possible later change requests | Number of products in scope, existing PSIRT or SBOM maturity, integrations with build pipelines and ticketing systems |
| Assessment fees for independent review where applicable | Independent auditor or notified body, not the implementation partner | Periodic, tied to the assessment route and any re-assessment | Conformity assessment route for the product class, scope of the technical documentation, and number of assessments |
| Support retainers for ongoing testing or upgrades | Implementation partner or other service provider under a retainer | Recurring, usually on a set cycle | Frequency of security testing, upgrade cadence of self-hosted tools, and how much incident response is included |
| Keeping security updates available for the support period | Your own hosting, storage and release teams | Recurring for the full period, including the 10-year minimum where it applies | Number of released versions, artifact retention and archive storage, and how long the support period runs |
What usually delays the project or inflates its cost
Most CRA vulnerability programs stall for the same few reasons: the team cannot tell what it ships, it spends effort on findings that do not matter, and it has no durable record of what it decided. Each pitfall below has a concrete step that keeps the work bounded across the support period.
No component inventory
Without a current list of the components in each release, a new advisory cannot be matched to the products it affects. Teams then search by hand across repositories, container images and vendored code, and the same question is answered again for every disclosure. Before anything else, generate a component list for each shipped version and store it with the release. Check that the list includes transitive dependencies and container base images, not only direct libraries.
Treating every CVE as a must-patch
Teams that read the regulation as requiring a fix for every published vulnerability create a backlog that never closes and pulls engineers away from real product risk. The Commission's FAQ states that a patch is not required for every vulnerability found in the support period. Set a written triage method that weighs severity, exploitability and impact on your product, and decide which findings need an update, a workaround advisory or a configuration change.
Bundling security and feature updates
When a security fix ships inside a feature release, customers cannot apply it without accepting unrelated behavior changes, and the fix is delayed by the feature schedule. Annex I requires security updates to be provided separately from functionality updates where technically feasible. Plan a separate release track for security fixes, and record in each release note why a change could not be split if you bundle one.
No record of risk decisions
A vulnerability that is deferred or accepted without a written rationale looks the same to an assessor as one that was ignored. Decisions made in chat or in a ticket that is later closed are hard to reconstruct during a market surveillance inquiry. For each finding, record the component, the affected versions, the risk assessment, the decision, the owner and the date reviewed. Keep this record in a tool that retains history, such as a findings tracker with an audit trail.
Upstream dependencies without a monitoring owner
Advisories for a library often arrive from the upstream project, a vendor or a public database before anyone on your team reads them. If no named person watches each upstream source, a critical flaw in a widely used component can sit unassessed for weeks. Assign an owner for each significant dependency, subscribe them to its advisory channel, and state in the process how long an upstream advisory may wait before triage.
No plan for keeping old updates available
Article 13(9) requires each security update to remain available for at least 10 years after issue or for the rest of the support period, whichever is longer. Teams often plan for the current release only, so artifacts, signing keys and build pipelines for older versions are lost. Confirm now where each released artifact and its signing material are stored, who can retrieve them, and how a rebuild would work if a toolchain is retired.
Who owns the process, who builds it and who assesses it
Your organization owns the vulnerability handling process under the CRA. That includes the policy, the decisions about which vulnerabilities must be fixed and how fast, and everything you tell customers and the public. Regulators and assessors will hold you accountable for these decisions, not your tooling vendor or consultant, so the people who make them need documented authority and enough technical depth to defend them.
- Policy and scope: Approve a written vulnerability handling policy that covers every product, component and support period in scope.
- Risk decisions: Decide, and record the reasoning for, whether a newly known vulnerability must be fixed before release or can be handled through a workaround or advisory.
- Customer communication: Own the advisories, release notes and user notices that explain risks and remediation.
- Publication and update availability: Decide what is published and confirm that security updates remain available for the required period.
- Staffing: Name accountable owners in engineering, product and support, and fund them for the full support period.
Before engaging any outside party, confirm internally who signs off on risk decisions and where the records of those decisions will be kept.
An implementation partner such as DeployOpen can build the systems that make the process work and prepare the evidence your team and assessors will review. DeployOpen plans, implements and integrates self-hosted open-source platforms inside your own infrastructure, and runs security testing where it is contracted. The partner does not make your risk decisions and does not issue any report, attestation or certificate.
- Tooling: Deploy and configure open-source vulnerability tracking, such as OWASP Dependency-Track and DefectDojo, inside your environment.
- Integrations: Connect scanners, build pipelines, component inventories and ticketing so that findings flow into one record.
- Documentation: Prepare procedures, runbooks and workflow descriptions that match how the tools actually operate.
- Evidence: Set up logs, retention and reports that show vulnerabilities were identified, triaged and remediated over time.
- Security testing: Where contracted, test applications, APIs and infrastructure to find vulnerabilities before release.
Before signing, ask for a written, fixed scope that lists each deliverable, which systems are touched and who keeps the tools running after handover.
An independent auditor, assessor or, for products that require one, a notified body tests whether the vulnerability handling process meets the requirements and issues any report or certificate. Only these independent bodies can do that. Their independence is what gives your customers and regulators confidence in the result, so they must not design the process they later test.
- Testing: Review the policy, sample vulnerability records and check that remediation decisions followed the documented process.
- Conformity route: Determine whether your product follows self-assessment or needs a notified body, based on its classification.
- Reports and certificates: Issue the findings or certificate that the independent body is authorized to give.
- Assessment timing: Agree with the assessor when they will review evidence and which period of records they will sample.
- Separation of roles: Avoid any arrangement where the same firm builds the process and certifies it.
Before engaging an assessor, confirm which conformity assessment route applies to your product and whether the body is authorized for it.
Questions buyers ask about CRA vulnerability management
Must we patch every vulnerability we find?
No. The Commission's FAQ 4.3.1 states that the regulation does not require a patch for every vulnerability found during the support period. The manufacturer's response depends on risk, and the remedy can be an immediate patch, a workaround advisory, updated manuals, or configuration guidance that disables the affected feature. The Commission's guidance describes the obligation as risk-based: you weigh severity, exploitability and impact, along with the risks of delaying a release. You still need a documented decision for each finding, so an assessor can see why a vulnerability was fixed, mitigated or accepted. Your engineers and product owners should agree on those criteria before the first finding arrives.
How long must security updates stay available?
Article 13(9) requires each security update issued during the support period to remain available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer. The clock therefore runs per update, not per product release. Plan storage, signing keys, download channels and documentation for that full period, and confirm with your legal and product teams how the support period applies to each product you place on the market. Ask any hosting or distribution partner how they will keep older artifacts retrievable and verifiable for as long as this obligation runs.
Can our own team run the vulnerability process in-house?
Often yes, if the team has the time, the skills and a clear mandate. The work includes identifying vulnerabilities in your product and its components, triaging them, deciding on remediation, shipping security updates separately from feature updates where technically feasible, and keeping an auditable record. The main cost is staff time, plus the tooling and infrastructure to track findings. Outsourcing usually covers setup, tooling integration, documentation or testing, while your organization keeps ownership of decisions and the final evidence. Whatever you choose, you own the process. An outside partner does not take that responsibility away.
What does this work need from our engineers?
Engineers need to maintain a current component inventory, feed it into a tracker that correlates against vulnerability sources, and triage findings against the product's actual exposure. Typical tasks include reviewing whether a vulnerable library is reachable, writing advisories for customers who cannot upgrade, and building release pipelines that publish security fixes as separate artifacts. Tools such as OWASP Dependency-Track (Apache-2.0) correlate components against sources including the NVD, GitHub Advisories and OSV, and DefectDojo (BSD-3-Clause) imports findings from more than 500 report formats and deduplicates them using per-tool hashcode fields. Check each tool's current feature set before you commit, because some capabilities such as SSO and automatic connectors are limited to DefectDojo Pro.
How does this process connect to Article 14 reporting?
The vulnerability handling process decides what becomes reportable, and Article 14 sets the separate duty to notify actively exploited vulnerabilities and severe incidents. Manufacturer reporting obligations began on 11 September 2026, when ENISA launched the CRA Single Reporting Platform. Your triage workflow therefore needs a fast path for flagging findings that may be actively exploited, with named owners who can assess them and route notifications to the designated CSIRT. Record the timestamps of discovery and decision in the same tracker, so you can show when your organization became aware. Confirm the exact reporting steps and deadlines against the regulation text and the Commission guidance before you rely on them.
Does hiring a partner make us CRA compliant?
No. Compliance is a status your organization holds for its own products, and only the manufacturer can declare conformity. DeployOpen plans, implements, integrates and documents self-hosted open-source tooling inside your infrastructure, and it prepares the processes and evidence your team needs. It does not issue conformity declarations, audit reports or certificates, and it does not replace your obligations under the regulation. Where a conformity assessment route requires it, an independent notified body or other assessor makes that determination. Ask any partner to state in writing which tasks it performs, which remain yours, and what evidence each deliverable produces.
How DeployOpen scopes and prepares the vulnerability process
DeployOpen helps manufacturers set up the vulnerability handling process for their products within their own infrastructure, using self-hosted open-source tooling. The organization keeps ownership of its risk decisions, advisories and updates, while DeployOpen prepares the systems, workflows and records that show the process operates across the support period.
How we scope
- Engagements are fixed-scope, with the products, components and support period agreed in writing first.
- The written scope names which findings sources, tracking tools and advisory channels are in place.
- Ongoing support for the process is available as a retainer after the initial scope is delivered.
How we build
- We deploy a self-hosted dependency tracking tool and connect it to the product's SBOM and component inventory.
- We configure a findings tracker so scanner output is imported, deduplicated and assigned to owners.
- We document the risk-based triage criteria the organization approves for severity, exploitability and impact.
How we hand over
- Handover includes configuration records, runbooks and the workflow for separate security update releases.
- Process documentation maps each step to the Annex I Part II requirements the organization must evidence.
- The organization's staff receive written procedures and retain ownership of all decisions and published advisories.
How we support
- Support covers tool upgrades, backups and configuration changes after the handover is complete.
- Retainers can include continuous security testing to check whether the vulnerability process works in practice.
- Confirm with DeployOpen in writing which support tasks are included, since independent auditors issue any assessment reports.
