La loi sur la cyber-résilience expliquée : ce qu'il faut faire avant l'échéance de 2027
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.
Ce qu'exige réellement la loi sur la cyber-résilience
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.
Les trois incontournables de la cryptographie
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.
Qui est concerné et quel est le coût d'une non-conformité ?
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.
Les échéances à ne pas manquer : 2027 et le délai plus court de 2026
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.
Mise en correspondance des exigences de la CRA avec les contrôles cryptographiques
The CRA addresses cryptography across six control areas with direct implementation implications.
| Control Area | CRA Reference | Implementation Approach |
| Confidentialité des données stockées et en transit | Annexe I, partie I, § 2, point e) | Encrypt relevant data using state-of-the-art mechanisms, backed by PKI that issues device and session certificates |
| Intégrité des données, des commandes et de la configuration | Annexe I, partie I, paragraphe 2, point f) | Protect commands, programs, and configuration from unauthorized manipulation through signed configuration and authenticated channels |
| Configuration et identité sécurisées par défaut | Annexe I, partie I, § 2, points b) et d) | Ship products with secure default configuration and a unique device identity provisioned at manufacture |
| Mécanisme de mise à jour sécurisé | Annexe I, partie I, paragraphe 2, point c) ; Annexe I, partie II, paragraphe 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 |
| Suppression sécurisée des données | Annexe I, partie I, paragraphe 2, point 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.
Se préparer à l'audit avant que l'organisme notifié ne le demande
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.
Comment Keyfactor peut vous aider
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.
Agir avant qu'il ne soit trop tard
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.
Vous avez des questions sur la loi sur la cyber-résilience ? Nous avons les réponses.
Qu'est-ce que la loi sur la cyber-résilience ?
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.
Quand la loi sur la cyber-résilience entrera-t-elle en vigueur ?
Essential requirements must be fully applied by December 11, 2027. Vulnerability and active-exploitation reporting obligations begin earlier, in September 2026.
À qui s'applique la CRA ?
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. .
Quelles sont les sanctions en cas de non-respect des obligations envers l'Agence du revenu du Canada (ARC) ?
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.
Quelles sont les exigences cryptographiques imposées par l'ARC ?
Products must ship with encrypted data protection enabled by default, cryptographically signed and verified firmware updates, and a unique device identity provisioned at manufacture.
Ai-je besoin d'un inventaire cryptographique pour me conformer aux exigences de l'ARC ?
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.
Quel est l'impact de la CRA sur les produits existants ?
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.
Quelle est la première étape pour se mettre en conformité avec la CRA ?
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.
S'abonner à La Source
Stay secure with Keyfactor's monthly newsletter, packed with expert insights and practical steps for quantum-readiness.
Lire la suite
Critères communs (ISO/CEI 15408) : ce que signifie l'évaluation cryptographique pour les fournisseurs de produits informatiques
En savoir plus
La loi européenne sur la cyber-résilience : un guide pratique sur la cryptographie et l’ PKI , destiné aux éditeurs de logiciels de type « Software »
En savoir plus