How the CRA changes SBOM and vulnerability handling for manufacturers
If you manufacture a product with digital elements sold in the EU, the CRA now requires you to know every component in that product, handle its vulnerabilities across the whole support period and report actively exploited vulnerabilities to the authorities. The reporting duty under Article 14 has applied since 11 September 2026, and the full regulation applies from 11 December 2027. Those dates mean the process has to work for products already on the market, not only for products you have yet to release. The function has three parts: identifying components in a software bill of materials (SBOM), handling vulnerabilities throughout the product lifecycle, and reporting actively exploited ones on the deadlines the regulation sets. Tooling supports the first two parts well and the third only in part, because the legal decisions remain yours.
Annex I Part II requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, and Annex VII places it in your technical documentation. Dependency-Track can ingest CycloneDX SBOMs, correlate components against several vulnerability sources and apply policies, and Trivy can generate an SBOM from a build target or scan an existing one. Confirm with your own engineering team whether the SBOM covers transitive dependencies in each release, because the regulation sets top-level dependencies as the minimum, not the goal. Also decide whether you will share the SBOM with users, since Annex II makes that step optional and only requires you to tell users where to access it if you do.
Article 14 sets three clocks for an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. Each notification goes to the designated CSIRT and to ENISA through the Single Reporting Platform. A scanner can flag a vulnerability, but it cannot establish reliable evidence of exploitation, and that judgment must be recorded with a named owner and a timestamp. Before go-live, rehearse this path with your product security, legal and support teams. DeployOpen prepares systems, controls and evidence for compliance readiness, but it does not issue conformity assessments, attestations or certifications. Whether a notified body is required for your product is a question for the regulation and the Commission guidance, and for your conformity assessment body.
Which CRA requirements the function must meet and how to configure it
This table maps each CRA provision that touches SBOMs, vulnerability handling and reporting to a configuration step in Dependency-Track or Trivy. Read it as a checklist: the left column names the obligation, the middle column the setup that supports it, and the right column the record an assessor or market surveillance authority is likely to ask for. The main takeaway is that the SBOM and VEX data must be complete and current before any reporting clock starts.
| Requirement | Configuration with Dependency-Track and Trivy | Evidence to keep |
|---|---|---|
| Annex I Part II point (1): identify components and document vulnerabilities | Generate a CycloneDX SBOM per product release with Trivy (SBOM output) and upload it to a Dependency-Track project per product version. Confirm the SBOM covers at least top-level dependencies in the format your regulator accepts. | Versioned SBOM files per release, project-to-release mapping, and the vulnerability list generated for each version |
| Article 3(39): SBOM as a formal record of components and supply chain relationships | Scan existing SBOMs as well as build artifacts so dependency relationships come from the build, not from manual lists. Check that the SBOM records component identifiers and relationships, and fill gaps before upload. | Build logs showing which SBOM generator ran, input targets, and any manual corrections with a reviewer name |
| Annex VII point 2(b): SBOM in technical documentation | Store the SBOM file and its hash in the technical documentation repository alongside the release record. Tag each entry with the product version so the documentation matches what was shipped. | Technical documentation index linking each SBOM to a release, with hash and generation date |
| Annex VII point 8: provision to a market surveillance authority on reasoned request | Keep an export procedure: Dependency-Track project export for the requested version, plus the Trivy JSON or SBOM report used to produce it. Test the export on one release before a request arrives. | Written export procedure, a dated test export, and a request log |
| Annex II point 9: user information on SBOM access (only if you choose to share) | If you publish the SBOM to users, configure the publication location and link it in user documentation. If you do not share it, record that decision and the reason in the product file. | Decision record on SBOM sharing and, if shared, the published location and version |
| Article 3(42) and Article 14: actively exploited vulnerability | In Dependency-Track, route notifications for new findings on in-scope projects to a triage channel (email, webhook or Jira). Add a reviewer step that records reliable evidence of exploitation and the date you became aware, since that date starts the 24-hour clock. | Triage log with awareness date, evidence reviewed, and the decision made, timestamped |
| Article 14(1) and (2): early warning (24 hours), notification (72 hours), final report (14 days) | Prepare report templates from DefectDojo or Dependency-Track findings so the affected component, versions and available fix can be filled in quickly. Confirm submission through ENISA's Single Reporting Platform and the designated CSIRT before go-live. | Submission copies with timestamps, and a final report after a corrective or mitigating measure is available |
| Vulnerability exploitability records (VEX) | Import CycloneDX VEX documents into Dependency-Track to record components marked not affected, with justification. Review VEX entries at each release so suppressions do not carry forward unchecked. | VEX files per release, justification text, and reviewer sign-off on each suppression |
| Offline or restricted build environments | Mirror Trivy databases (trivy-db, trivy-java-db, trivy-checks) into an internal registry and point builds at them with the repository flags. Schedule mirror updates and record the database version used for each scan. | Mirror update schedule, database version logged per build, and the transfer record for any air-gapped copy |
How the toolchain changes for connected builds, air-gapped plants and legacy products
In a connected build pipeline, the toolchain can pull vulnerability data on every run. Trivy generates an SBOM for each build artifact, Dependency-Track ingests that SBOM and correlates its components against vulnerability sources, and findings are triaged against the product's own release history. The main maintenance job is keeping the scanner databases and the Dependency-Track vulnerability mirror fresh, because a stale database quietly stops finding new issues.
- Build-time SBOM generation: Run Trivy against each release artifact so the SBOM reflects what actually shipped, not only what a manifest declares.
- Scheduled database refresh: Confirm the Trivy database and Dependency-Track correlation data update on a schedule your pipeline controls, and alert when an update fails.
- Machine-readable output: Keep the SBOM in CycloneDX format so Dependency-Track can consume it and the technical documentation can point to the same file.
- Top-level dependency coverage: Verify the SBOM covers at least the top-level dependencies, since Annex I Part II point (1) sets that minimum.
- Release-linked records: Store each SBOM and scan result with the release it describes so reporting can show which versions were affected.
Check whether your pipeline records the SBOM version that accompanied each shipped release, because that link is what a market surveillance request will test.
On an air-gapped or restricted engineering network, the scanner cannot reach public vulnerability sources, so the databases must be brought in by controlled transfer. Trivy's databases (trivy-db, trivy-java-db and trivy-checks) are published as OCI images that can be mirrored to an internal registry, or downloaded on a connected machine and copied into the offline cache directory. Either way, the team must decide who performs the transfer and how often it happens.
- Mirror or copy path: Choose between an internal registry mirror, selected with
--db-repositoryand related flags, and a file transfer into the cache db directory. - Java database: Include trivy-java-db if the product uses Java dependencies, because it is a separate data set from trivy-db.
- Transfer records: Log each import with the source date, checksum and operator so auditors can trace which data the scans used.
- Dependency-Track feeds: Plan how its vulnerability data reaches the offline instance, since it does not refresh itself without a path.
- Stale-data alarms: Set a check that flags any scan run against a database older than your agreed threshold.
Confirm with your security team how often the transfer runs and whether the transfer media itself is approved under your network policy, because the Trivy documentation warns that mirrors must be kept updated.
Products placed on the EU market before 11 December 2027 fall under the regulation only if they are substantially modified from that date, according to Article 69(2) and (3). The Article 14 reporting obligations are different: they apply to all in-scope products whenever they were placed on the market. A legacy product therefore may not need the full set of Annex I requirements yet, but it may still need a way to report actively exploited vulnerabilities.
- Scope check: Determine whether each legacy product is in scope and whether any planned change would count as a substantial modification.
- Reporting path for all in-scope products: Make sure an actively exploited vulnerability in a legacy product can still be notified through the Single Reporting Platform.
- Component records: Build an SBOM for legacy products where the data exists, because the gap is often discovered only when an incident forces the question.
- Modification trigger: Tie any substantial change to a new SBOM and documentation review, so the scope decision is revisited at each release.
- Support boundaries: Record which components are no longer maintained upstream, since that affects both vulnerability handling and any later modification.
Ask legal and product compliance to confirm the scope position for each product line in writing, since the answer depends on what changes are planned and how the product is classified.
Which open-source platforms fit each CRA duty
The CRA asks manufacturers to know their components, handle vulnerabilities over the product's life and report actively exploited ones. The platforms below cover the inventory, scanning, findings and notification steps, and each one has a specific role. The reporting pathway itself runs through the ENISA Single Reporting Platform, not through these tools.
Dependency-Track as the inventory and risk system
Dependency-Track (Apache-2.0) ingests CycloneDX SBOMs and CycloneDX VEX documents, correlates components against sources such as the NVD, GitHub Advisories, OSV and Trivy, and applies security and license policies per project. It gives you one place to hold the component list the CRA requires in technical documentation. Check whether your build pipeline can publish SBOMs per release, how VEX statements are reviewed and who signs off on policy exceptions.
Trivy for SBOM generation and scanning
Trivy (Apache-2.0) generates SBOMs for container images, filesystems, Git repositories and virtual machine images, and it can also scan an existing SBOM. This matters because the CRA expects top-level dependencies to be identified in a machine-readable format. Confirm which SBOM formats your release process needs, and plan how the vulnerability database will be updated if build servers cannot reach the internet.
DefectDojo for findings workflow and SLAs
DefectDojo receives findings from scanners and tracks each one through triage, ownership and remediation deadlines. Dependency-Track has native DefectDojo support, so component vulnerabilities can flow into the same queue as code and container findings. For CRA work, check that each finding keeps a record of when you became aware of it, because the reporting clock depends on that date. Confirm how deduplication handles repeated findings across releases.
Trivy Operator for Kubernetes-hosted products
Trivy Operator (Apache-2.0) scans a Kubernetes cluster continuously, for example when a new Pod is created, and stores vulnerability, configuration and exposed secret reports as Kubernetes custom resources. This suits products you run as a hosted service or deliver as a cluster workload. Confirm how often reports are refreshed, who reviews them, and whether the findings can be exported to your Dependency-Track or DefectDojo instance.
Jira and Slack notifications for routing
Dependency-Track sends configurable notifications to Slack, Microsoft Teams, Mattermost, webhooks, email and Jira. Use these to route new critical component findings to the team that owns the affected product, not to a shared channel nobody reads. Your routing rules should match the CRA clock: a finding that may be actively exploited needs to reach the person who can file the ENISA notification within the deadlines. Confirm who holds that role and test the alert path before go-live.
How to run the 24-hour, 72-hour and 14-day reporting clock
Article 14(1) and (2) of Regulation (EU) 2024/2847 require a manufacturer to notify any actively exploited vulnerability in its product at the same time to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform. The clock has three stages: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. These obligations apply from 11 September 2026, and ENISA launched the initial operating capability of the platform on that date. Confirm with your national CSIRT coordinator how it wants submissions routed, and confirm that your reporting contacts are registered on the platform before you need them.
The clock is set by when you become aware, so the trigger matters as much as the deadline. A Dependency-Track alert on a newly published CVE in a shipped component, or a Trivy finding in a released image, is not automatically an actively exploited vulnerability. Under Article 3(42), it qualifies only where there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Treat each alert as an input to a documented triage decision, record who made the call, when, and on what evidence, and keep the decision separate from the ticket that fixes the component. A regulator will ask for that record, and it should exist before any incident.
Write the triage workflow now, while nothing is on fire. It should name the roles that can declare awareness (product security lead, incident commander, legal counsel), the sources they monitor (Dependency-Track notifications routed to a monitored channel, vendor advisories, threat intelligence feeds, customer reports), the evidence threshold for escalation, and the template for each of the three submissions. Rehearse the workflow with a tabletop exercise so the first 24 hours are not spent deciding who owns the decision. Ask any implementation partner to show how alerts from Dependency-Track and Trivy reach these roles and how each decision is timestamped and stored.
Evidence market surveillance authorities and auditors will ask for
This table lists the records a market surveillance authority or a conformity assessment body is likely to request for the CRA, the tool or export that typically produces each one, and what to confirm before relying on it. Read it as a checklist of records to keep current from the first release onward, not as proof that any single record meets the regulation.
| Evidence record | Producing component | What to confirm or keep |
|---|---|---|
| SBOM file in the technical documentation | Dependency-Track project export or Trivy CycloneDX output | Machine-readable format covering at least top-level dependencies, stored with the technical documentation for each product version |
| SBOM version history per release | Dependency-Track project versions and stored BOM uploads, plus Trivy SBOM output archived per build | A retained SBOM for every released version, linked to the build identifier and the component list it describes |
| Vulnerability triage records with VEX justifications | Dependency-Track analysis decisions exported as CycloneDX VEX, with DefectDojo finding history | Who assessed each finding, the justification given, the date, and whether the decision changed between releases |
| Timestamps of notifications and SRP submission record | Ticketing audit log and the notification record kept by the manufacturer, reconciled with the CSIRT and ENISA submission receipts | Times of awareness, early warning, vulnerability notification and final report, held against the 24-hour, 72-hour and 14-day clocks in Article 14 |
| Component-level license records | Dependency-Track license data using SPDX license IDs, with Trivy license scan output | License identifier per component and version, with any exceptions approved and dated |
| Database versions and scan dates used | Trivy database metadata from the scan run, Dependency-Track vulnerability source sync logs, and scanner configuration in version control | Database version, feed source and scan timestamp recorded with each report, including mirrored or offline databases used in air-gapped builds |
What open-source tooling alone does not satisfy under the CRA
Dependency-Track and Trivy produce the component inventory and vulnerability data the CRA asks for, but several obligations depend on decisions, documents and third-party agreements that no scanner can generate. The cards below cover the gaps manufacturers should plan for before the reporting duties apply.
Reporting needs a human decision process
Article 14 requires notification of actively exploited vulnerabilities through the Single Reporting Platform, with an early warning within 24 hours, a notification within 72 hours and a final report within 14 days after a corrective measure is available. Each step needs a named owner, an approval path and an organization account on the platform. Confirm with ENISA's platform FAQ how accounts and submissions are handled before your first incident, and rehearse the chain with your security and legal teams.
Exploitation judgment cannot be automated
Article 3(42) defines an actively exploited vulnerability as one with reliable evidence that a malicious actor exploited it in a system without the owner's permission. A CVE feed or a severity score does not establish that evidence. Your team must weigh telemetry, customer reports, vendor advisories and threat intelligence, then record why a finding was or was not classed as exploited. Keep that reasoning in the case record, because a regulator will ask for it.
Technical documentation is not tool output
The technical documentation, the risk assessment and the statements on support periods are written documents that Annex VII requires you to maintain. Dependency-Track and Trivy can supply the SBOM referenced in Annex VII point 2(b), but they cannot describe your design, your risk reasoning or how long you commit to security updates. Assign an owner for each document, version it with the product release and check that the SBOM in the file matches the shipped build.
Supplier data for components you do not build
Annex I Part II requires you to identify components in your product, but scanners only see what you ship in a file system or image. Third-party firmware, embedded modules and closed libraries often lack a usable SBOM. Put SBOM and vulnerability notification duties into supplier contracts, specify the format and top-level dependency coverage, and record gaps as known unknowns in your risk assessment.
Notified bodies for class I, class II and critical products
Most products follow self-assessment under module A, but class I important products may need a notified body where harmonized standards are not fully applied, and class II and critical products always do. Under Article 32, the conformity assessment route depends on the Annex III and Annex IV category, which the Commission's 2025 implementing regulation describes. Confirm your category early, check which harmonized standards are published for it and budget for assessment lead times with the body you choose.
Mirror freshness in air-gapped setups
Trivy's vulnerability databases are published as OCI images that must be mirrored into an internal registry, or copied to an offline cache when the network is isolated. The Trivy docs warn that mirrors must be kept updated. A stale mirror produces clean-looking reports for components with newer advisories, which weakens the evidence trail. Record the database version and transfer date with each scan, and set a documented refresh cadence that your auditors can check.
Questions manufacturers ask before hiring help with CRA SBOM and reporting
What drives the cost of CRA SBOM and vulnerability handling work?
The main drivers are the number of products, how many build pipelines produce each one, how many supplier components sit inside them, and how much scanning and tracking already exists. A single product with one pipeline and clean dependency manifests is far less work than a product line with several languages, firmware images and third-party binaries. Costs fall into one-time items (designing the SBOM generation in CI, mapping the product architecture, setting up Dependency-Track and the reporting path) and recurring items (keeping SBOMs current with each release, triaging new CVEs, and handling notifications). Ask any provider for a quote that lists products, pipelines, supplier components and the recurring triage model separately.
How long does a CRA SBOM and reporting project take?
No duration is supplied for this work, and the scope agreed in writing is what sets it. The timeline depends on the number of products, the state of their build systems, how quickly supplier information arrives, and whether a notified body is involved for the product class. Manufacturers should also check the dates that matter for their planning: the Article 14 reporting obligations apply from 11 September 2026, while the main body of the regulation applies from 11 December 2027 (Article 71(2)). Ask a provider for milestones tied to specific products and build pipelines rather than a single end date.
What does our team need to provide before an engagement starts?
Four inputs matter most. First, read access to source repositories, build pipelines and artifact registries so SBOM generation can be tested on real builds. Second, a description of the product architecture, including firmware, operating system layers, containers and any hardware-dependent software. Third, contacts at key suppliers who can provide component data or respond to vulnerability questions. Fourth, a named triage owner who decides how findings are classified and who can approve a corrective or mitigating measure. Without that last role, the 24-hour early warning and 72-hour notification steps have no one accountable for them.
Can our own engineers handle CRA SBOM and vulnerability handling without outside help?
Many manufacturers with mature build systems can do parts of this in-house, particularly SBOM generation and routine triage. The harder parts are usually the regulatory mapping to Annex I Part II, consistent evidence for the technical documentation, and running the reporting workflow under deadline pressure. Trivy can produce an SBOM for a target and scan existing SBOMs, and Dependency-Track consumes and produces CycloneDX SBOMs and VEX documents, so the tooling is open source. Teams should test whether they can meet the early warning, notification and final report steps in an exercise before relying on them. DeployOpen implements and documents these systems in the client's own infrastructure, but the manufacturer keeps responsibility for its products and decisions.
Does the SBOM for our product have to be published?
No. The regulation requires the SBOM in the technical documentation (Annex VII point 2(b)) and requires it to be provided to a market surveillance authority on reasoned request (Annex VII point 8). Annex II point 9 requires user information on where to access the SBOM only if the manufacturer decides to make it available to users. Whether to publish is a commercial and security decision, and manufacturers should weigh it against what the SBOM reveals about their components. Confirm the final position against the regulation text and the Commission guidance before deciding.
What are the maximum CRA fines for non-compliance?
Article 64 sets the maximum administrative fines. Breaches of Annex I and of Articles 13 and 14 can reach EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other listed obligations can reach EUR 10 million or 2%, and incorrect or misleading information given to authorities can reach EUR 5 million or 1%. These are ceilings, not expected amounts, and enforcement depends on national authorities. The figures show why reporting discipline and documented SBOM handling matter, but they are context for planning rather than a cost estimate for compliance work.
Does DeployOpen issue a CRA certificate for our products?
No. DeployOpen does not issue CRA certificates, attestations or audit reports. For most products, the manufacturer follows self-assessment under module A, while a notified body is needed for certain class I important products, class II products and critical products (Article 32). DeployOpen prepares systems, controls and evidence, such as SBOM pipelines, vulnerability tracking and reporting records, so that a manufacturer or an independent body can assess them. Confirm with the relevant conformity assessment body which route applies to each product.
How a CRA readiness engagement moves from inventory to tested reporting
The engagement follows the order a manufacturer needs to meet CRA obligations: know what is in the product, produce and maintain the SBOM, run vulnerability handling, rehearse the Article 14 reporting clock, and assemble the evidence. Each phase is agreed in a written fixed scope before work starts, and each closes with a checkable output.
Inventory products and components
DeployOpen works with the manufacturer's engineering and product teams to list each product with digital elements, its versions, its build pipelines and its top-level dependencies, and to confirm which products fall under the regulation and which may be in scope for Article 14 reporting. The output is a signed-off inventory of products, components and owners, along with open questions about scope that the manufacturer must settle with counsel or its notified body where one is needed. The step is done when every product has a named owner and a documented component source.
Build the SBOM pipeline
Engineers configure build pipelines so that each release produces a machine-readable SBOM in a commonly used format covering at least top-level dependencies, using Trivy for container images, filesystems and existing SBOM inputs where they fit the product's build. The team stores each SBOM against the release it describes and confirms that the output is reproducible across at least one build. The step is done when a test build produces a valid SBOM for each in-scope product and the artifact is archived with its release record.
Configure Dependency-Track and policies
DeployOpen deploys Dependency-Track, uploads the SBOMs, and sets portfolio and per-project policies for security, license and operational risk, along with the notification channels and the ownership of each project. The configuration also defines how VEX statements are recorded for vulnerabilities judged not exploitable in a given product. The step is done when a sample upload triggers the expected findings, notifications reach the named owners, and the policy settings are exported and documented.
Write the triage and reporting runbook
Product security, engineering and legal staff agree a written runbook covering how a vulnerability is triaged, who decides whether it is actively exploited in the sense of Article 3(42), who drafts each notification, and who approves it before it goes to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform. The runbook maps each stage to the early warning, vulnerability notification and final report deadlines set in Article 14. The step is done when the runbook is approved by named roles and each reporting step has a named owner and a documented input.
Tabletop the reporting clock
DeployOpen facilitates a tabletop exercise using an illustrative scenario in which a component in a shipped product is reported as exploited, and the team works through the runbook against the Article 14 clock. Facilitators record where handoffs were slow, where data was missing from the SBOM or Dependency-Track records, and where the decision on exploitation was unclear. The step is done when a written exercise report lists each gap, an owner and a fix date agreed with the manufacturer.
Assemble the evidence pack
The team gathers the technical documentation items that reference the SBOM, the pipeline and policy configurations, VEX records, triage decisions, the runbook, the tabletop report and the reporting records, and maps each item to the relevant CRA requirement. The pack is organized so that it can be produced to a market surveillance authority on reasoned request. The step is done when the manufacturer's compliance lead has reviewed the pack and confirmed it is complete for the agreed scope. DeployOpen prepares this evidence; it does not issue conformity assessments or certifications.
How DeployOpen scopes and supports CRA SBOM and vulnerability handling
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the SBOM pipeline, vulnerability tracking and reporting records stay under the manufacturer's control. Engagements start with a written scope that ties each CRA obligation to a specific tool, workflow and piece of evidence.
How we scope
- We confirm which products with digital elements are in scope and which of them were placed on the market before the applicable dates.
- We map Annex I Part II vulnerability handling duties and Article 14 reporting duties to named owners, tools and records.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We set up Dependency-Track and Trivy so SBOMs are generated for each product build in a machine-readable format.
- We configure component correlation, policies and notifications, and test them against known vulnerable sample components.
- We mirror Trivy databases to an internal registry where the environment requires it, and document how updates are kept current.
How we hand over
- We document the SBOM generation, triage and escalation procedures in a form your engineering and compliance teams can run.
- We provide a reporting runbook covering the 24-hour, 72-hour and 14-day Article 14 milestones and who triggers each one.
- We deliver the technical documentation extracts and evidence records that your team and any assessor can review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We help you keep pace with new harmonized standards and Commission guidance by updating procedures and configurations.
- Confirm with your notified body or market surveillance contacts which evidence formats they expect before the scope is signed.
