ComparisonEngineering-side tooling

SBOM and application security tools vs CVD Portal

Scanners, SBOM generators and posture platforms that produce CRA evidence without producing the CRA file. How does SBOM and application security tools compare to CVD Portal for an EU manufacturer subject to the Cyber Resilience Act?

Headquarters
Various vendors, mostly United States and Israel
Category
Engineering-side tooling
Pricing model
Typically an annual subscription priced on request, scaled by repositories, developers or applications.

How they compare on CRA-critical features

Five differences between engineering-side security tooling and a product conformity workspace under Regulation (EU) 2024/2847. The first row is where the tooling is stronger.

Feature
SBOM and application security tools
CVD Portal
SBOM generation and component vulnerability tracking
Core strength. Usually deeper than ours
Supported, and linked to the Annex I Part II duty it evidences. Import an existing SBOM rather than duplicating the scanner
Annex III / Annex IV classification and the Article 32 route
Not advertised
Free classifier. The result decides which requirements apply and whether the product can self-assess
Annex I Part I applicability table with justifications
Not advertised
Every essential requirement marked applicable with a reference or not applicable with a justification that has to survive review
Annex VII technical documentation, EU Declaration of Conformity, CE marking
Evidence for the file. Not the file itself
Generated per product and versioned with the record
Article 13 CVD policy and whitelabel single point of contact
Not advertised
Included on the Free tier, under the manufacturer's own domain

Where SBOM and application security tools is strong

  • +They do the part that is genuinely hard to do manually. Enumerating components across a real codebase, keeping the list current through every release and matching it against vulnerability feeds is not work a compliance team can do in a spreadsheet.
  • +They already live in the development pipeline, so evidence is produced continuously where the change happens instead of being reconstructed before an audit.
  • +Most of the Annex I Part II vulnerability handling duties map onto capabilities this category already has, particularly the SBOM, addressing vulnerabilities without delay, and testing.
  • +Several publish free or open-source tiers, which puts the SBOM within reach of a manufacturer with no compliance budget.

Where the tooling stops

  • !The unit is the repository, the application or the finding. The CRA's unit is the product with digital elements as placed on the market, which is what carries a classification, a technical file, a declared support period and a CE mark.
  • !Classification is upstream of all of it and is not a scanning problem. Whether a product is default, Class I, Class II or critical under Annex III and Annex IV decides which requirements apply and whether it may self-assess at all.
  • !Annex I Part I is a set of properties the product has to have, evidenced and justified requirement by requirement. It is an argument on the record, not a scan result.
  • !The conformity outputs have no equivalent in this category. The Annex VII technical documentation, the EU Declaration of Conformity, the Annex VI simplified declaration and the CE marking are documents that get signed and held for ten years.
  • !Article 13 needs a public page and a monitored contact under the manufacturer's own domain, which is a website obligation rather than a pipeline one.

The CRA gap

This category answers "what is in our software and what is wrong with it". The CRA asks "can this product carry a CE mark, and can you prove it for the whole support period". The first is an input to the second and does not substitute for it. The practical test is simple: if an authority asked today for the technical documentation for one named product, with the Annex I applicability decisions and the justification for everything marked not applicable, could the scanner produce it. It produces the evidence that goes inside it.

Why teams pick CVD Portal for CRA

Five reasons a conformity workspace sits on top rather than instead. Keep the scanners.

  1. 1

    Starts where the tooling stops, at classification, and carries the product through to the Declaration of Conformity and the CE marking checklist.

  2. 2

    Imports rather than duplicates. SBOMs and vulnerability evidence from existing tools attach to the specific Annex I requirement they answer.

  3. 3

    Holds the file true over time. Evidence validity windows and documentation review cycles run against the product's declared support period, per Article 31(2).

  4. 4

    Covers the two obligations that start on 11 September 2026 in one place, the Article 13 policy and single point of contact and the Article 14 reporting cascade.

  5. 5

    The Article 13 baseline is free, so the gap can be closed before there is budget for anything else.

Frequently asked

Which tools do I need for CRA compliance?
Two different kinds, and they are usually separate products. An engineering-side tool to generate the SBOM and keep component vulnerabilities tracked, which covers much of Annex I Part II. And a conformity record to classify the product, decide and justify the Annex I Part I requirements, hold the Annex VII technical documentation, issue the EU Declaration of Conformity, and run the Article 13 and Article 14 obligations. Most manufacturers already have the first and are missing the second.
Our security scanner says we are CRA ready. Are we?
It is telling you something true about a narrow slice. Scanners assess the software's vulnerability posture, which maps onto Annex I Part II. CRA readiness also requires an Annex III classification, an Annex I Part I applicability table with justifications, Annex VII technical documentation, a signed Declaration of Conformity, a CE mark, a published disclosure policy under Article 13 and a working Article 14 reporting path. Run the free classifier first, because the classification decides how much of the rest applies.
Is CVD Portal a scanner?
No. It does not scan source, containers or dependencies, and it is not trying to displace the tools that do. It stores what they produce, links each item to the CRA requirement it evidences, and tracks when it goes stale against the product's support period.
What does the CRA require that a scanner cannot produce?
The classification decision under Annex III and Annex IV and the Article 32 conformity route that follows from it. The Annex I Part I applicability table with a justification on every requirement marked not applicable. The Annex VII technical documentation. The EU Declaration of Conformity and its Annex VI simplified form. The CE marking. The Article 13 published policy and single point of contact. The Article 14 submission package to ENISA and the national CSIRT.
Where does CVD Portal stop?
It prepares and maintains the conformity file. It does not act as a conformity assessment body. Module A self-assessment is open to default-class products. Important products (Annex III) and critical products (Annex IV) need a notified body or a European cybersecurity certification scheme, because no CRA harmonised standard is cited in the Official Journal yet. For those, CVD Portal prepares the technical file and the Annex I evidence the assessment body asks for, and does not replace it.

Keep the tooling, add the conformity record

Import the SBOM and the vulnerability evidence you already produce, then classify the product and build the file around them. The Article 13 baseline is €0/month and no card is required to start.