The EU Cyber Resilience Act came into force in December 2024. By September 11, 2026, your team must report actively exploited vulnerabilities within 24 hours of awareness. That's right, just 24 hours.
The challenge isn't just compliance. It's structuring your response to meet that deadline without putting your team in constant crisis mode.
The Decision You're Facing
You have three reporting architectures to choose from, each with different resource needs and risk profiles:
- Manual triage with centralized tracking: Your security team uses spreadsheets to manually cross-reference CVEs against known deployments.
- SBOM-driven automation with human verification: You generate software bills of materials (SBOMs) for released products and use tools to flag affected components.
- Continuous monitoring with automated assessment: Your supply chain is instrumented to detect, assess, and prepare reports automatically.
Your choice depends on product release cadence, dependency complexity, team size, and acceptable response latency.
Key Factors That Affect Your Choice
Release cadence: If you ship quarterly, manual processes might work. If you deploy daily, they won't. The CRA applies to every released product with digital components, regardless of update size.
Dependency depth: Count your transitive dependencies. If a release includes 50 direct dependencies, you're likely managing over 300 components. Manual tracking fails around 100 total dependencies.
Team capacity: How many people can you dedicate to vulnerability correlation during an active exploitation event? If it's "one person for a few hours," you need automation.
Current SBOM maturity: Do you generate SBOMs today? Are they accurate? Can you map them to released product versions? If you're starting from scratch, plan for 6-12 months to build reliable SBOM generation.
Path A: Manual Triage with Centralized Tracking
Choose this if:
- You release fewer than four products per year.
- Your dependency tree stays under 100 components.
- You have dedicated security engineers who can respond within business hours.
- Your products don't include embedded systems or IoT components.
What you'll need: A version-controlled spreadsheet or lightweight database mapping product versions to component versions. When ENISA or the European Commission publishes an exploited vulnerability, you manually check if any released product contains the affected version.
Timeline to implement: 2-3 months to build the tracking system and train your team.
Risk: You'll miss dependencies you didn't know about. Manual correlation introduces human error. If an exploit drops on Friday evening, you're starting the 24-hour clock with no automated safety net.
Specific requirement: The CRA requires reporting within 24 hours of becoming aware of active exploitation. "Awareness" starts when you should reasonably know, not when you finish investigating. Manual processes compress your response window.
Path B: SBOM-Driven Automation with Human Verification
Choose this if:
- You release monthly or more frequently.
- Your dependency count exceeds 100 components.
- You already generate SBOMs or can implement generation within 6 months.
- You need to scale reporting without proportionally scaling headcount.
What you'll need: SBOM generation integrated into your build pipeline (CycloneDX or SPDX format), a vulnerability database tracking active exploitation status, and tools that correlate CVEs against your SBOM repository. Your security team reviews flagged matches and submits reports.
Timeline to implement: 6-9 months if starting SBOM generation from scratch; 3-4 months if you already have accurate SBOMs.
Risk: SBOM accuracy is your single point of failure. If your build process omits dependencies or records incorrect versions, you'll file incomplete reports. You'll also need a process to update historical SBOMs when you discover gaps.
Specific requirement: The CRA expects manufacturers to identify affected products "without undue delay." If you have SBOMs but don't use them for correlation, regulators may view that as negligence.
Path C: Continuous Monitoring with Automated Assessment
Choose this if:
- You deploy continuously or have complex product portfolios.
- Your products include third-party components you don't control.
- You need to meet the 24-hour deadline across time zones and weekends.
- You're already investing in supply chain security tooling.
What you'll need: Everything from Path B, plus continuous monitoring of exploitation feeds, automated severity assessment based on your deployment context, and pre-drafted report templates that populate automatically. Your team reviews and approves rather than drafts from scratch.
Timeline to implement: 12-18 months for full automation, but you can phase it in by starting with SBOM generation and adding monitoring layers incrementally.
Risk: Over-automation creates alert fatigue. You'll need tuning to distinguish between "CVE published" and "CVE actively exploited in a way that affects our products." False positives waste the goodwill you've built with ENISA.
Specific requirement: The CRA distinguishes between "actively exploited vulnerabilities" and "severe incidents." Your automation needs to categorize correctly, as the reporting templates differ.
Summary Matrix
| Factor | Path A: Manual | Path B: SBOM + Automation | Path C: Continuous |
|---|---|---|---|
| Best for release cadence | Quarterly or less | Monthly to weekly | Daily or continuous |
| Dependency threshold | <100 components | 100-500 components | 500+ or complex supply chain |
| Team size needed | 1-2 security engineers | 2-4 engineers + tooling | 4+ engineers + dedicated tooling budget |
| Time to implement | 2-3 months | 6-9 months | 12-18 months |
| Response window reliability | Business hours only | Extended hours with on-call | 24/7 automated detection |
| SBOM requirement | Optional tracking | Must be accurate and current | Must be real-time |
| Cost (annual) | $20K-50K (mostly labor) | $100K-200K (tooling + labor) | $300K+ (platform + integration) |
What Happens If You Choose Wrong
If you pick Path A but need Path B, you'll discover the gap during your first real incident. You'll miss the 24-hour deadline, file an incomplete report, and spend the next quarter explaining to regulators why your process failed.
If you over-engineer with Path C when Path B would suffice, you'll burn budget and engineer time on automation that doesn't materially reduce your risk. Your team will spend more time tuning the system than they would have on manual verification.
Start by measuring your current state: How many dependencies do you have? How quickly can you correlate a CVE to affected products today? If that exercise takes more than 4 hours, you need at least Path B before September 2026.
The CRA reporting deadline isn't the finish line. It's the starting gun for ongoing operational compliance. Choose the path that you can sustain, not just the one that gets you across the deadline.
