Achieve CRA Cryptographic Key Management Requirements

Your firmware team thought the hard part was signing releases. Your compliance lead thought the hard part was building the technical file. Then the CRA review starts, and both teams realise the fundamental issue sits underneath everything else: who controls the keys, where they live, how they’re used, and whether you can prove it.

That changes the conversation fast. Key management stops being an implementation detail and becomes a market-access question. If your product depends on secure updates, authenticated boot, encrypted storage, or trusted device identity, your cryptographic design is no longer something you tidy up later. It sits directly inside your conformity story.

Many teams I advise don’t fail here because they ignore cryptography. They fail because they treat keys as infrastructure plumbing. Under the CRA, that approach doesn’t hold. You need a deliberate system for generation, storage, usage, revocation, documentation, and evidence. You also need it early enough that engineering, security, legal, and product can all work from the same assumptions.

Table of Contents

Why Key Management Is Now a Boardroom Topic Under CRA

The pressure usually starts with a simple question from leadership: “Are we on track for CRA?” What sounds like a documentation exercise quickly turns into a design review of signing workflows, update pipelines, boot trust anchors, and operational ownership of private keys.

The reason is straightforward. The CRA doesn’t just ask whether your product includes security features. It asks whether you can maintain security across the product lifecycle, including vulnerability handling and trusted updates. If the keys behind those controls are weak, exposed, badly governed, or poorly documented, the whole control set becomes questionable.

The timeline forces earlier decisions

The CRA uses a phased timetable. Most provisions apply in full 36 months after publication, while incident and vulnerability reporting obligations activate within 21 months, which forces organisations to stand up secure signing workflows and cryptographic infrastructure sooner than many planned (sternumiot.com on CRA enforcement timing).

That matters at board level because key management has long lead times. Teams need time to:

Select an architecture: HSM, KMS, secure element, TPM, or a mix.
Change release workflows: Move signing out of ad hoc scripts and developer machines.
Define ownership: Security, platform engineering, manufacturing, and compliance all touch the process.
Create evidence: Logs, policies, diagrams, approvals, and technical-file artefacts don’t appear automatically.

A board doesn’t need to know every cryptographic primitive. It does need to understand whether the company can still place products on the EU market without reworking its release and trust model at the last minute.

Poor key management is now a business risk

The old mindset was that key handling lived with PKI engineers and embedded specialists. That isn’t enough anymore. If a signing key is extractable, if a device identity isn’t bound to hardware, or if revocation is improvised after shipment, the risk isn’t confined to a security finding. It can affect product shipment, incident response, and conformity claims.

Practical rule: If a private key can be copied by a person or process that doesn’t need to copy it, your design is already on the wrong track.

A practical example helps. Consider a connected industrial gateway. The product team may already encrypt storage and sign firmware. On paper, that sounds mature. But if the firmware signing key sits in a shared build server keystore, and if field devices trust updates without a documented key-rotation path, the organisation has a weak control plane behind a strong-looking feature set.

That is why CRA cryptographic key management requirements land in governance meetings. The board isn’t being asked to approve cipher suites. It’s being asked to fund the controls that make trusted products defensible.

Understanding the CRA’s Legal Mandate for Cryptography

The legal requirement isn’t “use cryptography” in the abstract. The CRA ties cryptographic practice to product security outcomes such as confidentiality, integrity, and protection against misuse. Once you read the Annex I obligations through that lens, key management becomes unavoidable.

Confidentiality requires more than encryption

CRA Annex I Part I.2(e) requires protection of data confidentiality for stored and transmitted data and explicitly requires secure key management alongside encryption. In IoT devices, poor key handling is a recognised failure point, and 22% of recent IoT vulnerabilities in the ES region stemmed from key mismanagement (cyberresilienceact.eu on disk encryption challenges).

That legal framing matters because many teams still describe compliance in terms of “we encrypt data at rest” or “we use TLS”. Those statements are incomplete. Encryption only protects data if the keys are generated properly, stored securely, released under the right conditions, and retired when necessary.

A practical example is automated disk decryption on a headless device. The device needs access to a decryption key during boot or startup. If the team hardcodes that key in firmware, stores it in a readable file, or injects it through a weak provisioning script, the encryption control looks good in a product brochure but fails under scrutiny.

Integrity and authenticity depend on trust anchors

The same legal logic applies to firmware and software authenticity. A product can’t claim trusted update delivery if the signing process relies on exposed private keys or undocumented trust anchors.

In practice, this means:

Boot trust must start somewhere defensible: usually hardware-bound identity or a secure element.
Signing authority must be controlled: not spread across unmanaged CI jobs or personal tokens.
Verification rules must be explicit: devices need a clear policy for what they trust, when they reject, and how they recover.

