The Conformité Européenne (CE, or European conformity) mark has always signaled that a product meets EU safety standards. Starting in 2027, it will also certify something new: that your connected product was built with cryptographic security from the ground up. The Cyber Resilience Act (CRA) is making secure-by-design cybersecurity a legal requirement for any hardware or software product with a digital element sold in the European Union.
For digital products (and everyone around them) this changes everything. After the starting date, products shipped without a unique device identity, signed firmware updates, or encryption enabled by default will no longer qualify for the CE mark. No CE mark means no access to the EU market.
This guide breaks down what the CRA requires, who it applies to, the penalties for non-compliance, and the practical steps you can take now to get audit-ready before the December 2027 deadline.
What the Cyber Resilience Act actually requires
The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the EU’s first horizontal law mandating secure-by-design cybersecurity for products that contain a digital element. It applies to any product with digital elements places in the EU market: hardware, software, and any remote data processing solution that is part of the product’s function . The regulation ties compliance directly to CE marking.
The CRA splits obligations into two categories. Annex I, Part I covers product security design requirements, specifying how products must be built. Annex I, Part II covers lifecycle vulnerability handling requirements, defining how suppliers must support products after sale.
Unlike previous frameworks that relied on vague language about “appropriate security measures,” the CRA gets specific. Digital products must ship with cryptographic protection for data confidentiality and integrity enabled by default, cryptographically verified software and firmware updates, and a secure identity and authentication mechanism. These requirements must be justified by a product-specific cybersecurity risk assessment rather than a fixed checklist.
The three cryptographic must-haves
The CRA addresses cryptography through several essential requirements in Annex I. Three areas demand immediate attention from product security teams.
Encrypted data at rest and in transit. Products must protect relevant data using state-of-the-art encryption mechanisms. This applies to both stored data and data transmitted between devices. The PKI that issues device and session certificates forms the backbone of this requirement.
Signed firmware and software updates. Security updates must be cryptographically signed and disseminated without delay, free of charge, throughout the mandatory support period. Verification must happen before installation. Automatic updates should be enabled by default.
Secure device identity. Products must ship with secure default configuration and identity-based access control. In practical terms, this means a unique cryptographic identity provisioned at the point of manufacture, not shared or default credentials.
These three capabilities are interdependent. Without a strong device identity, you cannot establish authenticated and secure channels. Without signed updates, you cannot patch vulnerabilities without introducing new ones. Without encryption, data confidentiality fails at the first interception.
Who is in scope and what it costs to ignore
The CRA casts a wide net. It applies to essentially any connected product or software sold in the EU, regardless of where it is originated. Most products fall into the default category with standard obligations. Important products (in Annex I, Class I and II) and Critical products face stricter conformity assessment requirements. These categories include identity management systems, VPN software, and smart meter gateways. Above that, Annex IV critical products such as smart meter gateways, smartcards and secure elements, hardware devices with security boxes, can be made subject to mandatory European cybersecurity certification by delegated actThe regulation binds almost any player in the supply chain, starting with manufacturers. Importers must verify manufacturer compliance before making a product available on the EU market. Distributors share similar verification obligations. Open-source stewards who commercially distribute software with digital elements may also fall under certain conditions defined in the regulation.
Penalties are significant. Non-compliance can trigger fines of up to ~15 million or 2.5% of global annual revenue, whichever is higher. Beyond financial penalties, non-compliant products lose the CE mark required for EU market access. This transforms the CRA from a security regulation into a market-access requirement.
The deadlines that matter: 2027 and the shorter 2026 clock
The CRA timeline leaves less runway than it appears. Essential requirements must be fully applied by December 11, 2027. However, vulnerability and active-exploitation reporting obligations start earlier, in September 2026.
Thirty-six months sounded like a comfortable window, but that time is disappearing fast for those in need to overhaul their products. Redesigning products that were never built with a unique device identity requires hardware changes, manufacturing line updates, and supply chain coordination. Implementing a signing pipeline for firmware updates means establishing PKI infrastructure, key management procedures, and secure distribution channels. Building a cryptographic inventory for every embedded library and algorithm across product lines takes systematic discovery and ongoing maintenance.
Organizations that waited until 2026 to start are finding themselves looking for solutions. The complexity compounds when you consider that industrial products, automotive systems, and connected devices often have development cycles measured in years, not months. It is not late, but the clock is ticking.
Mapping CRA requirements to cryptographic controls
The CRA addresses cryptography across six control areas with direct implementation implications.
| Control Area | CRA Reference | Implementation Approach |
| Confidentiality of data at rest and in transit | Annex I, Part I, §2(e) | Encrypt relevant data using state-of-the-art mechanisms, backed by PKI that issues device and session certificates |
| Integrity of data, commands, and configuration | Annex I, Part I, §2(f) | Protect commands, programs, and configuration from unauthorized manipulation through signed configuration and authenticated channels |
| Secure by default configuration and identity | Annex I, Part I, §2(b) and §2(d) | Ship products with secure default configuration and a unique device identity provisioned at manufacture |
| Secure update mechanism | Annex I, Part I, §2(c); Annex I, Part II, §7 | Cryptographically sign security updates and disseminate them without delay throughout the support period |
| Cryptographic component visibility | Implicit under risk assessment; anticipated in Annex K | Identify and track embedded cryptographic libraries and algorithms across the product and its dependencies |
| Secure data deletion | Annex I, Part I, §2(m) | Enable secure and permanent deletion of data and settings, including cryptographic key destruction |
Each control area requires both technical implementation and documentation. Conformity assessments will probe whether your cryptographic design choices are documented, justified by risk, and demonstrably implemented. For the Cyber Resilience Act, intention alone is not sufficient.
Getting audit ready before a notified body asks
CRA conformity assessments focus on evidence of implemented controls, not policy documentation alone. Whether your products undergo self-declared conformity assessment or review by a notified body, assessors will probe specific areas. Taking action on the following questions will help you be prepared ahead of time.
- Cryptographic component inventory. Does the organization maintain an inventory of every cryptographic library and algorithm embedded in the product, including inherited dependencies? If you cannot produce this inventory, you cannot tell a regulator what is actually exposed when the next vulnerability hits.
- Risk assessment documentation. Has the organization performed and documented a product-specific cybersecurity risk assessment justifying its cryptographic design choices? Generic security policies will not suffice.
- Device identity provisioning. Is a unique cryptographic identity provisioned to each device during manufacturing? Shared or default credentials fail this requirement.
- Signed update pipeline. Can the organization demonstrate that firmware and software updates are cryptographically signed and verified before installation? Automatic updates should be enabled by default.
- Secure erase and key destruction. Does the product support secure data deletion, including cryptographic key destruction, for ownership transfer or decommissioning?
- Support period commitments. Is the mandatory security-update support period documented and communicated to users? The minimum is five years or the product’s expected lifetime if shorter.
How Keyfactor can help
Keyfactor provides the PKI and certificate lifecycle management infrastructure that manufacturers need to meet CRA cryptographic requirements. The platform addresses each of the six control areas with purpose-built capabilities.
AgileSec discovers and inventories cryptographic assets across products and dependencies, giving suppliers the visibility to assess exposure and plan remediation.
EJBCA provides the enterprise-grade PKI that issues device certificates, authenticates secure channels, and supports cryptographic key destruction for secure data deletion.
Keyfactor Command delivers centralized visibility and automation for certificate lifecycles across devices and products. It enforces cryptography policies, tracks certificate expiry, and provides the audit trail assessors require.
SignServer and Signum enable code signing for firmware and software updates, ensuring every update is cryptographically verified before deployment.
These tools work together to automate the cryptographic controls that the CRA mandates, while producing the documentation and audit evidence that conformity assessments demand.
Taking action before time runs out
The CRA represents a fundamental shift in how the EU regulates connected digital products. Cybersecurity is no longer a best practice or a competitive differentiator. It is a market-access requirement enforced through CE marking.
The organizations best positioned for December 2027 are those building cryptographic governance infrastructure today. Start with visibility: inventory the cryptographic assets, libraries, and algorithms embedded in your products. Assess those assets against CRA requirements. Establish automation to manage certificate and key lifecycles before gaps become incidents.
Waiting is the riskiest strategy. Products in development now will ship into a CRA-regulated market. The cryptographic choices you make today will determine whether those products earn the CE mark or lose access to 450 million consumers.
Got Cyber Resilience Act questions? We’ve got answers.
What is the Cyber Resilience Act?
The CRA (Regulation EU 2024/2847) is the EU’s first horizontal law requiring secure-by-design cybersecurity for any product with a digital element sold in the EU market. It ties compliance to CE marking, making cybersecurity a market-access requirement.
When does the Cyber Resilience Act take effect?
Essential requirements must be fully applied by December 11, 2027. Vulnerability and active-exploitation reporting obligations begin earlier, in September 2026.
Who does the CRA apply to?
The CRA applies to every product with digital elements in the EU market, regardless of the specific origin. This includes hardware, software, and any remote data processing solution that is essential to the functioning of the product. .
What are the penalties for CRA non-compliance?
Non-compliance can result in fines of up to ‚~15 million or 2.5% of global annual revenue, whichever is higher. Non-compliant products lose the CE mark required for EU market access.
What cryptographic requirements does the CRA mandate?
Products must ship with encrypted data protection enabled by default, cryptographically signed and verified firmware updates, and a unique device identity provisioned at manufacture.
Do I need a cryptographic inventory for CRA compliance?
Yes. Conformity assessments require suppliers to maintain an inventory of every cryptographic library and algorithm embedded in the product, including dependencies. This inventory is essential for assessing exposure when vulnerabilities are discovered.
How does the CRA affect existing products?
Products placed on the EU market after December 2027 must comply with CRA requirements. Products already on the market may need updates to meet vulnerability handling and support period obligations.
What is the first step toward CRA compliance?
Start with visibility. Inventory the cryptographic assets deployed across your products, assess them against CRA requirements, and establish automation for certificate and key lifecycle management before gaps become compliance failures.
