Three cryptographic controls CISOs need for post-quantum readiness

At a glance

What this is: This is Idemia’s analysis of three cryptographic controls for post-quantum readiness, centred on secure element-based HSMs, licensed quantum-ready libraries, and crypto-agility.

Why it matters: It matters because cryptographic governance, not algorithm selection alone, will determine whether identity, data protection, and regulated infrastructure can adapt without disruptive rework.

Context

Post-quantum readiness is an identity and cryptographic governance problem before it is a math problem. The article argues that organisations need to plan for how keys, libraries, and field-updatable systems will be governed when current encryption can no longer be assumed safe.

For CISOs, the practical issue is that cryptographic controls are not static assets. They are lifecycle-managed capabilities that must be deployable, maintainable, and revocable across devices, services, and regulated environments as standards evolve.

Key questions

Q: How should security teams start a post-quantum migration program?

A: Start by inventorying where cryptography is actually used, then measure external exposure first. Public domains, certificates, SSH keys, and service accounts should be mapped to owners and replacement paths before standards deadlines force a rushed program. A quick scan is useful, but the real work is governance, sequencing, and lifecycle control.

Q: What breaks when cryptographic systems are not agile?

A: Systems that hardcode algorithms or bind trust to one certificate format become expensive and slow to replace. When post-quantum standards change, those environments cannot adapt cleanly, and migration turns into a multi-year operational project. In identity terms, brittle crypto creates trust debt that eventually has to be repaid.

Q: How do HSM design choices affect cryptographic isolation and resilience?

A: A concentrated HSM architecture can create a shared processing bottleneck and a narrower isolation boundary for cryptographic operations. Distributed secure elements change that by spreading trust across dedicated hardware resources, which can improve tenant separation and operational resilience. The trade-off is that architecture decisions now shape both security and maintainability.

Q: What should organisations evaluate before adopting quantum-ready cryptographic libraries?

A: They should evaluate maintenance commitments, code-signing practices, integration support, and update cadence, not just the algorithm set. Post-quantum libraries will evolve, so the real question is whether the supplier and the internal team can sustain verification, testing, and timely correction as standards mature.

Technical breakdown

Why secure element HSM design changes key management

Traditional HSMs often concentrate cryptographic operations into a single processor and memory path, which creates deployment bottlenecks and can complicate isolation between tenants or processes. A matrix of secure elements distributes cryptographic work across dedicated hardware resources and enclaves, which changes both the isolation model and the operational scaling profile. In practice, the design is about reducing single-point concentration in the control plane for keys and signatures, not simply adding more hardware capacity.

Practical implication: Evaluate whether your HSM architecture can isolate cryptographic operations per tenant, workload, or environment without overloading a single processing path.

Why quantum-ready libraries need more than code

Post-quantum cryptography is still evolving, so library choice is really a governance choice about maintenance, integrity, and support over time. Licensed libraries can add code signing, integration support, and contractual update expectations, which matters when deployments span non-standard hardware or software environments. The article’s point is that PQC readiness depends on controlled implementation, continuous testing, and update discipline, because migration will not be a one-time swap of algorithms.

Practical implication: Treat PQC library selection as a lifecycle decision and verify who will maintain, sign, test, and support the code as standards change.

How crypto-agility turns algorithm change into normal operations

Crypto-agility is the ability to change cryptographic algorithms or protocols without rebuilding the whole environment each time. That matters because post-quantum migration will touch endpoints, core systems, and cloud-connected services, and those dependencies make large-scale replacement slow and expensive. In regulated sectors, crypto-agility also becomes a compliance enabler because it supports faster adaptation when security-by-design requirements or incident-driven changes demand cryptographic updates.

