For years, cryptography lived in the background of software engineering, a detail teams rarely discussed outside a security review. The EU Cyber Resilience Act moves it to the center of product regulation. Under the CRA, the cryptographic choices inside your software now help decide whether it can legally enter the European market.
The mechanism is the CE mark. The same marking that governs the physical and electrical safety of EU products now extends to cybersecurity for anything with a digital element. Miss the CRA’s essential requirements, and your product cannot carry the CE mark.
Without the CE mark, the product cannot be sold. This applies to any manufacturer that places a product with digital elements on the EU market, wherever the company is based.
What the Cyber Resilience Act actually requires
The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the EU’s first horizontal, secure-by-design law for products with digital elements. Horizontal means it cuts across industries rather than targeting one sector. Secure-by-design means security has to be built into the product from the start, not added later.
The regulation splits obligations into two parts. Annex I, Part I covers product security design: the properties a product must have when it ships. Annex I, Part II covers lifecycle vulnerability handling: how you find, fix, and communicate vulnerabilities after the product is on the market. Meeting the CRA means satisfying both, not just hardening the initial release.
Who is in scope
The CRA reaches a wide set of roles across the software supply chain:
- Software producers and publishers, including standalone software and embedded software.
- Remote data processing solutions that are integral to a product, meaning the product cannot perform its function without them.
- Open-source stewards that distribute their software commercially.
- Importers and distributors, who must verify that the producer behind a product has met its obligations.
If you build, package, or resell software that reaches the EU, you almost certainly hold some responsibility under the CRA.
Default, Important, and Critical categories
The CRA tiers products by risk. Most products fall into the default category. Above that sit the Important classes (Class I and Class II) and the Critical category, which carry stricter conformity assessment obligations. Several Important examples land squarely in IT and software, including identity management systems, VPN software, and firewalls. If your product performs a security function like these, expect a higher bar of evidence. In some cases, that means review by a notified body rather than self-declaration.
Why it matters: CE marking, deadlines, and penalties
The business case is direct. Non-compliant software loses the CE mark required for EU market access. A CRA gap is therefore a revenue and distribution problem, not only a security one.
The penalties reinforce the point. Fines reach 15 million euros or 2.5 percent of global total annual revenue, whichever is higher. That ceiling covers breaches of the Annex I essential requirements and of the Article 13 and 14 obligations, and other obligations carry lower caps.
How the CRA maps to cryptography and PKI
The CRA addresses cryptography through several interlocking Annex I control areas. Each one names a security property, and behind most of them sits a public key infrastructure (PKI) capability that makes the property practical at scale. Here is how the pieces connect.
Confidentiality of data at rest and in transit
Annex I, Part I, section 2(e) requires products to protect the confidentiality of relevant data using state-of-the-art encryption, both at rest and in transit. In practice, that protection depends on a PKI that issues the session and service certificates used to establish encrypted channels and protect stored data.
Integrity of data, commands, and configuration
Annex I, Part I, section 2(f) requires protection of the integrity of stored, transmitted, and processed data, commands, programs, and configuration against manipulation not authorized by the user, and reporting on corruptions. Signed configuration and authenticated, certificate-backed channels give you a way to prove that a command or setting came from a trusted source and arrived unchanged.
Secure by default configuration and identity
Annex I, Part I, sections 2(b) and 2(d) require secure default settings and identity-based access control. Point 2(b) also requires the ability to reset the product to its original state, and point 2(d) requires reporting on possible unauthorized access. The practical goal is a unique service or instance identity provisioned at deployment, rather than a shared default credential that ships with every copy. Certificate-based identities let each workload authenticate as itself.
Secure update mechanism
Annex I, Part I, section 2(c), together with Annex I, Part II, points (7) and (8), requires a secure update mechanism. Updates must be distributed without delay and free of charge throughout the mandatory support period. They also need to be cryptographically signed, so recipients can verify authenticity before installing. Code signing is the control that makes this verifiable.
Cryptographic component visibility
Component tracking has an explicit hook. Annex I, Part II, point (1) requires manufacturers to identify and document vulnerabilities and components, including a software bill of materials in a machine-readable format covering at least top-level dependencies. Cryptography-specific expectations are being set through Annex K, a cross-vertical annex under development in the ETSI CYBER-EUSR standards mandated by standardization request M/606, which is expected to define an allow list of cryptographic mechanisms drawn from ENISA guidance The expectation is that you can identify the cryptographic libraries and algorithms embedded across your software and its dependencies. That lets you assess exposure and remediate quickly when a component is found weak.
Secure data deletion
Annex I, Part I, section 2(m) requires support for secure, permanent deletion of data and settings. For software that handles tenants or customer environments, that includes cryptographic key destruction during offboarding or decommissioning, so retired data cannot be recovered.
Getting audit ready: questions assessors will ask
CRA conformity assessments, whether self-declared or reviewed by a notified body, focus on demonstrated evidence rather than policy statements. A written intention to encrypt data counts for little without proof that the mechanism exists and works. Use the probe areas below as a checklist you can self-assess against:
- Risk assessment documentation that justifies your cryptographic design choices.
- A unique cryptographic identity for each service, instance, or tenant.
- A signed update pipeline that verifies signatures before installation, with automatic updates on by default.
- A cryptographic component inventory that covers inherited open-source dependencies.
- Secure erase and key destruction procedures for offboarding or decommissioning.
- Documented, communicated support-period commitments. Five years is the floor, longer where the product will be in use longer, shorter only where expected use is under five years.
Where to begin: a practical readiness path
You do not have to solve every requirement at once, but the sequence matters. A workable order looks like this:
- Confirm your Article 14 reporting process is live. That means a named owner, an intake path for vulnerability and incident signals, and the ability to file a 24-hour early warning, a 72-hour notification, and a final report through ENISA’s single reporting platform and your coordinating CSIRT
- Gain visibility into your cryptographic assets, since you cannot protect or justify what you cannot see.
- Provision unique identities for services and instances to replace shared defaults.
- Stand up a signed update pipeline with verification before installation.
- Build a cryptographic component inventory that includes open-source dependencies.
- Document the risk-based design decisions behind each choice.
Start early. The essential requirements land in December 2027, but the vulnerability-reporting obligations arrive in September 2026. The design changes above take time to plan, test, and roll out across a shipping product.
How Keyfactor can help
Keyfactor gives software publishers a concrete path from CRA requirement to implementation, mapping each control area to a capability you can deploy.
Keyfactor AgileSec addresses cryptographic component visibility. It discovers and inventories the cryptographic libraries, algorithms, keys, and protocols across your code, endpoints, cloud workloads, and dependencies. It then scores the risks, so you can prioritize remediation and evidence your exposure for an assessor.
EJBCA provides the PKI foundation for confidentiality, integrity, and secure-by-default identity. It issues the certificates that protect data in transit and at rest. It provisions unique service and instance identities in place of shared credentials, and it supports cryptographic key destruction for clean offboarding and decommissioning.
Keyfactor SignServer, together with Keyfactor Signum, delivers the secure update mechanism. Both cryptographically sign software updates and release artifacts, with hardware-protected keys and signed audit logs, so recipients can verify authenticity throughout the support period.
Keyfactor Command ties it together operationally. It automates the certificate lifecycle behind these identities and channels, giving security teams continuous visibility, automated renewal, and centralized governance across every environment.
Individually, these products satisfy specific CRA controls. Together they form Keyfactor’s Trust Control Plane. It is a single system for observing your cryptographic estate, analyzing risk, provisioning trusted identities, orchestrating action, and governing it all against policy. That is the same continuous loop the CRA asks you to demonstrate, from initial design through the full support period.
Ready to map your CRA obligations to a working readiness plan? Request a Demo.
Got Cyber Resilience Act questions? We’ve got answers.
What is the EU Cyber Resilience Act?
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s first horizontal law mandating secure-by-design cybersecurity for products with digital elements, meaning software or hardware products and their remote data processing solutions.. It ties compliance directly to CE marking and splits obligations into product security design and lifecycle vulnerability handling.
Does the CRA apply to software companies outside the EU?
Yes. It applies to any manufacturer that places a product with digital elements on the EU market, regardless of where the company is based. Software producers, open-source stewards that distribute commercially, and importers and distributors all carry obligations.
When do CRA requirements take effect?
The Article 14 reporting obligations have applied since September 11, 2026, and they cover products already on the EU market. The provisions on notified bodies have applied since June 11, 2026. The essential requirements, conformity assessment, and CE marking apply from December 11, 2027
What are the penalties for non-compliance?
Penalties reach 15 million euros or 2.5 percent of global total annual revenue, whichever is higher. Non-compliant software also loses the CE mark required for EU market access, making this a market-access issue as much as a security one.
What cryptographic controls does the CRA require?
The CRA addresses cryptography through several Annex I control areas. These cover confidentiality and integrity of data, secure-by-default configuration and identity, signed updates, cryptographic component visibility, and secure data deletion including key destruction. Each choice must be justified by a product-specific risk assessment.
What is a cryptographic component inventory and why does it matter?
It is a record of every cryptographic library and algorithm embedded in your software, including inherited open-source dependencies. Assessors expect it, and without one you cannot quickly determine what is exposed when a component vulnerability is disclosed.
Which products face stricter CRA obligations?
Important (Class I and II) and Critical categories carry stricter conformity assessment obligations than the default category. In IT and software, this includes identity management systems and VPN software.
How does PKI support CRA compliance?
PKI underpins the CRA’s core cryptographic requirements. Certificates encrypt data in transit and at rest and provision unique service and device identities. They also sign software updates, so recipients can verify authenticity throughout the support period.
