If your organization manufactures or distributes hardware or software products in Europe, you have 24 months to align with a regulatory shift that will fundamentally change how you design, document, and maintain your offerings. The EU Cyber Resilience Act is here, and the European Telecommunications Standards Institute (ETSI) has published 17 draft standards defining what compliance means.
This is not theoretical. ETSI's proposed standards, currently under public inquiry through mid-November 2026, will become the compliance baseline for operating systems, routers, firewalls, VPNs, browsers, password managers, smart home devices, wearables, and nine other product categories. If your organization sells any of these in the EU, you're in scope.
What This Checklist Covers
This checklist helps you assess your current product security posture against the core requirements emerging from ETSI's proposed standards. It's designed for security leaders advising product teams, compliance officers mapping regulatory gaps, and vCISOs guiding clients through European market access decisions. Each item reflects mandates that appear across multiple ETSI draft standards, emphasizing cryptography, secure defaults, software transparency, and lifecycle management.
Prerequisites
Before starting this assessment, confirm:
- Product jurisdiction clarity. Know which of your products will be sold, distributed, or serviced in the EU after December 2027.
- Access to product architecture documentation. Review cryptographic implementations, default configurations, and update mechanisms.
- Cross-functional team availability. This checklist requires input from engineering, product management, legal, and supply chain.
- Understanding of your role in the supply chain. The CRA applies differently to manufacturers, importers, distributors, and service providers. Know your category for each product.
CRA Readiness Checklist
1. Modern Cryptography Implementation
Requirement: Products must implement current cryptographic standards for data protection, authentication, and integrity.
☐ Your products use cryptographic algorithms that align with current NIST, ENISA, or equivalent recommendations (not deprecated or legacy algorithms like SHA-1 or DES).
☐ You have a documented process for cryptographic agility, enabling updates or replacements without full product redesign.
Good looks like: A cryptography inventory showing which algorithms protect data at rest and in transit, with version control and a defined deprecation timeline tied to NIST SP 800-131A or equivalent.
2. Secure-by-Default Configuration
Requirement: Products must ship with security features enabled and insecure features disabled out of the box.
☐ Default credentials are unique per device or eliminated entirely (no "admin/admin" scenarios).
☐ Unnecessary services, ports, and protocols are disabled in the default configuration.
☐ Security features (encryption, authentication, logging) are enabled by default and require deliberate action to disable.
Good looks like: A configuration baseline document showing that hardening is the default state, not an optional post-deployment step. Your installation guide should explain how to relax security controls, not how to enable them.
3. Software Bill of Materials (SBOM) Generation
Requirement: You must provide a machine-readable inventory of software components, dependencies, and versions.
☐ You generate an SBOM for each product release in a standardized format (SPDX or CycloneDX).
☐ The SBOM includes direct and transitive dependencies with version numbers and license information.
☐ You have a process to update and redistribute SBOMs when components change due to patches or updates.
Good looks like: An automated CI/CD pipeline step that generates and validates SBOMs, with a customer-facing portal where buyers can download current SBOMs for their deployed product versions. Your SBOM should answer "Do I have Log4j 2.14.1 in my environment?" in under five minutes.
4. Vulnerability Disclosure and Response Process
Requirement: You must maintain a documented process for receiving, triaging, and responding to vulnerability reports.
☐ You have a public security contact ([email protected] or equivalent) listed on your website.
☐ You have defined SLAs for acknowledging reports (typically 72 hours) and issuing fixes based on severity.
☐ Your process includes coordination with affected customers and, where applicable, public disclosure timelines.
Good looks like: A security.txt file deployed at /.well-known/security.txt following RFC 9116, backed by an internal vulnerability management workflow in your GRC platform with defined escalation paths.
5. Post-Sale Update Capability
Requirement: Products must support security updates throughout their supported lifecycle.
☐ Your products can receive and apply security patches without requiring physical access or full reinstallation.
☐ Updates are delivered over authenticated, encrypted channels.
☐ You have defined and communicated a support lifecycle (when updates will be provided and when they will cease).
Good looks like: An automated update mechanism with rollback capability, cryptographic signature verification for update packages, and a published end-of-life policy that gives customers at least 12 months' notice before support termination.
6. Supply Chain Transparency
Requirement: You must know and document your software supply chain, including third-party components.
☐ You maintain an inventory of all third-party libraries, SDKs, and frameworks used in your products.
☐ You have a process to monitor these components for disclosed vulnerabilities (CVEs).
☐ You can trace which products are affected when a component vulnerability is announced.
Good looks like: Integration with a software composition analysis tool that maps CVEs to affected products within 24 hours of disclosure, with automated alerts to product teams and documented remediation workflows.
7. Documentation of Security Properties
Requirement: You must provide documentation describing the security features, configurations, and operational requirements of your products.
☐ Product documentation includes a security section describing authentication mechanisms, encryption methods, and logging capabilities.
☐ You document known limitations, constraints, or environmental requirements for security features to function correctly.
☐ Documentation is maintained and versioned alongside product releases.
Good looks like: A dedicated security guide for each product that a customer's security team can use during procurement evaluation, clearly stating what the product does and doesn't protect against.
Common Mistakes
Treating this as a one-time compliance exercise. The CRA isn't a checklist you complete in Q4 2027. It requires ongoing processes for vulnerability management, SBOM maintenance, and update distribution. Build continuous compliance into your product development lifecycle now.
Assuming existing security certifications cover CRA requirements. ISO 27001 certification or SOC 2 compliance doesn't automatically satisfy ETSI's product-specific standards. You need product-level technical controls, not just organizational processes.
Delegating entirely to engineering. CRA compliance requires legal interpretation (are you a manufacturer or distributor?), supply chain coordination (who owns component vulnerabilities?), and commercial decisions (what's your support lifecycle?). This is a cross-functional program, not a technical project.
Ignoring the SBOM requirement until late 2027. Generating accurate SBOMs for complex products with hundreds of dependencies takes tooling, process changes, and validation time. Start building your SBOM capability in 2025, not 2027.
Underestimating the scope of "products with digital elements." If it connects to a network or processes data, it's likely in scope. That includes firmware in hardware products, not just standalone software.
Next Steps
The ETSI standards are under public inquiry through mid-November 2026. Final versions are expected by December 2026, giving you 12 months to implement before the CRA takes full effect. Here's your timeline:
Q2 2025: Complete this checklist for your product portfolio. Identify gaps and prioritize based on product revenue and market criticality.
Q3 2025: Establish SBOM generation capability and begin building component inventories. This is your longest-lead item.
Q4 2025: Implement secure-by-default configurations for products currently in development. Retrofit existing products where feasible.
Q1-Q2 2026: Review final ETSI standards when published and validate your implementations against the approved requirements.
Q3-Q4 2026: Conduct internal compliance audits and address any remaining gaps before the December 2027 enforcement date.
If you're a vCISO advising clients with European market exposure, this checklist should inform your 2025 roadmap discussions now. Organizations that treat CRA compliance as a product quality initiative, not a last-minute regulatory burden, will have a significant competitive advantage when the deadline arrives.