Practical implication: Map which systems can accept field updates to algorithms, protocols, and key lifecycles without a full migration programme.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Crypto-agility is the control that matters most when cryptographic assumptions start moving. The article correctly shifts attention away from one-time migration planning toward the ability to change algorithms and protocols repeatedly in live environments. That is the real governance challenge for identity and data protection, because cryptographic dependency only becomes visible when systems must be updated without breaking trust chains. Practitioners should treat agility as a standing capability, not a project outcome.

Secure element distribution reduces cryptographic concentration risk more effectively than a single-processor HSM model. The article’s HSM argument is not about raw throughput alone. It is about physical and logical segregation of cryptographic operations so that key handling, tenant isolation, and operational resilience do not depend on one processing core and one protected enclosure. That changes the shape of the control plane for cryptographic trust.

Licensed cryptographic libraries create a governance boundary around post-quantum change. Open-source libraries can be useful, but the article highlights maintenance certainty, code signing, and integration support as part of the control story. That matters because PQC is still maturing, and organisations need a way to verify provenance, manage updates, and avoid silent drift in cryptographic implementation. The practitioner conclusion is that library provenance and supportability are now part of cryptographic assurance.

Post-quantum readiness is a lifecycle problem, not a single-control decision. HSM architecture, library governance, and crypto-agility each solve a different failure mode, but none is sufficient alone. One controls hardware isolation, one controls implementation maintenance, and one controls the ability to evolve. The discipline required is to manage cryptography as a governed lifecycle across infrastructure, software, and regulated operations.

Regulatory pressure will increasingly expose organisations that treat cryptography as a background service. The article ties crypto-agility to compliance expectations in frameworks and regulations such as PCI DSS, NIST CSF, CRA, NIS2, and DORA. That is a strong signal that cryptographic modernization will be assessed as operational resilience, not just security engineering. Practitioners should expect change-management scrutiny to expand from access controls into cryptographic controls.

What this signals

Crypto-agility is becoming the deciding factor in whether post-quantum plans are operational or aspirational. Security teams should assume that cryptographic change will recur, then build update paths into endpoint, application, and infrastructure governance so algorithm transitions do not become emergency programmes.

HSM design now affects governance as much as hardware assurance. When cryptographic operations are concentrated in one processing model, resilience depends on a narrow control boundary, so identity and platform teams should reassess where isolation actually exists.

Quantum-ready libraries require provenance and supportability decisions, not just technical compatibility. Teams that cannot verify update ownership, signing, and maintenance cadence will struggle to sustain cryptographic assurance as standards continue to move.

For practitioners

• Assess HSM concentration risk Review whether one processor, one memory path, or one operating envelope is carrying too much of your cryptographic trust boundary. Prioritise environments where tenant isolation and concurrent processing matter most.
• Inventory PQC library dependencies Map where cryptographic libraries are embedded in devices, software, and services, then identify which deployments can accept signed updates and vendor-supported maintenance.
• Test field update paths for cryptographic change Validate whether endpoints, core systems, and cloud-connected services can change algorithms and protocols without a full rebuild or extended downtime.
• Align cryptographic governance to compliance expectations Document how your cryptographic controls support resilience, reporting, and remediation obligations under sector and product-security requirements.

Key takeaways

• Post-quantum readiness is less about picking a new algorithm than about governing how cryptography changes across live systems.
• Secure element-based HSM design, licensed libraries, and crypto-agility each address a different failure mode in cryptographic resilience.
• Organisations that treat cryptography as a lifecycle capability will be better placed to adapt to post-quantum change without disruptive rebuilds.

Key terms

• Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
• Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
• Hardware Security Module: A hardware security module is a tamper-resistant device or service used to generate, store, and use cryptographic keys without exposing them directly to endpoints. For code signing, it reduces the chance that a compromised workstation or build server can steal the signing authority.
• Cryptographic Key Management: Cryptographic key management is the discipline of generating, storing, using, rotating, revoking, and auditing the keys that protect encrypted systems. In practice, it is the governance layer that determines whether encryption remains trustworthy across cloud, pipeline, and workload environments.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.