EU Cyber Resilience Act: What Software Companies Need to Know for 2026

The EU Cyber Resilience Act Is Real and It Applies to You

If you sell software to anyone in the EU, the Cyber Resilience Act (CRA) applies to you. Not next year. Not when you get around to it. Now.

The CRA is the EU's most ambitious cybersecurity regulation to date. It covers all products with digital elements — which means basically all software. And unlike GDPR, which had a grace period before enforcement, the CRA's requirements are specific, technical, and verifiable.

Here's what US software companies need to know, what to do, and when.

---

CRA Requirements at a Glance

What's Required

1. SBOMs — Software Bill of Materials for every product
2. Vulnerability disclosure — Documented process for receiving, triaging, and disclosing vulnerabilities
3. Security by design — Documented security practices throughout development
4. Incident reporting — 24-hour notification for actively exploited vulnerabilities, 72-hour notification for other incidents
5. Provenance tracking — Ability to trace software components back to their source
6. 5-year support — Security updates for at least 5 years after sale

Who's Covered

Any product with digital elements sold in the EU. This includes:

• SaaS applications
• Mobile apps
• IoT devices with firmware
• Open-source software distributed in the EU
• Components and libraries used in covered products

Who's Exempt

• Open-source software developed outside a commercial context
• Software already covered by sector-specific regulations (aviation, automotive, medical devices)

---

The Compliance Timeline

| Date | Requirement | |------|-------------| | Mid-2026 | Incident reporting obligations begin | | Late 2027 | All obligations apply (SBOMs, security by design, vulnerability disclosure) | | Late 2029 | Full enforcement, penalties in effect |

Key point: The mid-2026 date is for reporting — you need to be able to report incidents before you can comply. This means your vulnerability disclosure process needs to exist by mid-2026.

---

What US Companies Need to Do Now

1. Generate SBOMs for Every Product

This is non-negotiable. Every product you sell in the EU needs an SBOM.

Tooling options:

• syft (by Anchore) — Open source, works with most package managers
• trivy — Open source, generates SBOMs and scans for vulnerabilities
• Commercial tools — Snyk, FOSSA, WhiteSource all generate SBOMs as part of their scanning

Our recommendation: Start with syft or trivy for generation, then integrate into your CI/CD pipeline so SBOMs are generated automatically at every build.

2. Establish a Vulnerability Disclosure Process

You need:

• A way for researchers to report vulnerabilities (security@, HackerOne, or Bugcrowd)
• A documented triage process (how you assess severity and priority)
• A disclosure policy (when and how you disclose vulnerabilities publicly)
• A coordination process for reporting to EU authorities

Timeline: This needs to exist by mid-2026. Start now.

3. Document Your Security Practices

The CRA requires "security by design" documentation. This means:

• Threat modeling for each product
• Secure development lifecycle documentation
• Code review and testing practices
• Dependency management policies
• Incident response procedures

If you're already doing these things, you just need to document them. If you're not, you have bigger problems than compliance.

4. Implement Provenance Tracking

The CRA doesn't explicitly mandate provenance tracking, but it requires the ability to trace software components back to their source. This is provenance tracking.

What this means in practice:

• Every build artifact should have a provenance record showing: what source code it was built from, who built it, in what environment, and with what dependencies
• Provenance records should be cryptographically verifiable
• You should be able to answer "where did this component come from?" for any component in any product

ProvenanceOS handles this automatically — generating SLSA-compliant provenance records at build time and maintaining a searchable provenance log for every artifact.

5. Plan for 5-Year Support

The CRA requires security updates for 5 years. If you're a SaaS company, this probably means maintaining older versions longer than you currently do.

For companies with rapid release cycles, this means:

• Document which versions are supported
• Maintain a security patching process for supported versions
• Communicate end-of-support dates clearly to customers

---

The Penalty Math

Let's talk about what non-compliance costs:

• Maximum penalty: €15M or 2.5% of global annual turnover, whichever is higher
• Market exclusion: Non-compliant products can be removed from the EU market
• Reputational damage: Public enforcement actions are visible to customers and competitors

For a $10M/year SaaS company selling in the EU: the maximum penalty is €250K. For a $100M/year company: €2.5M. And that's before you factor in market exclusion.

The cost of compliance is always less than the cost of non-compliance.

---

Common Mistakes

Mistake 1: "We're a US company, this doesn't apply to us." Wrong. If you sell to EU customers, it applies. There's no territorial exemption.

Mistake 2: "We'll deal with this when enforcement starts." The compliance window closes fast. Demand for CRA assessors will exceed supply. Companies that start now will be fine. Companies that wait will be scrambling.

Mistake 3: "Our SaaS doesn't count as a 'product with digital elements.'" It does. The CRA explicitly includes SaaS, cloud services, and web applications.

Mistake 4: "We'll just generate an SBOM and call it done." SBOMs are necessary but not sufficient. You also need vulnerability disclosure processes, security documentation, provenance tracking, and 5-year support commitments.

---

Resources

• ProvenanceOS — Automated provenance tracking for software supply chains. SLSA-compliant provenance records at build time.
• EU CRA Official Text — Full regulation on EUR-Lex
• ENISA CRA Guidance — The EU's cybersecurity agency publishes implementation guidance
• SLSA Framework — Supply-chain Levels for Software Artifacts — the standard for provenance verification
• CycloneDX — Open standard for SBOMs

---

The Bottom Line

The EU CRA is the most significant cybersecurity regulation for software companies since GDPR. It requires SBOMs, vulnerability disclosure, security documentation, provenance tracking, and long-term support commitments.

If you sell software in the EU, you need to be preparing now. Not because enforcement is imminent, but because compliance takes time, demand for assessors will spike, and the cost of non-compliance is too high to risk.

Start with SBOMs. Document your security practices. Implement provenance tracking. And if you want to automate the hardest parts, ProvenanceOS handles provenance records, traceability, and SLSA compliance out of the box.