September 11, 2026. One week from now. That's when the EU Cyber Resilience Act starts enforcing its first real obligations.
Most developers haven't heard of it. Most companies aren't ready for it. Here's what's changing and why it matters if you ship software anywhere in Europe.
What's the CRA?
The Cyber Resilience Act is the EU's first horizontal cybersecurity law for digital products. Not sector-specific. Not voluntary. Every product with digital elements sold in the EU falls under it: apps, libraries, firmware, IoT devices, SaaS, desktop software, frameworks. If it connects to a network and you sell it in Europe, it's in scope.
The only exemptions are products already covered by other EU regulations: medical devices, vehicles, aviation, marine equipment. Everything else is included.
What Happens on September 11
Two mandatory reporting obligations kick in:
1. Actively exploited vulnerabilities: If you discover a vulnerability in your product that's being actively exploited, you must report it. Not eventually. Not when you have a fix. Immediately.
2. Severe security incidents: Any incident that impacts the security of your product's users must be reported.
The timeline is tight:
- 24 hours: Early warning notification to ENISA (EU cybersecurity agency)
- 72 hours: Full incident notification with details
- 14 days: Final report after a fix is available (for vulnerabilities)
- 1 month: Final report for severe incidents
Miss these windows and you're in breach of EU law.
Why Most Companies Aren't Ready
The September deadline catches companies off guard because the full CRA requirements don't apply until December 2027. Most legal teams looked at that date and told engineering "we have time."
They missed the fine print. The reporting obligations apply to every product already on the market, not just products shipped after September 11. If you have software deployed in the EU today and you discover an exploited vulnerability next month, you're legally required to report it within 24 hours.
That means you need, right now:
- A process to detect actively exploited vulnerabilities in your products
- A triage workflow to determine if something meets the reporting threshold
- A designated person who can submit to ENISA's Single Reporting Platform
- Internal coordination between security, legal, and product teams
- Documentation of every decision (regulators can ask for this)
Most startups and mid-size companies have exactly none of this in place.
What's Coming in December 2027
September 2026 is the appetizer. The full CRA requirements in December 2027 are the main course:
Annex I Part I (product requirements):
- Products must be designed with security by default
- No known exploitable vulnerabilities at time of release
- Secure configuration out of the box
- Protection against unauthorized access
- Data confidentiality and integrity
- Minimal attack surface
- Incident logging and monitoring
- Security updates for the entire support period
Annex I Part II (process requirements):
- Vulnerability handling process (intake, triage, fix, disclosure)
- SBOM (Software Bill of Materials) for every product
- 10 years of technical documentation retention
- CE marking (yes, like on your toaster)
Conformity assessment:
- Most products: self-assessment
- "Important products" (password managers, VPNs, identity systems): third-party audit
- "Critical products" (industrial controllers, certain infrastructure): mandatory EU certification
The Open Source Question
This is where it gets interesting. The CRA has a carve-out for open source, but it's narrower than people think.
Exempt: Open source developed and distributed without commercial intent. Pure hobby projects, community-maintained libraries where nobody's making money.
NOT exempt: Open source with commercial involvement. If your company maintains an open source library and offers paid support, consulting, or a commercial version, the CRA treats you as a manufacturer. Same obligations. Same reporting. Same conformity assessment.
This means companies like Elastic, MongoDB, HashiCorp, and anyone running an open-core model are fully in scope. And so is any company that ships commercial software containing open source dependencies, since they're the "manufacturer" of the combined product.
What Developers Should Actually Do
Before September 11, 2026 (next week)
- Figure out if you sell to EU customers. If yes, CRA applies to you regardless of where you're based.
- Set up a vulnerability intake process. You need a way for people to report vulnerabilities and a way to triage them.
- Register with ENISA's reporting platform. You'll need access when (not if) you have to file.
- Document your incident response process. Regulators will want to see it exists.
Before December 2027
- Start your SBOM. Tools like Syft, CycloneDX, or SPDX can generate these from your dependency files.
- Audit your security defaults. No default passwords, no unnecessary open ports, no optional security features that should be on by default.
- Review your update mechanism. The CRA requires that security updates are delivered automatically or with clear user notification.
- Assess your conformity route. Most products self-assess. Check Annex III and IV to see if you're in a higher category.
If you maintain open source
- Check if commercial activity brings you in scope. Sponsorships, paid support, consulting, dual licensing all count.
- Consider adding a security policy. SECURITY.md with a disclosure process covers the basics.
- Know your downstream. If commercial products embed your library, their compliance may depend on your vulnerability handling.
The Bigger Picture
The CRA is the EU doing what GDPR did for privacy, but for product security. It's setting a floor that every digital product must meet. The 24-hour reporting window is modeled on GDPR's 72-hour breach notification, but tighter.
For developers, the practical impact is:
- Security isn't optional anymore. It's a legal requirement with specific deliverables.
- SBOMs are coming whether you like them or not. The CRA mandates them.
- Vulnerability handling needs a process. "We'll fix it when we get to it" doesn't meet a 24-hour reporting window.
- Documentation matters. 10-year retention means your threat models, security decisions, and risk assessments need to be written down.
The companies that started preparing in 2025 are in decent shape. The companies starting now have a week to get their reporting pipeline operational and 15 months to overhaul their development practices.
The companies that haven't started yet are about to have a very interesting autumn.
Sources:
Top comments (0)