The EU Cyber Resilience Act (CRA) will be fully enforced by December 2027. This gives your team a 36-month window to overhaul how you handle security requirements for any product sold in the EU market.
This checklist outlines the specific steps your development and compliance teams need to take now, with clear deliverables and success criteria.
What This Checklist Covers
This checklist focuses on the core CRA compliance requirements affecting your development workflow: software component transparency, vulnerability management, incident response automation, and continuous security monitoring. If you ship software or hardware products to EU customers, these requirements apply to you.
Prerequisites
Before starting this checklist, ensure you have:
- Executive sponsorship: CRA compliance requires changes across development, security, and legal teams. You need budget authority and a cross-functional mandate.
- Current product inventory: A complete list of products sold in the EU, including version numbers and deployment models.
- Access to your build pipeline: You'll need to configure your CI/CD systems to generate and validate compliance artifacts.
CRA Compliance Checklist
1. Establish SBOM Generation for Every Build
Action: Configure your build pipeline to automatically generate Software Bills of Materials (SBOMs) in CycloneDX or SPDX format for every production release.
Requirements: SBOMs help define application boundaries and enable risk analysis—both explicit CRA requirements. Your SBOM must include direct and transitive dependencies with version numbers and license information.
What good looks like: Run sbom-tool generate (or your tool of choice) in your CI pipeline. Every artifact pushed to production includes an SBOM stored in your artifact registry. Your security team can query "show me all products using log4j 2.14.1" and get answers in under 60 seconds.
2. Map CRA Product Classifications
Action: Review your product portfolio and classify each product according to CRA categories (default cybersecurity requirements vs. critical products with enhanced requirements).
Requirements: Classification determines your compliance obligations. Critical products face stricter security requirements and third-party assessment obligations.
What good looks like: You maintain a spreadsheet or database with product name, CRA classification, and justification. Your legal team has reviewed and approved classifications. You can produce this list for auditors on demand.
3. Implement Automated Vulnerability Scanning
Action: Deploy automated scanning that checks your SBOMs against known vulnerability databases (NVD, GitHub Advisory Database, OSV) on every commit and daily for deployed products.
Requirements: CRA requires active vulnerability management throughout the product lifecycle. You must identify vulnerabilities in components and respond within defined timeframes.
What good looks like: Your CI pipeline fails builds containing critical vulnerabilities in direct dependencies. You receive daily reports of new vulnerabilities in production components. Your mean time to vulnerability awareness is under 24 hours from disclosure.
4. Create Vulnerability Disclosure and Response Procedures
Action: Establish a public vulnerability disclosure policy and internal response playbook that defines roles, timelines, and communication templates.
Requirements: CRA mandates that manufacturers handle vulnerabilities actively and report exploited vulnerabilities to ENISA (the EU cybersecurity agency) within 24 hours of awareness.
What good looks like: Your security page includes a clear vulnerability disclosure policy with a security contact email. Your internal playbook defines who gets notified when a critical vulnerability appears in your SBOM, decision criteria for patching vs. workarounds, and templates for customer notifications. You've run at least one tabletop exercise.
5. Instrument Incident Detection and Alerting
Action: Deploy monitoring that detects actively exploited vulnerabilities in your products and alerts your response team automatically.
Requirements: The 24-hour ENISA reporting requirement starts when you become aware of exploitation. Automated monitoring ensures you don't miss the clock.
What good looks like: You've integrated threat intelligence feeds that flag when vulnerabilities in your SBOM appear in CISA KEV or similar exploitation databases. Alerts route to a monitored channel with escalation if unacknowledged. You can demonstrate detection and notification within 4 hours of a vulnerability hitting KEV.
6. Establish Component Update Procedures
Action: Document and test your process for updating vulnerable components, including regression testing requirements and customer notification workflows.
Requirements: CRA requires you to address vulnerabilities throughout the product's supported lifetime, not just at initial release.
What good looks like: You maintain a dependency update policy that specifies maximum age for direct dependencies (e.g., "no direct dependencies older than 6 months"). You've successfully executed at least one emergency update in a non-production environment. Your customer notification template includes affected versions, remediation steps, and timelines.
7. Build Security Documentation Archives
Action: Create a documentation repository that captures security design decisions, threat models, and compliance evidence for each product version.
Requirements: CRA compliance assessments require demonstrating security throughout the development lifecycle. You need contemporaneous documentation, not reconstructed narratives.
What good looks like: For each major release, you store: threat model, security test results, SBOM, vulnerability scan reports, and sign-off from security review. Documentation is version-controlled and linked to release tags. You can produce a complete security package for any release shipped in the last 24 months within 2 hours.
8. Validate SBOM Accuracy
Action: Implement automated testing that verifies your SBOMs match actual deployed components. Check for phantom dependencies (listed but not present) and ghost dependencies (present but not listed).
Requirements: An inaccurate SBOM is worse than no SBOM—it gives false confidence in your vulnerability management.
What good looks like: Your CI pipeline includes SBOM validation tests. You've caught at least one discrepancy between SBOM and actual dependencies in testing. You can demonstrate SBOM accuracy above 95% (measured as: declared components that actually exist + actual components that are declared / total actual components).
9. Test Your Incident Response Workflow
Action: Run a tabletop exercise simulating a critical vulnerability disclosure in a component used across multiple products.
Requirements: Paper processes fail under pressure. Testing reveals gaps in tooling, communication, and decision-making authority.
What good looks like: Your exercise includes: SBOM query to identify affected products, severity assessment, patch vs. workaround decision, customer impact analysis, and draft notifications. You identify and document at least three process improvements. Your exercise takes under 4 hours from disclosure to draft customer communication.
10. Establish Continuous Monitoring
Action: Deploy automated daily checks that scan your production SBOMs against updated vulnerability databases and alert on new findings.
Requirements: Vulnerabilities are disclosed continuously. Waiting for your next release cycle to check for new vulnerabilities leaves gaps in your awareness.
What good looks like: You receive a daily security report for each product showing: new vulnerabilities detected in the last 24 hours, vulnerabilities by severity, and components requiring updates. Your security team reviews this report as part of daily standup. You've documented at least one instance where daily monitoring caught a vulnerability before your next scheduled scan.
Common Mistakes
Treating SBOMs as a one-time deliverable: Your SBOM is only accurate for the build that generated it. If you patch a component, you need a new SBOM. Store SBOMs with the same version control rigor as your source code.
Ignoring transitive dependencies: The vulnerability is often three layers deep in your dependency tree. Your SBOM must include the complete graph, not just direct dependencies.
Assuming your package manager's lock file is an SBOM: Lock files capture what you intended to install. SBOMs capture what actually shipped. These diverge more often than you think.
Delaying until 2026: Process changes take 6-12 months to stabilize. Starting in 2026 means you're testing your compliance workflow under audit pressure.
Next Steps
Start with items 1, 2, and 3. SBOM generation, product classification, and automated vulnerability scanning form your foundation. Everything else builds on these capabilities.
Schedule your first compliance review for 90 days from now. Assess: Are you generating SBOMs for every build? Can you identify affected products when a new vulnerability drops? Can you demonstrate your vulnerability response process?
The CRA deadline is fixed. Your compliance maturity curve is not.
EU Cyber Resilience Act