If legal, engineering, and product teams need a common starting point for interpreting these obligations, the European Commission CRA implementation guidance overview is a useful bridge between regulatory language and product decisions.

What the mandate means in day-to-day engineering

The law doesn’t reward cosmetic cryptography. It rewards controls that hold up operationally.

Here is the distinction I use with clients:

Legal objective	Weak implementation	CRA-aligned implementation
Protect confidential data	Encrypt data with app-managed secrets in config files	Encrypt data and protect release, storage, and retrieval of keys with controlled hardware-backed mechanisms
Protect software integrity	Sign builds with a shared file-based private key	Use controlled signing workflows, approval gates, and non-extractable signing keys
Prevent unauthorised access	Reuse credentials across manufacturing and field support	Separate identities, roles, trust anchors, and key permissions by function

If your architecture assumes that “trusted software” and “trusted key storage” are separate conversations, you’ll spend more time fixing evidence gaps later.

The legal test is evidence, not intent

A lot of teams have good intentions here. They mean to add revocation. They mean to separate development and production signing. They mean to formalise manufacturing keys after the next release cycle. The CRA pushes those plans into the present tense.

For manufacturers, the practical legal question is simple: can you show that confidentiality, integrity, and access control requirements are supported by real key management controls, not just by cryptographic libraries? If the answer is uncertain, you’re not looking at a small gap. You’re looking at a foundational compliance issue.

Managing the Full Key Lifecycle for CRA Compliance

Most CRA cryptographic key management requirements aren’t solved by buying one product. They’re solved by controlling the full lifecycle of each key type in your environment.

That means code-signing keys, firmware update keys, device identity keys, transport keys, disk-encryption keys, manufacturing keys, recovery keys, and any intermediate certificates that support trust decisions. Each one needs a purpose, an owner, a boundary, and an end state.

Start with a key inventory that engineers can use

Don’t begin with policy language. Begin with a working list.

For each key or certificate set, capture:

What it does: firmware signing, secure boot verification, device authentication, storage encryption, backend TLS, manufacturing enrolment.
Who owns it: platform security, product engineering, manufacturing, cloud operations, or supplier.
Where it exists: HSM, cloud KMS, secure element, TPM, build service, device flash, recovery environment.
When it’s used: build time, boot time, onboarding, update, runtime session, RMA, decommissioning.
What breaks if it’s compromised: update trust, fleet identity, confidentiality, service access, or recovery operations.

Without this inventory, teams miss hidden keys. I often see organisations document firmware signing but forget factory provisioning keys or support-only recovery credentials. Those forgotten assets become the awkward part of the technical review.

Generation and issuance

Key generation should match the sensitivity of the key and the blast radius of compromise.

For high-value private keys, especially signing keys, generation needs tight control. You want a governed process with named approvers, recorded parameters, and a clear custody model. Generating a release-signing key on a laptop, even “temporarily”, is exactly the kind of shortcut that creates lasting evidence problems.

A good practical pattern looks like this:

Security defines the key class and approved generation location.
The key is generated in controlled hardware or through a managed service backed by controlled hardware.
Metadata is recorded immediately, including purpose, owner, validity window, and linked product line.
Access rights are assigned to roles, not individuals.
The public trust material is distributed to the systems or devices that need to verify signatures.

A bad pattern is just as common:

developer creates key pair locally
key gets exported for CI convenience
same key ends up used in test and production
no one can later prove the original generation path

Storage and protection

Storage is where many programmes drift from “secure enough in practice” to “hard to defend in an audit”.

Here is the simple rule: private keys should live where applications and users can’t casually extract them. For top-tier signing keys, that means hardware-backed protection. For device-side secrets, that may mean TPMs, secure enclaves, or dedicated secure elements depending on product class and hardware constraints.

Practical example:

Non-compliant pattern: a firmware signing private key stored in a build runner filesystem, protected by an environment variable.
CRA-aligned pattern: the build pipeline sends a signing request to a controlled service that uses a non-extractable key in an HSM-backed environment, while the build runner never sees the raw private key.

For products with encrypted local storage, the same thinking applies. If the decryption key sits in plain software-accessible storage, the encryption story is weak. If the key is released only after a hardware-rooted trust check, you’re on firmer ground.

Distribution and provisioning

Key distribution isn’t just a backend problem. It often breaks in manufacturing and field onboarding.

When devices are provisioned, teams need to answer practical questions:

