"EU CRA 2027: SBOM Requirements Every Software Company Must Know"

The EU Cyber Resilience Act (CRA) is the most significant software security regulation in history. By 2027, every manufacturer selling digital products in the EU market must provide a Software Bill of Materials (SBOM) for their products.

This guide covers everything you need to know: what the CRA requires, when it takes effect, and how to comply.

What is the EU Cyber Resilience Act?

The Cyber Resilience Act, adopted in 2024, establishes cybersecurity requirements for products with digital elements sold in the European Union. It applies to both hardware and software, including standalone software, IoT devices, and cloud services.

The CRA is significant because:

- It covers ALL digital products sold in the EU (450 million people)

- It requires SBOMs, vulnerability management, and security updates

- Non-compliance can result in fines up to €15M or 2.5% of global revenue

- Products can be banned from the EU market entirely

Key SBOM Requirements

The CRA requires manufacturers to:

1. Maintain an SBOM for each product, documenting all software components

2. Track vulnerabilities in those components throughout the product lifecycle

3. Provide SBOMs to authorities upon request during market surveillance

4. Update components when vulnerabilities are discovered

5. Report vulnerabilities to ENISA (EU cybersecurity agency) within 24 hours

What Must Be in Your SBOM?

The CRA references both CycloneDX and SPDX formats. Your SBOM should include:

Required Fields

- Component name and version

- Supplier information

- Unique identifiers (CPE, PURL)

- Dependency relationships

- License information

- Known vulnerabilities (CVEs)

Recommended Fields

- Component description

- Hash/checksum for integrity

- Build information

- Component lifecycle status

Timeline

Year	Milestone
2024	CRA adopted by EU Parliament
2025	Member states begin transposition into national law
2025	Vulnerability reporting obligations begin
2026	Enforcement begins for high-risk products
2027	Full SBOM requirements enforced for all products

Key date: January 2027 is when all products must comply. Start preparing now.

Who Needs to Comply?

- Any company selling software in the EU market

- Hardware manufacturers with software components (IoT devices)

- Cloud service providers serving EU customers

- Open-source maintainers whose software is used in commercial EU products

- Medical device manufacturers (overlaps with FDA requirements)

How to Prepare

If you're currently using Dependabot, you'll need more for CRA compliance. Dependabot doesn't generate SBOMs — see our Dependabot alternatives comparison for tools that do.

Step 1: Generate an SBOM

The fastest way to generate an SBOM:

pip install vulnledger
vulnledger scan ./my-project

This generates a CycloneDX SBOM with every dependency and checks for known vulnerabilities.

Step 2: Set Up Continuous Monitoring

SBOMs are not one-time documents. You need to monitor for new vulnerabilities:

# Daily scan
vulnledger scan . --json --output daily-scan.json

# CI/CD gate (fails build if critical vulns found)
vulnledger scan . --ci

Step 3: Document Your Process

The CRA requires you to document:

- How you generate SBOMs

- How you monitor for vulnerabilities

- How you handle vulnerability reports

- How you update affected products

Step 4: Prepare for Audits

Keep records of:

- All SBOMs generated (with timestamps)

- All vulnerabilities found and their resolution status

- Communication with ENISA about vulnerabilities

- Product update history

Common Mistakes

1. Waiting until 2027 — Start now. Building SBOM processes takes time.

2. Generating SBOMs manually — Automate it. Manual SBOMs get outdated instantly.

3. Ignoring transitive dependencies — Your SBOM must include ALL dependencies, not just direct ones.

4. Not monitoring for new CVEs — An SBOM from January is useless if new CVEs are published in March.

5. Using the wrong format — Use CycloneDX or SPDX. Don't create your own format.

How VulnLedger Helps

VulnLedger automates CRA compliance:

1. Generate SBOMs — One command generates a CycloneDX SBOM

2. Scan for vulnerabilities — Checks against OSV.dev database

3. Continuous monitoring — Daily scans catch new CVEs

4. Compliance reports — One-click PDF reports mapped to CRA requirements

5. Team collaboration — Fork-based triage for shared vulnerability management

pip install vulnledger
vulnledger scan ./my-project --ci

Understanding the Fine Print

What Counts as a "Product with Digital Elements"?

The CRA's scope is broader than most companies realize. It covers:

- Standalone software — desktop apps, mobile apps, CLI tools

- SaaS platforms — cloud-based services serving EU users

- IoT devices — smart home, industrial sensors, medical devices

- Embedded firmware — any software running on hardware sold in the EU

- Open-source components — if your OSS is used in a commercial EU product

What Does "Manufacturer" Mean?

Under the CRA, a "manufacturer" is any entity that:

- Places a product on the EU market under their own name

- Modifies an existing product before placing it on the market

- Integrates components into a new product

This means even if you white-label or resell software, you may be considered a manufacturer.

The 24-Hour Reporting Window

One of the most demanding requirements: you must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them. This requires:

- A process for receiving vulnerability reports

- A process for triaging and confirming vulnerabilities

- A process for notifying ENISA and affected users

- A process for developing and distributing patches

Liability and Insurance

The CRA introduces product liability for software. If a vulnerability in your product causes damage, you can be held liable. This has implications for:

- Cyber insurance policies (may need to be updated)

- Terms of service (may need to be revised)

- Open-source licensing (may need liability clauses)

Industry-Specific Considerations

Cloud Service Providers (Article 12)

Cloud providers have additional obligations:

- Maintain SBOMs for all services

- Provide SBOMs to customers on request

- Report vulnerabilities within 24 hours

- Ensure regular security updates

Medical Device Software

The CRA overlaps with the EU Medical Device Regulation (MDR):

- SBOMs must satisfy both CRA and MDR requirements

- Vulnerability management must be documented for FDA and EU

- Clinical risk assessment must consider software vulnerabilities

Open-Source Maintainers

The CRA has specific provisions for open-source:

- "Stewards" (non-commercial open-source projects) have reduced obligations

- Commercial entities distributing open-source must comply fully

- Foundation-backed OSS may qualify for exemptions

Comparison with Other Frameworks

Framework	SBOM Required?	Vuln Reporting	Monitoring	Fines
EU CRA	Yes	24 hours	Continuous	€15M / 2.5% revenue
US EO 14028	Yes (federal)	N/A	Recommended	Contract loss
NIST SSDF	Yes (attestation)	N/A	Recommended	Contract loss
FDA Cyber	Yes (medical)	30 days	Required	Product rejection
PCI DSS 4.0	Component inventory	N/A	Required	$5K-$100K/month

Cost of Non-Compliance

Real-world scenarios:

- Startup selling in EU: Cannot sell product → lost market access

- IoT manufacturer: Product recall + fine up to 2.5% of global revenue

- SaaS company: Forced to remove features for EU users until compliant

- Open-source maintainer: Project used in commercial products → liability exposure

The Window Is Closing

With enforcement starting in 2026 for high-risk products and full requirements in 2027, the time to prepare is now. Companies that start building SBOM processes today will be compliant with minimal effort. Companies that wait until 2027 will face a scramble.

Conclusion

The EU CRA is not optional. Companies that don't prepare now risk losing access to the EU market. The good news: generating SBOMs is now easy and affordable. Start today, not in 2027.

Next steps:

1. Generate an SBOM for your main product

2. Set up automated scanning in your CI/CD pipeline

3. Document your vulnerability management process

4. Subscribe to VulnLedger for continuous monitoring