Cyber Resilience Act for Manufacturing:
Cryptography and PKI for Products
with Digital Elements
| Region | Global (applies to any product placed on the EU market, regardless of manufacturer’s location) |
| Applicability | Manufacturers: hardware and software products with digital elements, including embedded and IoT devices, sold into the EU Importers and Distributors: must verify manufacturer compliance before making a product available on the EU market Open-Source Stewards: organizations that commercially distribute software with digital elements, under certain conditions defined in the regulation |
| Relevant sections | Annex I, Part I: Essential cybersecurity requirements (design and default configuration) Annex I, Part II: Vulnerability handling requirements throughout the support period Annexes III and IV: Important and critical product categories subject to stricter conformity assessment |
Overview
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, is the EU’s first horizontal law mandating secure-by-design cybersecurity for products that are or contain a digital element (i.e. connected hardware, software, or remote data processing) placed on the EU market, tying compliance directly to CE marking. It splits obligations into product security design requirements (Annex I, Part I) and lifecycle vulnerability handling requirements (Annex I, Part II).
In practical terms, manufacturers must ship products with cryptographic protection for data confidentiality and integrity enabled by default, cryptographically verified software and firmware updates, and a secure identity and authentication mechanism, all justified by a product-specific cybersecurity risk assessment rather than a fixed checklist.
Why It Matters
The CRA applies to essentially any connected product or software sold in the EU: most products fall into the default category, with stricter obligations for Important (Class I and II) and Critical product categories such as identity management systems, VPN software, and smart meter gateways.
Essential requirements must be fully applied by December 11, 2027, with vulnerability and active-exploitation reporting obligations starting on a shorter timeline in September 2026. Penalties reach €15 million or 2.5% of global total revenue, whichever is higher, and non-compliant products lose the CE mark that is required for EU market access, making this a market-access issue as much as a security one.
How This Maps to Cryptography
The CRA addresses cryptography through several of the Annex I essential requirements, covering confidentiality, integrity, secure defaults, and update authenticity. The key control areas with direct cryptographic implications are:
| Section | Function | What it says | Supporting Products |
|---|---|---|---|
| Annex I, Part I, §2(e) | Confidentiality of Data at Rest and In Transit | Encrypting relevant data at rest and in transit using state-of-the-art mechanisms, backed by the PKI that issues device and session certificates | Command / EJBCA |
| Annex I, Part I, §2(f) | Integrity of Data, Commands, and Configuration | Protecting commands, programs, and configuration from unauthorized manipulation, typically through signed configuration and authenticated channels | EJBCA |
| Annex I, Part I, §2(b) and §2(d) | Secure by Default Configuration and Identity | Products ship with secure default configuration and identity-based access control, meaning a unique device identity provisioned at the point of manufacture | Keyfactor Command |
| Annex I, Part I, §2(c); Annex I, Part II, §7 | Secure Update Mechanism | Security updates should be cryptographically signed and disseminated without delay, free of charge, throughout the mandatory support period | SignServer Signum |
| Implicit under the required risk assessment | Cryptographic Component Visibility | Enable manufacturers to identify and track embedded cryptographic libraries and algorithms across the product and its dependencies to assess exposure and support remediation | Command AgileSec |
| Annex I, Part I, §2(m) | Secure Data Deletion | Ability to securely and permanently delete data and settings, including cryptographic key destruction | EJBCA |
Audit Readiness
CRA conformity assessments, whether self-declared or reviewed by a notified body, focus on whether cryptographic design choices are documented, justified by risk, and demonstrably implemented. Key areas that assessors and market surveillance authorities probe:
- Risk Assessment Documentation: Has the organization performed and documented a product-specific cybersecurity risk assessment justifying its cryptographic design choices?
- Device Identity Provisioning: Is a unique cryptographic identity provisioned to each device during manufacturing, rather than relying on shared or default credentials?
- Signed Update Pipeline: Can the organization demonstrate that firmware and software updates are cryptographically signed and verified before installation, with automatic updates on by default?
- Cryptographic Component Inventory: Does the organization maintain an inventory of every cryptographic library and algorithm embedded in the product, including inherited dependencies?
- 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, a minimum of five years or the product’s expected lifetime if shorter, documented and communicated to users?
TAKE THIS TO MANAGEMENT
The CRA turns cybersecurity into a market-access requirement: no CE mark, no access to the EU market. Not to mention fines up to €15 million or 2.5% of our global total revenue. Every connected product, hardware or software we ship needs a real device identity, signed firmware, and encryption enabled by default, backed by documentation proving we assessed the risk and designed accordingly.
We have until December 2027 for full compliance, but the vulnerability-reporting clock starts on a much shorter runway, and 36 months disappear fast once you account for redesigning products that were never built with a unique identity or a signing pipeline. If we can’t produce a cryptographic inventory for a product, we can’t tell a regulator or ourselves, what’s actually exposed when the next vulnerability hits
Related Compliances
ISO/SAE 21434