How does the device receive its initial identity?
Is that identity unique per device?
Is the identity tied to hardware?
Can the provisioning station request more privilege than it should?
Can a contract manufacturer copy trust material outside the intended flow?

This is one reason hardware-bound identity matters. It reduces ambiguity about who or what a credential belongs to. It also makes later evidence easier because you can show that trust starts in the device, not in a spreadsheet.

If you’re redesigning development controls around these flows, a CRA-aware secure software development life cycle reference helps teams tie key handling to release governance rather than treating it as a separate security track.

Use and access control

Keys should only be usable for their defined purpose. That sounds obvious, but many environments still allow broad, inherited permissions.

I recommend checking these points:

Separate duties: the person who approves a release shouldn’t also be able to alter signing policy alone.
Constrain usage: a code-signing key shouldn’t also issue device certificates or decrypt support archives.
Log cryptographic actions: sign, rotate, revoke, import, delete, and policy change events need a durable trail.
Use short trust paths where possible: fewer intermediates usually means fewer silent failure modes.

The strongest key-management design is often the one that removes human choice from the dangerous moments.

A broader architecture principle is helpful in these situations. If your release and device-authentication model is moving toward strong identity, least privilege, and explicit verification, Zero Trust Architecture Design is a useful companion read. It maps well to signing approval, workload identity, and service-to-service trust boundaries.

Rotation, revocation, and retirement

Rotation plans often exist only on paper. Under the CRA, that isn’t enough because vulnerability handling and secure updates depend on being able to change trust material under pressure.

A realistic rotation plan answers:

Which keys rotate routinely and which rotate only on trigger events?
How do devices trust the next key before the current one is retired?
Can old signatures still be validated where necessary?
How is compromise declared, approved, and communicated internally?
What happens to devices that miss an update window?

Revocation is even more revealing. Teams usually discover too late that they can revoke a certificate in the PKI but can’t get field devices to reject signatures tied to an old trust root without a risky bootloader change.

A practical example:

Weak approach: publish a revocation notice internally and plan to replace the key in the next major release.
Stronger approach: maintain an updateable trust store on the device, define emergency revocation procedures, and test rollback-safe transition paths before release.

Retirement matters too. Old keys shouldn’t linger because “some legacy job still needs them”. If they do, document the dependency, isolate the use case, and set a retirement plan with named owners.

CRA key lifecycle management controls

Lifecycle Stage	CRA-Aligned Control Requirement	Practical Example
Generation	Generate keys through controlled, approved processes with clear ownership and purpose	Release-signing keys are created in a governed hardware-backed environment with recorded approvals
Storage	Keep private keys non-extractable or tightly hardware-protected according to risk	Firmware signing keys remain inside an HSM-backed signing service rather than a CI runner
Distribution	Provision trust material through authenticated, documented workflows	Devices receive unique trust material during controlled manufacturing enrolment
Use	Restrict key operations by role, purpose, and workflow approval	A CI pipeline can request signing only after release approval and policy checks
Rotation	Predefine replacement paths and trust transitions	Devices trust a new signing certificate before the old one is retired
Revocation	Support rapid invalidation and field enforcement	A compromised signing chain can be blocked through managed trust-store updates
Retirement	Remove obsolete keys and archive evidence	End-of-life manufacturing keys are disabled, logged, and retained only as evidence records

What works and what doesn’t

What works is boring, repeatable, and controlled. Named owners. Hardware-backed protection for high-value private keys. Separate trust domains. Tested transition paths. Logging that survives scrutiny.

What doesn’t work is convenience-first crypto. Shared secrets in deployment scripts. Signing from developer workstations. Reused identities across product lines. “Temporary” exceptions that become permanent.

If your team wants one practical standard, use this one: every key should have a reason to exist, a protected place to live, a documented way to be used, and a planned way to die.

Choosing the Right Tools for Secure Key Management

Tool selection gets messy because teams often compare products that solve different problems. An HSM, a cloud KMS, a device secure element, and an open-source crypto library don’t compete directly. They sit at different layers.

The right question isn’t “what tool is best?” It’s “what key class are we protecting, where is it used, and what evidence will we need later?”

HSMs for high-value signing authority

For private signing keys, the CRA sets a very high bar. The requirement level for these keys effectively requires HSM-backed protection with FIPS 140-2 Level 3 certification, making this a mandatory measure for products subject to the CRA and EU market access (Encryption Consulting on CRA compliance and HSM-backed signing keys).

That should drive one clear decision. If you’re still protecting production firmware-signing keys in software-accessible stores, stop treating that as a mature interim state.

An HSM is the right fit when:

The key signs firmware or software releases
Compromise would affect many devices or product lines
You need strong auditability and custody controls
Multiple teams touch the release process

