CRA compliance starts with
SBOMs and CBOMs
Reporting obligations begin September 2026. Full compliance by December 2027. Know what you’re shipping before you have to prove it
Maximum CRA fine for essential requirement violations. [1]
of organisations have started SBOM implementation for CRA. [2]
Sept 2026 → Dec 2027
Reporting duties start; full obligations follow. [3]
CRA compliance doesn't forgive what you didn't know was there
Annex I requires products with digital elements to be designed and documented to a defined security baseline, including how data confidentiality is protected. A manifest-based SBOM shows what was declared — not the vendored code, copied snippets, or cryptographic algorithms buried inside dependencies that never made it into a package file.
SCANOSS scans source code directly, generating both an SBOM and a CBOM your CRA technical documentation can rely on.
The compliance problem
Most CRA gaps start with an assumption. These are the four that create exposure — and how SCANOSS addresses each one.
"We're not in scope"
If your product connects to a network or device and is placed on the EU market, it’s a “product with digital elements” under the CRA — hardware or software, commercial or open source steward.
SCANOSS scans your codebase regardless of classification, so your inventory is ready before scope is even in question.
"We already have an SBOM"
A manifest-based SBOM only shows what was declared. Vendored code, copied snippets, and undeclared dependencies don’t appear — and they’re still your liability under Annex I.
SCANOSS detects components and cryptographic implementations at snippet level, producing an SBOM and CBOM that reflect what’s actually in your code.
"We'll deal with it by 2027"
Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026 — over a year before full enforcement.
SCANOSS component-level data feeds directly into the 24-hour reporting window Article 14 requires.
"Our suppliers handle this"
Manufacturers remain accountable for every component they ship, including third-party and open source code they didn’t write.
SCANOSS provides traceable, verifiable component and cryptographic data that holds up as evidence in a conformity assessment.
Key CRA obligations
What the regulation actually requires, broken down.
Annex I
Essential cybersecurity requirements
Products with digital elements must be designed, developed and maintained to a baseline security standard, documented and evidenced.
Article 13
Manufacturer obligations
Manufacturers must identify and document components, including third-party and open source ones, throughout the product lifecycle.
Article 14
Vulnerability and incident reporting
Actively exploited vulnerabilities and severe incidents must reach ENISA within 24 hours of the manufacturer becoming aware.
Article 64
Penalties
Non-compliance with essential requirements carries fines of up to €15 million or 2.5% of global turnover, whichever is higher.
How it works
Integrate in your workflow
Run SCANOSS through CLI, API, or CI/CD
SCANOSS scans source code and dependencies to build a complete inventory of components, licences and vulnerabilities.
Scan the codebase
Produce SBOM and CBOM
Generate CycloneDX-format SBOM and CBOM as audit-ready documentation for conformity assessment.
Works where you build
