Skip to the main content.

AN ARCHITECTURE GUIDE

POST-QUANTUM READINESS

 

How to govern, prioritise and deliver cryptographic change

 

For CISOs, enterprise architects, cryptographic centres of excellence, platform owners and risk leaders preparing for the post-quantum era.

 

DOWNLOAD YOUR COPY

EXECUTIVE SUMMARY

 

Post-quantum migration now has standards and planning milestones. The first three NIST standards are final and ready for implementation, while security authorities are setting migration expectations that reach into the next decade. The UK National Cyber Security Centre, for example, advises organisations to complete discovery and initial planning by 2028, begin their highest-priority migrations by 2031 and aim to complete migration by 2035.

For CISOs and enterprise architects, this is an enterprise architecture and operating-model challenge, not simply an algorithm replacement programme. Replacing RSA or elliptic-curve cryptography with quantum-resistant alternatives is not a like-for-like upgrade: different cryptographic functions require different algorithms; keys and signatures may be considerably larger; protocols, certificates, schemas and relying systems may need to change; and guidance on hybrid schemes varies between authorities and use cases.

The architecture beneath applications will determine how difficult the transition becomes. When algorithms and cryptographic policy are embedded across hundreds of applications, every change becomes a distributed software project.

 

 

When applications are separated from cryptographic implementation, more of the migration can be managed through governed services and policy. That separation is the foundation of crypto-agility: the ability to discover, govern, test and evolve cryptography as standards, implementation guidance and business requirements change.

CORE PRIORITIES

The practical priorities are to establish clear visibility of the cryptographic estate, define decision rights and ownership, prepare data and integration layers for new cryptographic artefacts, and create a controlled way to change algorithms and policies without repeatedly rebuilding application logic.

WHO IS THIS GUIDE FOR

CISOs, enterprise and security architects, cryptographic centres of excellence, application and platform owners, infrastructure teams, risk leaders and programme managers. It can be used as a briefing document, a readiness-assessment framework and a starting point for defining migration priorities, ownership and target architecture.

ONE DESTINATION, SEVERAL MIGRATION PATHS

 

A cryptographically relevant quantum computer would undermine much of the public-key cryptography used today for key establishment, digital signatures and identity. The timing remains uncertain, but migration cannot wait for the threat to materialise. Long-lived systems take years to replace, and sensitive encrypted data collected today may remain valuable to an attacker in the future.

These positions are guidance for different constituencies, not a single set of global rules. Yet they matter to multinational organisations. Security policy, procurement requirements and sector obligations may differ by market and system. Enterprise architecture must be able to support distinct policy profiles without forcing teams to maintain separate application stacks.

PQC CHANGES MORE THAN THE ALGORITHM

 

Post-quantum algorithms have different operating characteristics and serve different purposes:

FUNCTION

RELEVANT ALGORITHMS

ARCHITECTURAL IMPLICATION

Key Establishment

 ML-KEM

Protocols and integrations must support KEM-based operation and larger cryptographic artefacts

General-Purpose Signatures

ML-DSA

Signing, certificate, encoding and validation ecosystems need compatible formats and implementations.

Alternative or Specialised Signatures

SLH-DSA, LMS and XMSS

 Size and performance may limit use cases. LMS and XMSS also require strict state management.

 

These differences extend into application and data architecture. Fixed database fields may not accommodate larger keys or signatures. API gateways may reject larger payloads. Indexes, message queues and network paths may carry assumptions inherited from RSA or elliptic-curve systems. Certificates and signed objects need enough metadata to identify the algorithm, parameters, key and encoding used.

Treating signatures as opaque, versioned objects can reduce hard-coded dependencies, but the surrounding context still needs to be retained. Discovering and correcting these assumptions before a production migration is far less disruptive than finding them during one.

THREE MODELS FOR CRYPTOGRAPHIC CHANGE

 

Each architecture model creates a different migration burden when algorithms, policy and implementation guidance evolve.

Embedded Cryptography