Trade-offs are real. HSMs add operational cost, approval workflow design, and integration effort. But for high-value signing keys, those trade-offs are usually easier than defending a weaker architecture.

KMS and cloud services for operational scale

A KMS can be excellent for application-layer secrets, service encryption keys, and controlled backend use cases. It often gives teams better operational speed, API integration, policy controls, and central management than hand-built key stores.

For cloud-native environments, managed services can simplify adoption. But don’t blur categories. A cloud KMS may fit runtime service encryption while still not being your final answer for the most sensitive release-signing authority unless the design and underlying controls meet your risk and evidence needs.

A practical split I often recommend:

Product need	Better fit	Why
Firmware signing root or production signing key	HSM-backed service	Highest control and strongest boundary for non-extractable signing operations
Backend service encryption	KMS or cloud key service	Easier rotation, policy management, and integration with application services
Device-side identity or storage protection	Secure element, TPM, or enclave	Trust anchor needs to live in or close to the device hardware
Crypto implementation in software	Open-source library	Useful for protocol support, but not a substitute for secure key custody

If your current stack leans heavily on cloud secret storage, it’s worth reviewing where secret management ends and proper key custody begins. This overview of AWS Secrets Manager in CRA-related contexts is useful for drawing that line.

Secure elements and device hardware roots

On the device side, secure elements, TPMs, and enclaves often do the work a central HSM can’t do. They anchor local trust.

Use them when the product needs to:

hold a unique device identity
verify boot stages from a hardware root
protect local keys used for storage or mutual authentication
resist easy extraction in the field

For a simple practical example, compare two IoT sensor designs.

In the first design, every device in a product family ships with the same credential burned in during assembly. Support is easier at first, but compromise of one unit can undermine trust across the fleet.

In the second, each device gets its own hardware-bound identity and trust material. Provisioning is more disciplined, but compromise stays local and audit evidence is much stronger.

Hardware-backed identity tends to feel expensive until you price the operational pain of shared trust.

What open-source libraries can and can’t do

Teams often over-credit libraries such as OpenSSL, wolfSSL, mbed TLS, or BoringSSL. These are important building blocks for implementing cryptographic functions and secure protocols. They are not, by themselves, a key-management system.

A library can help you verify signatures, establish TLS sessions, or use approved algorithms. It doesn’t solve secure custody, approval workflow, tamper resistance, role separation, or evidence collection. If your product security narrative relies on a library name alone, it will look thin.

A practical selection rule by product class

Use a simple decision lens.

For consumer connected products, prioritise secure update signing, device uniqueness, and field-safe key rotation.

For industrial and embedded systems, add stronger focus on manufacturing provisioning, secure boot chains, and separation between operational technology and enterprise release authority.

For software-only products, concentrate on release-signing controls, backend secret segregation, and evidence-rich CI/CD approvals.

For multi-product manufacturers, centralise policy where possible but don’t force one key architecture across every product. The right answer for a battery-powered sensor isn’t always the right answer for a cloud-managed gateway.

Documenting Key Management for Your Technical File

A strong control that isn’t documented properly becomes hard to defend. Under the CRA, your technical file isn’t just a repository of diagrams. It’s the record that shows your cryptographic controls are deliberate, implemented, and auditable.

For key management, the file needs to answer three questions clearly. What keys exist. How they’re protected. How you know the controls are working.

What auditors and assessors need to see

CRA Annex I Part I.2(d) requires protection against unauthorised access, which in practice means auditable credential storage and cryptographic key management. The same analysis highlights hardware-bound Initial Device Identities (IDevIDs) per IEEE 802.1AR and HSM-backed key protection with FIPS 140-2 Level 3 as important technical evidence points for the technical file (ODVA CIP Security paper).

That gives you a practical documentation standard. Don’t just say “keys are protected”. Show the mechanism, the boundary, the process, and the evidence trail.

A workable structure for the file

A clean technical file section on key management usually includes the following.

Key management policy

This should define scope, ownership, roles, approval paths, and control objectives. Keep it specific to the product environment.

A useful model is to align it with the structure of an effective information security policy so it reads like an enforceable internal control, not marketing copy.

Include:

Key classes: signing, device identity, transport, storage, manufacturing, recovery.
Protection levels: which keys require hardware-backed custody and why.
Role separation: who can request, approve, operate, review, and revoke.
Environment boundaries: test, staging, production, manufacturing.
Exception handling: who approves deviations and how they’re time-limited.

Architecture evidence

Teams often stay too high-level at this point. A single generic platform diagram isn’t enough.

Include practical artefacts such as:

