The EU's Cyber Resilience Act (CRA) introduces a new compliance requirement: software and network-connected products now need the same CE marking as electronics and machinery. By December 2027, if you sell digital products in the EU, you must determine whether your products meet these requirements.
This isn't about certifying your security program; it's about proving each product meets safety requirements throughout its lifecycle.
The Decision You Are Facing
Your team must decide if your products fall under the CRA scope and, if so, which compliance path applies. This decision impacts your development pipeline, support commitments, and vulnerability management processes long after each release.
Non-compliance means you cannot sell your products in the EU. The CRA treats insecure software like unsafe machinery—products that don't meet requirements cannot be legally sold.
Key Factors That Affect Your Choice
Product classification drives everything. The CRA distinguishes between three categories:
- Standard products: Most commercial software and IoT devices
- Important products: Infrastructure components, identity management systems, network equipment
- Critical products: Operating systems, industrial control systems, smart card operating systems
Your support horizon matters. The CRA mandates a minimum of five years of free security updates for most products. If your current support model offers 12-month update windows, you need to fundamentally change your business model.
Component visibility becomes mandatory. You must know every dependency in your product. If you cannot produce a complete software bill of materials (SBOM) for each release, you cannot demonstrate compliance. Currently, only a quarter of organizations generate SBOMs automatically, indicating most teams need infrastructure changes.
Vulnerability reporting timelines are strict. ENISA manages the reporting system. When you discover an actively exploited vulnerability, you have 24 hours to report. For other vulnerabilities, you have 14 days. These are legal requirements with enforcement mechanisms.
Path A: Full CRA Compliance (You Sell Products in the EU)
Choose this path if:
- You develop software products sold to EU customers
- You manufacture or distribute IoT devices, network equipment, or embedded systems
- You provide SaaS platforms that include downloadable components
- Your open source project has been integrated into a commercial product you maintain
What this requires:
Establish vulnerability reporting processes by September 11. This involves:
- Direct integration with ENISA's reporting system
- Internal triage workflows to meet 24-hour and 14-day deadlines
- Documentation showing how you track vulnerabilities in third-party components
Implement SBOM generation in your CI/CD pipeline. Manual SBOM creation doesn't scale when tracking changes across every build. Your automation must:
- Capture all direct and transitive dependencies
- Link each component to known vulnerabilities (CVE associations)
- Update automatically when dependencies change
- Generate machine-readable formats (SPDX or CycloneDX)
Extend your support commitments. If you currently offer two years of security updates, budget for five. This affects:
- Support team capacity planning
- Infrastructure costs for maintaining old build environments
- Testing requirements for backporting security fixes
Document your secure development practices. The CRA requires evidence that security is built into your product design. You need written processes for:
- Threat modeling during the design phase
- Security testing before release
- Incident response procedures
- Third-party component evaluation
Path B: Indirect CRA Impact (You Depend on Covered Products)
Choose this path if:
- You build internal applications using commercial frameworks or platforms
- You consume open source components that may fall under CRA scope
- You integrate third-party APIs or services in your products
- You operate in a regulated industry with EU customers
What this requires:
You don't need CE marking, but you inherit supply chain obligations. Your vendors must demonstrate CRA compliance, and you must verify it.
Build vendor assessment criteria that ask:
- Do you provide SBOMs for your products?
- What is your vulnerability disclosure timeline?
- How long do you commit to security updates?
- Are you registered as a CRA-covered manufacturer?
For open source dependencies, monitor project governance. The CRA distinguishes between open source developed in the open (generally exempt) and open source components integrated into commercial products (covered). If a critical library in your stack becomes unmaintained, plan a migration before the CRA deadline.
Update your procurement contracts. Standard software licenses often disclaim security warranties. Under CRA, manufacturers cannot disclaim responsibility for security vulnerabilities. Your contracts should specify:
- Minimum support duration
- Vulnerability notification procedures
- SBOM delivery format and frequency
Path C: Strategic Exemption Planning (You May Qualify for Exclusions)
Choose this path if:
- You develop software exclusively for internal use
- You provide consulting or bespoke development services
- You maintain open source projects without commercial integration
- You operate in sectors with existing cybersecurity regulations (finance, healthcare, energy)
What this requires:
Document your exemption basis clearly. The CRA includes carve-outs, but you must demonstrate why you qualify. Keep records showing:
- Your product is not placed on the EU market
- Your development is not connected to commercial distribution
- Your sector already complies with equivalent security requirements
Even if exempt, monitor the regulatory landscape. Member states may interpret CRA scope differently during the 2027 implementation phase. If you expand into new markets or change your business model, your exemption status may change.
Summary Matrix
| Factor | Path A: Full Compliance | Path B: Indirect Impact | Path C: Exemption |
|---|---|---|---|
| Trigger | Sell products in EU | Use covered components | Internal use only |
| SBOM requirement | Must generate automatically | Must receive from vendors | Optional (recommended) |
| Vulnerability reporting | 24h/14d to ENISA | Receive from vendors | None |
| Support commitment | 5+ years mandatory | Depends on vendor | None |
| Timeline pressure | Sept 11 (reporting), Dec 2027 (full) | Vendor-dependent | Monitor for changes |
| Primary risk | Market access blocked | Supply chain disruption | Exemption reclassification |
The CRA shifts security from a process you certify to a product attribute you demonstrate. Your path depends on where your products sit in the supply chain, but all three paths require decisions now—not in 2027 when enforcement begins.