Application teams select libraries, algorithms, parameters and integration patterns. Every application may require separate remediation, testing and release work when cryptography changes.

HERO02

Centralised Key Management

A KMS or HSM centralises key custody and may perform selected operations, while applications still own much of the protocol and integration logic. Key control improves, but algorithm and protocol changes can still create substantial application work.

HERO02

Centralised Cryptographic Services

A governed service owns approved algorithms, keys, policy enforcement and cryptographic operations behind stable interfaces. More changes can be implemented through policy and service updates while application business logic remains stable.

HERO02

Modern key management systems do more than distribute keys. Many can sign, encrypt or decrypt without exposing private key material. That is an important security control, but it does not automatically provide enterprise-wide abstraction. Application teams may still decide which algorithms and modes to use, how certificates are handled and how cryptographic metadata is stored.

This burden grows as post-quantum options are introduced. Implementation teams must account for new parameters, larger objects, new failure modes and algorithm-specific lifecycle controls. Stateful hash-based signatures illustrate the risk. With XMSS or LMS, signing state must be managed so that a one-time key is never reused. A rollback or poorly coordinated backup process can undermine security even when the underlying algorithm is sound.

Concentrating these decisions in a governed cryptographic platform reduces the number of places where specialist expertise is required. It also makes policy easier to apply consistently and audit across the enterprise.

FROM KEY MANAGEMENT TO CRYPTOGRAPHIC SERVICE DELIVERY

 

In a service-based model, applications request a cryptographic operation with the context needed to apply policy. An application might ask a platform to sign a software release under an approved signing policy or protect a customer record for a defined data class. It does not need to hard-code the algorithm or manage the associated private key.

The platform can then determine which approved implementation satisfies the request. Security teams define permitted algorithms, parameters, key types and regional controls. Execution services enforce those decisions, manage metadata and perform the operation. Regional nodes can place execution closerto applications while maintaining central governance.

Centralised governance should not create a single operational bottleneck. Latency, throughput, resilience, data residency, observability and outage behaviour all need to be designed explicitly. Some high-volume or latency-sensitive operations may remain local while still consuming centrally defined policy. The objective is consistent control and replaceable implementation, not forcing every cryptographic operation through one physical service.

 

WHAT A CODE-SIGNING MIGRATION LOOKS LIKE

 

Consider an application that signs release artefacts using an RSA or ECDSA key and certificate. In a tightly coupled model, the application may specify the algorithm, call a local library, handle the certificate and assume a particular signature format. Moving to a post-quantum signature can require code changes, new libraries,revised interfaces and extensive retesting.

With a cryptographic service, the application requests an approved release signature through a stable interface. The platform selects the algorithm according to policy, protects the signing key and records the metadata needed for verification and audit. The application's core release workflow can remain separated from algorithm selection.

The migration is not invisible. Certificate profiles, signed-object formats, verification software and relying systems may still need to change. A service architecture cannot remove those ecosystem dependencies. It can prevent the same algorithm-selection and key-handling logic from being rebuilt independently in every signing application.

That is a more realistic definition of transparent migration: preserve stable business workflows where possible, while containing cryptographic change within a controlled part of the architecture.

SIX ACTIONS ENTERPRISES CAN TAKE NOW

WHERE PREPARATION IS STRONGEST - AND WHERE FOUNDATIONS ARE MISSING

 

Use the following questions to identify where preparation is strongest and where foundational work is still required:

Visibility

Can the organisation identify algorithms, keys, certificates, libraries, protocols, owners and dependent systems?

Ownership

Are policy, exceptions, migration decisions and residual-risk acceptance assigned to named roles?

Prioritisation

Can systems be ranked by data lifetime, exposure, criticality, upgradeability and supplier dependency?

Application Coupling

How many applications hard-code algorithms, key sizes, providers or cryptographic formats?

Data Readiness

Can schemas, APIs and networks handle larger, versioned cryptographic artefacts and their metadata?

Testing

Can teams test interoperability, performance, rollback, coexistence and repeated algorithm substitution?

A ROADMAP FOR GOVERNED POST-QUANTUM MIGRATION

 