Trust chain diagram: root of trust through bootloader, firmware, update validation, and runtime identity.
Signing workflow diagram: source control to build to approval to signing to release publication.
Provisioning diagram: manufacturing enrolment, device identity issuance, backend registration.
Key boundary diagram: where private keys reside and which systems never receive raw key material.

Procedural records

This is the operating evidence. It proves the system runs as described.

Add records such as:

Generation records: request, approval, purpose, owner, environment, date.
Access reviews: periodic review of who can trigger signing or administer policy.
Rotation logs: planned rotations and emergency replacements.
Revocation runbooks: steps, responsibilities, communication channels, field enforcement method.
Incident tie-ins: how suspected key compromise is escalated and assessed.

If you need a practical framework for assembling this material, this guide to CRA technical file structure is a useful reference point.

A concrete example of good documentation

Suppose you’re documenting the firmware-signing process for a connected controller.

A weak description would say: “Firmware is signed before release using secure keys managed by the security team.”

A better description would say something like this, without needing to be verbose:

Production firmware is signed only through the release-signing service. The private signing key is stored in an HSM-backed environment and is not exportable. Build systems submit signing requests after release approval. The service logs requestor identity, artefact hash, approval reference, signing result, and timestamp. Devices verify signatures during update installation against the approved trust chain documented in Architecture Diagram KM-04.

That paragraph does real work. It names the mechanism, the boundary, the trigger, and the evidence.

Evidence that teams often forget

Some of the most useful supporting artefacts are not cryptographic at all.

Change-control records show when trust anchors or signing policies were updated.
Training records show that engineers and release managers understand the process.
Supplier control documents show how contract manufacturers or external build partners are constrained.
Test evidence shows that invalid signatures, revoked trust material, and outdated keys are rejected.

Documentation should let a reviewer reconstruct your trust model without interviewing your most senior engineer.

What not to put in the file

Don’t dump secrets, raw private key material, or operational details that create unnecessary exposure. The file should prove control, not leak sensitive implementation data.

Also avoid vague claims like “industry best practice”, “state of the art”, or “secure by design” unless you tie them to concrete controls. Reviewers don’t assess slogans. They assess evidence.

Your Actionable Key Management Compliance Checklist

Organizations generally don’t need another theory deck. They need a starting list that assigns work to the right people and exposes the gaps early.

Use the checklist below as a live programme tracker, not a one-off workshop artefact.

Manufacturer checklist

Inventory every key class: Include signing, device identity, storage, manufacturing, backend, and recovery keys.
Map each key to a product function: If a key has no clear business or technical purpose, remove it.
Identify high-value private keys: Treat production signing keys as a top-priority remediation area.
Move sensitive keys out of general-purpose storage: Replace file-based or script-managed custody with controlled hardware-backed protection where required.
Separate test and production trust: Don’t let convenience create cross-environment signing risk.
Document rotation and revocation paths: Make sure fielded devices can transition trust safely.
Capture evidence as you build controls: Policies, diagrams, approvals, logs, and test results should be gathered continuously.

Importer checklist

Importers don’t design the cryptographic architecture, but they do need confidence that the manufacturer’s conformity claims are credible.

Verify that key-management controls are documented: Ask for technical-file evidence, not a slide deck summary.
Check secure update claims: Confirm that the product has a defensible signing and verification model.
Review vulnerability-handling dependencies: If secure updates depend on weak key custody, post-market obligations become harder to trust.
Escalate ambiguity early: If the manufacturer can’t explain where critical signing keys live or how compromise is handled, treat that as a material issue.

Distributor checklist

Distributors often sit closest to the point where commercial urgency can override technical caution. Resist that pressure.

Confirm conformity artefacts are present: Missing or vague documentation around trust and updates deserves follow-up.
Watch for unsupported product changes: Rebranding, repackaging, or modified firmware can affect trust assumptions.
Maintain traceability: If questions arise about a product’s update integrity later, distribution records matter.

Three immediate actions for this quarter

Run a key-management gap review against your current release, provisioning, and device trust model.
Prioritise signing-key custody and evidence collection before lower-risk key classes.
Assign named owners across security, engineering, manufacturing, and compliance so key management doesn’t fall into organisational gaps.

The organisations that handle CRA cryptographic key management requirements well don’t treat them as a crypto-only project. They treat them as product governance implemented through engineering discipline.

If you’re trying to turn CRA obligations into a usable plan, Regulus helps manufacturers and digital product teams assess applicability, map requirements, structure technical-file evidence, and build a practical roadmap for 2025 to 2027 without managing the whole programme in spreadsheets.

Related publications