CRA is not a vulnerability scanner

A manufacturer who treats the Cyber Resilience Act as “scan the firmware and file the CVEs” will fail the file, even if the scanner is excellent. Regulation (EU) 2024/2847 is a product-safety rule for products with digital elements. It asks you to show what you place on the Union market, what risk you accepted, what the product is made of, and how you will keep it through the support period.

Vulnerability handling stays. It is one duty inside Annex I Part II and the Article 14 clock. It is not the product.

Why the scanner story is so common

Scanners have a demo. A PDE catalogue does not. A risk row tied to Annex I does not light up a dashboard in five minutes. So the first tool that appears in a CRA conversation is often the one the security team already pays for.

That tool answers a narrow question: which known weaknesses exist in this build. CRA asks a wider one: are you allowed to place this product on the market, and can you still support it when an authority or a CSIRT calls. Those are different files.

If the only CRA artefact you can export is a vulnerability report, you do not have a CRA system. You have a scanner with a new cover slide.

The product map comes first

The primary addressee is the manufacturer: the person who places a product with digital elements on the Union market under their name or trademark. That product can be a device, standalone software or a component sold separately. Importers and distributors pick up duties of their own. None of that is visible in a scan.

Before you talk about CVE queues you need a catalogue. Name, version, type, markets, the date you made it available, the support end with month and year. CRA applies per product, not once for the whole company. A substantial modification is a new placing on the market.

Without that map you cannot say which SBOM belongs to which SKU, which Annex I gaps are open, or which CSIRT you notify when Article 14 starts on 11 September 2026. A scanner that does not know the product identity is scanning a blob.

Risk is tied to Annex I, not to a CVSS colour

Article 13 wants a cybersecurity risk assessment across the lifecycle, not a slide before launch. Annex I then splits in two.

Part I is product properties: an appropriate level of cybersecurity for the risk, no known exploitable vulnerabilities at placing on the market, secure defaults, updates (including automatic ones with a clear opt-out), access control, integrity, confidentiality, a smaller attack surface, data minimisation.

Part II is vulnerability handling: identify and document vulnerabilities, including an SBOM; patch during the support period; tests; a public disclosure policy; coordinated disclosure; fixes without undue delay.

A scanner can feed Part II. It cannot decide whether the default password is still admin, whether the update can be refused, or whether the attack surface grew when you added remote diagnostics. A gap that lives in a side spreadsheet is not an assessment. The risk row has to point at the requirement it fails.

“No known exploitable vulnerabilities at placing on the market” is also not “the last scan was clean on Friday”. It is a statement about the product you are about to ship, with the SBOM of that version and an owner who can defend it.

SBOM is evidence, not a PDF in a drawer

Due diligence on third-party components sits on the component. The SBOM has to match the version you actually ship. The store build and the SBOM version that drift after two sprints is the usual failure.

The SBOM also feeds the vulnerability queue. That queue is real work: Article 14 starts on 11 September 2026 for actively exploited vulnerabilities and severe incidents. Early warning in 24 hours, full notification in 72 hours, then a final report, through the single reporting platform to the CSIRT of the main establishment and to ENISA.

A scanner that dumps 400 CVEs into a spreadsheet does not give you a 24-hour owner. It gives you noise. The operational cut is: which of these is in the shipped SBOM, which is actively exploited, which product does it hit, who files the early warning.

The technical file is what an authority can demand

By 11 December 2027 a product placed on the market must meet Annex I, complete conformity assessment, carry an EU declaration and the CE mark. Market surveillance can ask for the file years later.

That file is not a vulnerability report. It is the product identity, the risk assessment, Annex I evidence, the SBOM, the support period, instructions, the declaration and the mark. If one of those is missing, the CE path is not closed.

Most default-class products stay on module A. Module A still needs that file. Buying a better scanner in 2027 does not write the declaration.

What a scanner is good for, inside CRA

Keep the scanner. Point it at the build that matches the SBOM. Use it to open Part II items and to refresh the queue. Do not use it as:

• the product catalogue,
• the Article 13 assessment,
• the Annex I checklist,
• the support-period register,
• the EU declaration,
• the Article 14 playbook.

Those objects have owners, dates and product keys. A finding does not.

What to put in the system

Crado AI is built around the full loop, on-premise:

1. PDE catalogue - what you place on the market.
2. Risk and Annex I - which requirements are met, which are not.
3. SBOM - own and third-party components, linked to CVE.
4. Article 14 - the 24h / 72h clock.
5. Technical file and CE - what you can show before the product leaves the warehouse.

Vulnerability handling stays. It is not the product. If your current CRA plan is a scanner renewal and a 2027 CE workshop, the plan is the slide, not the file.