Migration should move from sponsorship and discovery to architecture, pilots, migration waves and continuous crypto-agility.

01

MOBILISE & GOVERN

Establish sponsorship, scope, risk appetite, decision rights, standards and exception processes.

HERO02

02

DISCOVER & ASSESS

Build the cryptographic inventory, map dependencies, assess suppliers and prioritise systems according to risk and lifecycle.

HERO02

03

DESIGN THE TARGET ARCHITECTURE

Define service boundaries, policy models, interfaces, metadata requirements, regional execution and resilience.

HERO02

04

PILOT PRIORITY USE CASES

Validate interoperability, performance, evidence, operational ownership and fallback using a small number of high-value workloads.

HERO02

05

SCALE BY MIGRATION WAVES

Coordinate application, infrastructure, supplier and governance changes in prioritised groups.

HERO02

06

OPERATE CRYPTO-AGILITY CONTINUOUSLY

Maintain the inventory, monitor standards, test substitution, manage exceptions and retire obsolete cryptography.

HERO02

A PRACTICAL IMPLEMENTATION CHECKLIST

 

Use this as a working checklist for programme planning, architecture reviews and evidence discussions:

noun-tick-7996563-EF8000 Identify algorithms, keys, certificates, libraries, protocols and hard-coded dependencies.

noun-tick-7996563-EF8000Associate cryptographic assets with owners, dependent systems, suppliers and lifecycle status.

noun-tick-7996563-EF8000Classify information by confidentiality and integrity lifetime.

noun-tick-7996563-EF8000Record technology replacement cycles and supplier-readiness dependencies.

noun-tick-7996563-EF8000Define where cryptographic policy and expertise should be centralised.

noun-tick-7996563-EF8000Remove fixed algorithm, key-size and signature-size assumptions from applications and schemas.

noun-tick-7996563-EF8000Preserve algorithm, parameter, key and encoding metadata.

noun-tick-7996563-EF8000Test interoperability, latency, throughput, storage impact, rollback and coexistence.

noun-tick-7996563-EF8000Define exception, deprecation and evidence processes.

noun-tick-7996563-EF8000Review readiness and residual risk at regular programme checkpoints.

EVIDENCE MATTERS

The checklist should produce evidence that the organisation can discover, prioritise, govern, test and repeat cryptographic change.

KEY TAKEAWAYS

 

The organisations that succeed will treat cryptographic change as a reusable enterprise capability:

  • Post-quantum migration affects architecture, data, protocols, suppliers and operating processes - not only algorithms.

  • A cryptographic inventory and clear ownership are prerequisites for credible prioritisation.

  • Centralised key custody improves protection, but crypto-agility also requires control of policy, implementation and expertise.

  • Centralised cryptographic services can reduce application-level coupling while preserving regional execution and operational resilience.

  • The target capability is repeated, governed cryptographic change - not a one-time replacement of RSA or elliptic-curve cryptography.

CONCLUSION

 

Post-quantum readiness depends on adopting quantum-resistant algorithms, but algorithm selection is only part of the work. Enterprises also need visibility, governance and an architecture that can absorb repeated cryptographic change.

Centralised cryptographic services provide one way to create that separation. They allow security teams to govern algorithms and keys as a shared capability, while applications remain focused on stable operational requirements. When standards, policies or implementation guidance change, the organisation has a controlled place to respond.

Cryptomathic addresses both the service architecture and the operating model behind it. CrystalKey centralises HSM services and cryptographic policy enforcement behind application-facing APIs. CrystalKey 360 supports the wider visibility, ownership, lifecycle control, automation and evidence needed to prepare the cryptographic estate for change.

 

cryptomathic_logo_orange-06

ASSESS WHETHER YOUR CURRENT ARCHITECTURE CAN SUPPORT REPEATED ALGORITHM CHANGE

Explore Cryptomathic's approach to PQC readiness and crypto agility, or speak with the team about the path from key management to governed cryptographic service delivery.

TALK TO AN EXPERT TODAY