Cyber Resilience Act for IT & Software
Cryptography and PKI for Software Products with Digital Elements
| Region | Global (applies to any product placed on the EU market, regardless of the manufacturer’s or publisher’s location) |
| Applicability | Software Producers and Publishers: standalone software, SaaS components with a digital element, and embedded software sold into the EU Open-Source Stewards: organizations that commercially distribute open-source software with digital elements, under conditions defined in the regulation Importers and Distributors: must verify producer compliance before making software available on the EU market |
| 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, 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).
For software specifically, manufacturers must ship products with cryptographic protection for data confidentiality and integrity enabled by default, cryptographically verified software updates, and a secure identity and authentication mechanism, all justified by a product-specific cybersecurity risk assessment rather than a fixed checklist. Important (Class I and II) categories include identity management systems and VPN software, both squarely within the IT and software industry.
Why it matters
The CRA applies to essentially any connected software product sold in the EU, and Important and Critical product categories, identity management systems, VPN software, and similar security-relevant software, carry stricter conformity assessment obligations than the default category.
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 software loses the CE mark required for EU market access, making this a market-access issue as much as a security one.
How this maps to cryptography
EU Cyber Resilience Act addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:
| Section | Function | What it says | Supporting Keyfactor Products |
| Annex I, Part I, §2(e) | Confidentiality of Data at Rest and In Transit | Encrypt relevant data at rest and in transit using state-of-the-art mechanisms, backed by the PKI that issues session and service certificates. | Command / EJBCA |
| Annex I, Part I, §2(f) | Integrity of Data, Commands, and Configuration | Protect commands, configuration, and application state 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 | Ship with secure default configuration and identity-based access control, meaning a unique service or instance identity provisioned at deployment rather than a shared default credential. | Keyfactor Command |
| Annex I, Part I, §2(c); Annex I, Part II, §7 | Secure Update Mechanism | Cryptographically sign software updates and disseminate them without delay, free of charge, throughout the mandatory support period. | SignServer / Signum |
| Implicit under the required risk assessment; anticipated in the forthcoming Annex K allow-list | Cryptographic Component Visibility | Identify and track embedded cryptographic libraries and algorithms across the software and its dependencies to assess exposure and support remediation. | Command / AgileSec |
| Annex I, Part I, §2(m) | Secure Data Deletion | Support secure and permanent deletion of data and settings, including cryptographic key destruction, for tenant offboarding or decommissioning. | EJBCA |
Audit readiness
Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:
- Risk Assessment Documentation: Has the organization performed and documented a product-specific cybersecurity risk assessment justifying its cryptographic design choices?
- Service and Instance Identity Provisioning: Is a unique cryptographic identity provisioned to each service, instance, or tenant, rather than relying on shared or default credentials?
- Signed Update Pipeline: Can the organization demonstrate that 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 software, including inherited open-source dependencies?
- Secure Erase and Key Destruction: Does the product support secure data deletion, including cryptographic key destruction, for tenant offboarding 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 for software the same way it does for hardware: no CE mark, no access to the EU market, plus fines up to €15 million or 2.5% of our global total revenue. Every connected software product we ship needs a real service identity, signed updates, 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 in September 2026, and that time disappears fast once you account for retrofitting products that were never built with a signing pipeline or per-tenant identity. If we can’t produce a cryptographic inventory for a product, including its open-source dependencies, we can’t tell a regulator, or ourselves, what’s actually exposed when the next vulnerability hits.
Related Compliances
CMMC 2.0 / NIST SP 800-171
