Quantum computing does not need to become commercially ordinary before it creates a cybersecurity problem.

An attacker can collect encrypted information today, retain it for years and attempt to decrypt it after sufficiently capable quantum computers become available.

This creates an immediate risk for information that must remain confidential over long periods, including:

• Government and defence information
• Intellectual property
• Financial records
• Health information
• Customer identity data
• Legal documents
• Product-development information
• Long-lived credentials
• Archived communications
• Industrial and infrastructure data

The problem is not limited to encrypted files.

Modern software depends heavily on public-key cryptography for:

• TLS connections
• API authentication
• Digital certificates
• Software signing
• Package verification
• Device identity
• Secure updates
• VPNs
• Email security
• Secrets distribution
• User and workload authentication

A cryptographically relevant quantum computer could undermine many of the RSA, Diffie–Hellman and elliptic-curve mechanisms used by those systems.

Software teams should not respond by immediately replacing every cryptographic primitive themselves.

They should make their applications discoverable, configurable, replaceable and testable so that cryptographic algorithms can change without requiring a complete redesign of the product.

The most important preparation is therefore not installing one new algorithm.

It is building cryptographic agility across the software lifecycle.

---

Quick answer: What should software teams change for post-quantum readiness?

Software teams should make cryptography visible, replaceable and centrally governed before attempting a large-scale post-quantum migration.

The highest-priority changes are:

1. Inventory where public-key cryptography is used.
2. Identify RSA, Diffie–Hellman, ECDH, ECDSA and other quantum-vulnerable dependencies.
3. Record which data and credentials require long-term protection.
4. Remove hard-coded algorithms and certificate assumptions from application logic.
5. Introduce cryptographic abstraction, policy and configuration layers.
6. Upgrade libraries, runtimes, operating systems and gateways that will provide PQC support.
7. Test ML-KEM for key establishment and approved post-quantum signature schemes for relevant use cases.
8. Prepare TLS, PKI, code-signing and identity systems for larger keys, certificates and signatures.
9. Use approved hybrid cryptographic profiles where transition policy requires classical and post-quantum protection together.
10. Update key-management, certificate-renewal and algorithm-negotiation processes.
11. Require PQC roadmaps from cloud, SaaS, hardware and security vendors.
12. Add continuous cryptographic discovery and migration testing to CI/CD and operational monitoring.

The core rule is:

Do not scatter direct dependencies on individual cryptographic algorithms throughout application code. Build systems that can replace algorithms, keys, certificates and protocols through controlled policy changes.

Key takeaways

1. No one can reliably state the exact date when a cryptographically relevant quantum computer will arrive.
2. Migration must begin before that date because enterprise cryptography is embedded in applications, protocols, devices, certificates and supply chains that may take years to replace.
3. RSA, finite-field Diffie–Hellman, ECDH, DSA and ECDSA are vulnerable to a sufficiently capable quantum computer.
4. Symmetric algorithms and hash functions are affected differently and are not replaced on the same basis as public-key cryptography.
5. NIST finalised ML-KEM, ML-DSA and SLH-DSA in August 2024 and says they can be put into use now. [1]
6. ML-KEM establishes a shared secret. It is not a direct replacement for bulk data encryption such as AES.
7. ML-DSA is intended as a principal general-purpose post-quantum signature standard, while SLH-DSA provides a hash-based alternative with different performance and size trade-offs. [2]
8. Post-quantum migration begins with cryptographic discovery and inventory, not indiscriminate algorithm replacement.
9. Crypto agility means being able to replace and adapt cryptographic mechanisms without redesigning or interrupting the entire system. [3]
10. Hybrid cryptography combines classical and post-quantum protection during migration, but hybrid constructions must follow reviewed, protocol-specific designs.
11. PKI, code signing, software updates, device identity and long-lived certificates can be harder to migrate than ordinary web traffic.
12. “Harvest now, decrypt later” makes information with long confidentiality requirements a present-day priority.
13. A vendor claiming “quantum-safe” should be able to identify the exact standard, parameter set, protocol profile, validation status and migration limitations it supports.
14. Post-quantum readiness is an ongoing software architecture and governance capability, not a one-time compliance project.

What is post-quantum cryptography?

Post-quantum cryptography, or PQC, is cryptography designed to run on conventional computers while resisting attacks from both conventional and sufficiently capable quantum computers.

PQC does not normally require:

• Quantum processors
• Quantum networks
• Specialised quantum communication links
• Quantum key distribution
• New physical communication infrastructure

It is implemented through software, hardware and existing digital protocols using different mathematical foundations from the public-key algorithms most organisations rely on today.

Post-quantum cryptography is not quantum cryptography

The terms are easy to confuse.

Post-quantum cryptography uses mathematical algorithms on ordinary computing systems.

Quantum cryptography, including quantum key distribution, uses quantum-physics mechanisms and specialised infrastructure.

For most software teams, the relevant migration path is standardised post-quantum cryptography, not deployment of quantum communication hardware.

What does quantum computing threaten?

The most urgent impact is on asymmetric or public-key cryptography.

RSA

RSA security depends on the difficulty of factoring large integers.

A sufficiently capable quantum computer using Shor’s algorithm could solve that problem efficiently enough to break RSA-based:

• Key transport
• Encryption
• Digital signatures
• Certificates
• Authentication

Diffie–Hellman

Finite-field Diffie–Hellman depends on the difficulty of the discrete-logarithm problem.

Shor’s algorithm also threatens this foundation.

Elliptic-curve cryptography

Elliptic-curve systems depend on the elliptic-curve discrete-logarithm problem.

This affects mechanisms including:

• ECDH
• ECDSA
• EdDSA-family assumptions where applicable
• Elliptic-curve certificate infrastructures
• Many modern identity and secure-communication systems

Digital signatures

Quantum-vulnerable digital signatures protect:

• Application packages
• Container images
• Firmware
• Operating-system updates
• Documents
• Certificates
• API requests
• Transactions
• Identity assertions

A compromised signature system can affect authenticity and integrity even when no confidential data is involved.

Symmetric encryption and hashing

Quantum search algorithms create a less dramatic impact on symmetric cryptography than Shor’s algorithm creates for public-key cryptography.

Strong symmetric algorithms do not generally need to be replaced with lattice-based equivalents.

Instead, teams should:

• Follow current standards for acceptable key sizes
• Avoid ageing, weak or shortened configurations
• Use suitable security margins for long-lived protection
• Review hash lengths and protocol-specific guidance
• Avoid assuming that every “256-bit” label provides identical effective security

The immediate migration focus is therefore public-key encryption, key establishment and digital signatures.

Why act before a quantum computer exists?

The transition has two separate clocks.

The confidentiality clock

How long must the information remain secret?

A medical record, trade secret or government archive may need protection for decades.

The migration clock

How long will it take to identify, update, test and replace every vulnerable dependency?

Migration may involve:

• Application code
• Cryptographic libraries
• Browsers
• Servers
• API gateways
• Identity providers
• Certificate authorities
• Hardware security modules
• Network devices
• Mobile applications
• Embedded systems
• Partner integrations
• Archived data
• Long-lived devices

A useful risk expression is:

Required confidentiality lifetime
+
Migration and replacement time
>
Time remaining before the quantum threat

When that inequality may be true, preparation is already late.

What is “harvest now, decrypt later”?

“Harvest now, decrypt later” describes an adversary collecting encrypted traffic or files today so they can attempt to decrypt them in the future.

The attacker does not need to break the encryption immediately.

They only need to:

1. Capture the encrypted information.
2. Preserve the ciphertext.
3. Wait until cryptanalytic or quantum capability improves.
4. Recover the historic information while it still has value.

This is especially relevant to:

• Research and development
• National-security information
• Merger and acquisition plans
• Legal records
• Long-term contracts
• Customer identity information
• Genetic or medical records
• Infrastructure designs
• Industrial intellectual property

It is less relevant to information whose value disappears quickly, such as a short-lived session token that expires in minutes.

---

Which post-quantum standards are available now?

NIST published three foundational post-quantum cryptography standards in August 2024.

FIPS 203: ML-KEM

ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism.

It is used to establish a shared secret between parties communicating over an untrusted network.

That shared secret can then be used with symmetric cryptography to provide:

• Confidentiality
• Authentication
• Secure sessions
• Protected data exchange

ML-KEM is relevant to future versions or profiles of:

• TLS
• VPNs
• Secure messaging
• Key-management protocols
• Service-to-service communication
• Remote access

Available parameter sets include:

• ML-KEM-512
• ML-KEM-768
• ML-KEM-1024

A product team should not select a parameter set only by choosing the largest number.

The choice should follow:

• Applicable standards
• Protocol profile
• Security category
• Performance requirements
• Vendor guidance
• Interoperability requirements

FIPS 204: ML-DSA

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm.

It creates and verifies digital signatures for:

• Software
• Certificates
• Documents
• Transactions
• Identity assertions
• API messages
• Firmware
• Audit evidence

ML-DSA is designed as a primary post-quantum signature mechanism for general applications.

FIPS 205: SLH-DSA

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm.

It uses a different security foundation from ML-DSA and provides algorithmic diversity.

Its trade-offs include comparatively large signatures and different performance characteristics.

It may be appropriate where:

• Hash-based assurance is desirable
• Signature size is acceptable
• Algorithmic diversification is important
• The applicable profile explicitly requires it

Additional standards remain in development

NIST selected HQC as an additional code-based KEM in March 2025. A future FIPS 207 is expected to standardise it.

A future FIPS 206 is expected to specify FN-DSA, based on Falcon, for applications that may benefit from smaller signatures and public keys but can manage its more difficult implementation requirements.

As of June 2026, those future standards should not be described as final NIST FIPS.

The existing final foundation remains:

• FIPS 203: ML-KEM
• FIPS 204: ML-DSA
• FIPS 205: SLH-DSA

What should software teams inventory?

A cryptographic inventory should answer more than:

Where do we use encryption?

It should identify every use of cryptography across data protection, identity, integrity and trust.

Applications

Inventory cryptography used by:

• Web applications
• Mobile applications
• Desktop software
• Internal services
• Microservices
• Serverless functions
• Batch systems
• AI platforms
• Integration services

Protocols

Record uses of:

• TLS
• SSH
• IPsec
• VPN protocols
• S/MIME
• OpenPGP
• Kerberos
• OAuth and OpenID-related signing
• SAML
• DNS security
• Secure messaging
• Proprietary transport protocols

Algorithms

Record algorithms including:

• RSA
• DSA
• Diffie–Hellman
• ECDH
• ECDSA
• EdDSA
• AES
• SHA families
• HMAC
• Password-based KDFs
• Vendor-specific cryptography

Keys and certificates

Inventory:

• Server certificates
• Client certificates
• Root certificates
• Intermediate authorities
• Code-signing certificates
• Device certificates
• User certificates
• API keys
• Signing keys
• Encryption keys
• Key-agreement keys
• Trust stores

Libraries and frameworks

Identify:

• OpenSSL and compatible distributions
• Language cryptography libraries
• Java security providers
• .NET cryptographic providers
• Browser and runtime TLS stacks
• Mobile operating-system APIs
• Hardware SDKs
• Cloud KMS and HSM integrations
• Vendor-supplied libraries
• Statically linked dependencies

Infrastructure

Include:

• Load balancers
• Reverse proxies
• API gateways
• Service meshes
• Identity providers
• Certificate authorities
• HSMs
• Key-management services
• Databases
• Message brokers
• Storage systems
• Backup platforms
• Monitoring tools

Devices

Include:

• IoT devices
• Industrial equipment
• Sensors
• Routers
• Firewalls
• VPN appliances
• Mobile devices
• Payment terminals
• Vehicles
• Medical devices
• Long-lived embedded products

Supply chain

Ask vendors:

• Which cryptographic algorithms are used?
• Which algorithms are hard-coded?
• Which libraries provide them?
• Does the product support ML-KEM or post-quantum signatures?
• Is support experimental or production-ready?
• Which standards and parameter sets are implemented?
• Can certificates and trust stores be updated remotely?
• What is the expected support date?
• Will hardware need replacement?
• What interoperability testing has been completed?

What information should each inventory record contain?

A useful record may include:

{
  "system": "Public API Gateway",
  "environment": "Production",
  "protocol": "TLS 1.3",
  "algorithm": "ECDHE",
  "signature": "ECDSA",
  "library": "Managed gateway service",
  "certificate_authority": "Enterprise CA",
  "data_classification": "Confidential",
  "confidentiality_lifetime": "10 years",
  "owner": "Platform Engineering",
  "vendor_pqc_support": "Planned",
  "migration_priority": "High"
}

Additional fields may include:

• Algorithm parameter or key size
• Key location
• Key owner
• Certificate expiry
• Renewal method
• External dependencies
• Business process
• Recovery procedure
• Replacement cost
• Vendor contact
• Test status
• Approved migration path

The inventory should be machine-readable where possible.

A one-time spreadsheet becomes outdated quickly.

Discover cryptography during development

Cryptography should be discovered before software reaches production.

CI/CD checks can inspect:

• Source-code calls
• Dependency manifests
• Compiled binaries
• Container images
• Certificates
• Configuration files
• Infrastructure-as-code
• TLS settings
• Mobile packages
• Firmware images

Detection rules may flag:

• Direct RSA or ECC calls
• Weak parameters
• Deprecated protocol versions
• Hard-coded certificates
• Static trust stores
• Embedded public keys
• Unsupported libraries
• Custom cryptography
• Certificates with long expiry periods

Discovery output should feed the organisation’s broader cryptographic inventory.

Discover cryptography during runtime

Static analysis cannot find every negotiated protocol or managed-service dependency.

Runtime discovery can use:

• Active network scanning
• TLS handshake inspection
• Certificate collection
• Historical traffic analysis
• Gateway telemetry
• Service-mesh data
• Endpoint inventory
• Cloud configuration APIs
• HSM and KMS logs

The objective is to connect cryptographic evidence to an accountable system owner.

A scan that reports 8,000 RSA certificates without identifying their applications and replacement process is not yet an actionable migration inventory.

Prioritising migration

Not every cryptographic dependency has equal urgency.

A practical priority score should consider:

Confidentiality lifetime

How long must the protected information remain secret?

Trust lifetime

How long must a signature remain trustworthy?

A firmware-signing key may need to protect devices for 15 years even when no confidential information is involved.

Exposure

Can attackers capture the traffic, document or signed artifact now?

Migration lead time

How long will replacement take?

System lifetime

Will the product remain deployed after ordinary support cycles?

Replaceability

Can software be updated remotely?

Dependency depth

How many partners, devices or protocols must coordinate the change?

Business impact

What happens if confidentiality, authenticity or identity is compromised?

Regulatory importance

Does the system protect regulated, safety-critical or contractual information?

Vendor readiness

Is a supported migration route available?

A practical priority matrix

System	Confidentiality or trust lifetime	Migration difficulty	Suggested priority
Public marketing website	Low	Low	Lower
Internal API carrying current operational data	Medium	Medium	Medium
Customer identity platform	Long	High	High
Code-signing infrastructure	Very long	High	Critical
Embedded device with 15-year life	Very long	Very high	Critical
Legal and compliance archive	Very long	High	Critical
Short-lived development environment	Low	Low	Lower
Root and intermediate PKI	Very long	Very high	Critical

What is cryptographic agility?

Cryptographic agility is the ability to replace or adapt cryptographic algorithms, protocols, keys, certificates and implementations without redesigning the entire system or causing unacceptable disruption.

It is not simply a configuration value such as:

ALGORITHM=ML-KEM

True crypto agility spans:

• Architecture
• Libraries
• Protocol negotiation
• Certificate handling
• Key management
• Deployment
• Testing
• Monitoring
• Governance

NIST’s final crypto-agility guidance treats agility as a broader operational capability for replacing and adapting cryptography while maintaining interoperability. [3]

How to design applications for crypto agility

1. Remove direct algorithm calls from business logic

Avoid:

createRsaSignature(order)

Prefer:

signatureService.sign(
    purpose = "order-approval",
    payload = order
)

The policy and cryptographic service determine the approved algorithm.

2. Use well-maintained providers

Applications should normally consume cryptography through:

• Platform APIs
• Approved libraries
• Managed key services
• HSM-backed services
• Standard protocols

Do not implement ML-KEM, ML-DSA or other cryptographic primitives directly unless cryptographic implementation is the organisation’s specialised responsibility.

3. Separate policy from implementation

The application should state the security purpose:

Establish confidential session
Verify software publisher
Sign audit event
Protect stored envelope key

A policy layer maps that purpose to approved mechanisms.

4. Support algorithm identifiers and versions

Persist enough metadata to determine:

• Which algorithm was used
• Which parameter set was used
• Which key signed or encrypted the data
• Which protocol profile applied
• Which software version produced it

Without metadata, future systems may be unable to verify old records.

5. Support more than one active algorithm

Migration periods frequently require:

• Old and new verification
• Dual certificates
• Multiple trust anchors
• Hybrid key establishment
• Re-signing
• Gradual client rollout

Design data structures and interfaces that can represent more than one algorithm cleanly.

6. Avoid fixed buffer assumptions

Post-quantum:

• Public keys may be larger
• Ciphertexts may be larger
• Signatures may be much larger
• Certificates may grow
• Handshake messages may grow

Review:

• Database fields
• API limits
• Header sizes
• Message queues
• Certificate parsers
• Network appliances
• Embedded buffers
• Log fields
• Hardware limits

7. Centralise cryptographic configuration

Do not rely on each application team manually selecting algorithms.

Use centrally managed:

• Security policy
• Approved profiles
• Library versions
• Trust stores
• Certificate templates
• Rollout flags
• Deprecation dates

8. Add emergency replacement paths

Cryptographic assumptions can fail independently of quantum computing.

The system should support:

• Rapid algorithm disablement
• Certificate rotation
• Key revocation
• Trust-anchor replacement
• Library patching
• Protocol downgrade prevention
• Emergency deployment

Crypto agility improves resilience against ordinary cryptographic failures as well as quantum threats.

A post-quantum-ready architecture

Layer 1: Asset and system inventory

Identify:

• Infrastructure
• Applications
• Data stores
• Endpoints
• Devices
• Cloud services
• Identities
• External providers

Layer 2: Cryptographic discovery

Discover:

• Protocols
• Algorithms
• Keys
• Certificates
• Trust stores
• Cryptographic libraries
• Network negotiations
• Supply-chain dependencies

Layer 3: Crypto-agility layer

Provide:

• Policy management
• Algorithm abstraction
• Negotiation
• Key orchestration
• Certificate management
• Observability
• Deprecation controls
• Configuration distribution

Layer 4: Hybrid and post-quantum mechanisms

Support approved combinations for:

• Key establishment
• Authentication
• Signatures
• Certificates
• Secure channels
• Data protection

Layer 5: Protected systems

Apply the migration across:

• TLS and PKI
• APIs
• Applications
• Databases
• Software signing
• Devices
• Cloud services
• Identity systems

What is hybrid cryptography?

Hybrid cryptography combines a traditional algorithm with a post-quantum algorithm during migration.

A simplified key-establishment example is:

Classical ECDH secret
+
ML-KEM secret
→
Combined session secret

The intended objective is to retain protection when at least one properly combined component remains secure.

Why use hybrid mechanisms?

Hybrid deployment can reduce migration risk because:

• Classical cryptography is widely deployed and understood.
• PQC implementations are newer.
• Not every client supports pure PQC.
• Standards and protocol profiles continue to mature.
• Organisations need transition periods.

Hybrid does not mean arbitrary combination

Teams must not invent combinations such as:

ECDH output + ML-KEM output

without using a reviewed construction and protocol profile.

Hybrid schemes introduce risks involving:

• Incorrect combiners
• Downgrade attacks
• Key reuse
• Certificate stripping
• Cross-protocol use
• Interoperability
• Failure handling

IETF engineering guidance recommends using recognised combinations and explicitly reviewed algorithm pairs rather than allowing arbitrary combinations. [4]

Do not confuse hybrid cryptography with fallback

A configuration that tries PQC and silently falls back to classical cryptography may provide no quantum protection during an active downgrade.

A strong hybrid construction requires the relevant components to contribute to the resulting protection according to the protocol’s security design.

TLS and API changes

Most application teams should receive PQC support through their TLS libraries, servers, gateways and cloud providers rather than writing a new handshake.

However, they still need to test the application consequences.

What may change?

• Key-exchange groups
• Handshake sizes
• Certificate sizes
• Packet fragmentation
• Connection latency
• CPU use
• Load-balancer compatibility
• Proxy behaviour
• Firewall inspection
• Session resumption
• Mobile-network behaviour

Application tasks

• Remove obsolete protocol restrictions.
• Update pinned cipher and group configurations.
• Upgrade TLS libraries and runtimes.
• Test hybrid negotiation end to end.
• Verify that gateways do not strip unsupported extensions.
• Test large handshakes over constrained networks.
• Confirm fallback and error behaviour.
• Monitor which profile was actually negotiated.

Do not assume the library default is enough

A library may support PQC without enabling it by default.

An application may also override modern defaults through:

• Fixed cipher lists
• Custom TLS configuration
• Legacy compatibility modes
• Pinned certificate expectations
• Gateway policies

Interoperability testing must confirm actual negotiation.

PKI and certificate changes

PKI may be one of the longest migration programmes because it involves:

• Root authorities
• Intermediate authorities
• Registration processes
• Certificate profiles
• HSMs
• Browsers
• Operating systems
• Applications
• Revocation
• Renewal
• Partner trust

Questions for the PKI team

• Can the CA issue post-quantum certificates?
• Can the HSM generate and protect the required keys?
• Can relying applications parse larger certificates?
• How will hybrid authentication be represented?
• Can trust stores hold new algorithm types?
• Can certificate discovery identify quantum-vulnerable chains?
• How long do root and intermediate certificates remain valid?
• How will historical signatures be validated?
• Can certificates be renewed without replacing hardware?

Long-lived roots are a priority

A root certificate may remain operational for decades.

Waiting until the end of its lifetime to begin PQC planning can create a trust-infrastructure bottleneck.

Digital signatures and code signing

Code signing may be more urgent than teams first assume.

A signature can remain relevant for as long as the signed software or device remains in use.

Examples include:

• Operating-system packages
• Mobile applications
• Containers
• Libraries
• Firmware
• Device bootloaders
• Industrial controllers
• Vehicle software
• Medical devices

Questions to answer

• Which algorithms sign current releases?
• Which trust roots verify the signatures?
• Can clients verify ML-DSA or another approved scheme?
• Can signatures be added without breaking old clients?
• Can existing artifacts be re-signed?
• How are offline devices updated?
• How long will the signed software remain deployed?
• Can an attacker replace firmware after a signature scheme becomes vulnerable?

Transitional strategies

Depending on the ecosystem, teams may consider:

• Dual signing
• Composite or hybrid signatures
• Separate classical and PQC signatures
• Re-signing important archives
• Shortening certificate lifetimes
• Updating secure-boot trust anchors
• Introducing new verification keys before they are mandatory

The selected method must be supported by the complete verification chain.

Producing a PQC signature has no value when the target device cannot parse or validate it.

Software supply-chain implications

PQC affects the trust systems around:

• Package repositories
• Build pipelines
• Artifact registries
• Container images
• SBOMs
• Provenance attestations
• Release manifests
• Update frameworks

Teams should inventory:

• Which service signs each artifact?
• Which algorithm is used?
• Which key-management service protects the key?
• Which consumers verify the signature?
• How long must the signature remain valid?
• Can the repository represent multiple signatures?
• Are old verification clients still deployed?

A post-quantum signing migration should be tested from the build service through the final consumer—not only at the signing API.

Identity and authentication changes

Post-quantum readiness affects machine and human identity systems.

Workload identity

Microservices may authenticate using:

• Mutual TLS
• Signed tokens
• Workload certificates
• Service-mesh identities
• Cloud identities

The trust chain, certificate profile and signing algorithm may all need migration.

User identity

Identity protocols may depend on quantum-vulnerable signatures for:

• ID tokens
• Access tokens
• SAML assertions
• Verifiable credentials
• Passkeys
• Federation metadata

Application teams should not create custom PQC token formats.

They should follow mature protocol profiles and identity-provider support.

Device identity

Devices present special difficulty because they may have:

• Limited memory
• Limited processing power
• Fixed firmware
• Long deployment lifetimes
• Poor update connectivity
• Hardware-embedded trust roots

Post-quantum support should be considered during product design rather than deferred to end-of-life maintenance.

Databases and data at rest

Database encryption often uses symmetric cryptography, but public-key cryptography still appears in the surrounding key lifecycle.

Examples include:

• Wrapping data-encryption keys
• Transporting backup keys
• Authenticating KMS requests
• TLS connections
• Signing backup manifests
• Database certificates
• Secrets-distribution systems

Envelope encryption

A common model is:

Data encrypted with a symmetric data key
↓
Data key protected by a key-encryption mechanism

The bulk data may not need re-encryption when the wrapping mechanism changes.

The team may instead need to:

• Re-wrap data keys
• Change KMS policies
• Rotate certificates
• Upgrade key-exchange protocols
• Preserve algorithm metadata

Archived encrypted data

For long-lived archives, record:

• Encryption algorithm
• Key-wrapping algorithm
• Key location
• Retention period
• Re-encryption plan
• Integrity mechanism
• Recovery dependencies

An archive is not protected merely because the bulk cipher is strong if the key was distributed using quantum-vulnerable public-key cryptography.

Secrets and key management

PQC does not reduce the importance of conventional key-management discipline.

Teams still need:

• Secure key generation
• Strong entropy
• HSM or isolated-key protection
• Access control
• Rotation
• Revocation
• Backup
• Recovery
• Separation of duties
• Audit logging
• Destruction

Expect operational differences

Post-quantum algorithms may introduce:

• Larger public keys
• Larger private keys
• Larger signatures
• New key-object types
• New HSM firmware requirements
• Different backup formats
• Different performance profiles

Do not assume that a KMS accepting an arbitrary byte array provides full, secure PQC lifecycle support.

Ask whether it supports:

• Native algorithm types
• Validated implementations
• Policy enforcement
• Non-exportable keys
• Audit events
• Rotation
• Certificate integration
• Backup and recovery

Mobile, IoT and operational technology

Long-lived devices can be the hardest assets to migrate.

They may remain deployed for:

• 10 years
• 15 years
• 20 years
• Longer in industrial environments

Design changes for new devices

New products should support:

• Updatable cryptographic libraries
• Replaceable trust anchors
• Secure firmware updates
• Multiple signature algorithms
• Adequate memory for larger objects
• Remote certificate renewal
• Algorithm metadata
• Recovery and rollback

Existing devices

Classify them as:

• Fully updateable
• Updateable with limitations
• Gateway-protectable
• Hardware-replacement required
• Unsupported

Gateway mitigation

A gateway may provide transitional protection for a legacy device.

However, it cannot retroactively fix:

• Weak device firmware verification
• An embedded vulnerable root
• Locally stored encrypted data
• Direct unauthorised physical access

Cloud and SaaS dependencies

Many organisations do not control the cryptography used by:

• Cloud storage
• Managed databases
• CDN providers
• Identity platforms
• SaaS applications
• Communication services
• Payment providers
• Managed certificate services

Vendor management is therefore part of PQC readiness.

Questions for providers

• Which NIST PQC standards are supported?
• In which regions and products?
• Is support experimental, optional or default?
• Are hybrid profiles available?
• Which clients interoperate?
• Does the service provide negotiation telemetry?
• Can customers control rollout?
• How are certificates migrated?
• Are customer-managed keys supported?
• Does enabling PQC affect pricing or performance?
• What is the retirement date for quantum-vulnerable configurations?

CISA’s migration guidance specifically encourages organisations to engage vendors and assess supply-chain readiness rather than treating PQC as an internal software-only project. [5]

Testing post-quantum implementations

PQC migration requires more than a functional test that two endpoints connect.

Interoperability testing

Test combinations of:

• Client library
• Server library
• Gateway
• Certificate authority
• HSM
• Cloud service
• Mobile application
• Partner system

Performance testing

Measure:

• Handshake duration
• CPU
• Memory
• Key generation
• Signing
• Verification
• Encapsulation
• Decapsulation
• Certificate parsing
• Network bytes
• Connection failure
• Tail latency

Network testing

Test:

• MTU limitations
• Packet loss
• Fragmentation
• Proxies
• Firewalls
• VPNs
• Mobile networks
• High-latency links
• Constrained devices

Failure testing

Test:

• Unsupported algorithm
• Expired PQC certificate
• Revoked key
• Hybrid component failure
• Downgrade attempt
• Corrupted ciphertext
• Invalid signature
• Old client
• Interrupted certificate rollout
• KMS or HSM failure

Security testing

Include:

• Side-channel review
• Input-validation fuzzing
• Constant-time implementation checks
• Key-reuse analysis
• Downgrade resistance
• Certificate-stripping resistance
• Error-message analysis
• Randomness testing

NIST’s KEM guidance stresses that securely deploying a KEM requires correct implementation and protocol integration, not only selection of a mathematically approved algorithm. [6]

What software teams should not do

1. Do not write custom PQC implementations

Use approved, maintained and validated providers.

2. Do not replace every symmetric cipher

The migration priority is not a global search-and-replace of AES.

3. Do not wait for a confirmed quantum arrival date

The migration and confidentiality clocks already exist.

4. Do not assume a TLS upgrade solves everything

Code signing, PKI, devices, identity, archives and vendor systems remain.

5. Do not describe an experimental implementation as fully quantum-safe

Identify exact standards, profiles and limitations.

6. Do not invent hybrid protocols

Use approved or thoroughly analysed constructions.

7. Do not hard-code ML-KEM or ML-DSA throughout business code

That recreates the same migration problem with a new algorithm.

8. Do not assume larger keys are a minor infrastructure detail

They can affect protocols, storage, firmware, hardware and gateways.

9. Do not trust vendor roadmaps without evidence

Request versions, dates, standards and interoperability information.

10. Do not create one static inventory

Cryptographic discovery must become continuous.

A practical post-quantum migration roadmap

Phase 1: Discover

Find cryptography across:

• Code
• Dependencies
• Certificates
• Protocols
• Networks
• Devices
• Cloud platforms
• Vendors

Deliverable: Initial cryptographic discovery report.

Phase 2: Inventory

Connect the findings to:

• System
• Owner
• Business process
• Data classification
• Algorithm
• Key
• Certificate
• Vendor
• Replacement path

Deliverable: Governed cryptographic inventory.

Phase 3: Prioritise

Rank systems using:

• Confidentiality lifetime
• Trust lifetime
• Exposure
• Migration difficulty
• Business impact
• Device lifetime
• Vendor readiness
• Regulatory significance

Deliverable: Risk-ranked migration portfolio.

Phase 4: Pilot

Select bounded use cases such as:

• Internal TLS connection
• Non-production API gateway
• Test code-signing workflow
• Certificate-lab environment
• Software-package verification
• Device prototype

Measure:

• Compatibility
• Performance
• Operational effort
• Failure modes
• Observability

Deliverable: Validated migration patterns.

Phase 5: Hybrid deployment

Introduce approved hybrid or transition mechanisms through:

• TLS profiles
• PKI
• Identity
• Code signing
• Device updates
• KMS and HSM services

Begin with high-priority systems and controlled client populations.

Deliverable: Production hybrid or post-quantum controls.

Phase 6: Govern

Establish:

• Algorithm policy
• Approved libraries
• Certificate profiles
• Vendor requirements
• Deprecation deadlines
• Exception management
• Continuous inventory
• Migration metrics
• Incident response

Deliverable: Sustainable cryptographic-agility programme.

Example 12-month readiness plan

Months 1–2

• Establish programme owner.
• Create cross-functional working group.
• Define inventory schema.
• Classify long-lived data.
• Identify critical PKI and signing systems.

Months 3–4

• Deploy discovery tooling.
• Scan source, binaries and protocols.
• Contact key vendors.
• Create initial migration risk register.
• Define approved testing libraries.

Months 5–6

• Build cryptographic abstraction in one application.
• Test ML-KEM in a controlled environment.
• Benchmark signature options.
• Test larger certificate and handshake sizes.
• Review KMS and HSM support.

Months 7–9

• Pilot hybrid TLS or another approved profile.
• Pilot post-quantum code signing.
• Test partner and mobile compatibility.
• Add CI/CD cryptographic checks.
• Define rollback and emergency controls.

Months 10–12

• Deploy to selected low-risk production systems.
• Establish negotiation and failure telemetry.
• Publish vendor compliance requirements.
• Approve multi-year migration roadmap.
• Integrate crypto agility into architecture standards.

How should readiness be measured?

Discovery metrics

• Percentage of systems scanned
• Percentage with identified cryptographic dependencies
• Unknown certificates
• Unsupported libraries
• Unowned cryptographic assets

Migration metrics

• High-priority systems with approved plans
• PQC-capable endpoints
• Hybrid-enabled connections
• PQC-capable certificate authorities
• Post-quantum signing pilots completed
• Legacy devices requiring replacement

Crypto-agility metrics

• Applications using central cryptographic abstraction
• Algorithms replaceable through policy
• Certificate-rotation time
• Emergency algorithm-disablement time
• Automated inventory coverage
• Vendor roadmap coverage

Operational metrics

• Handshake latency
• CPU and memory overhead
• Signature-verification time
• Failure rate
• Compatibility incidents
• Certificate size
• Deployment rollback rate

Governance metrics

• Exceptions
• Expired migration plans
• Unsupported vendor products
• Unapproved cryptographic libraries
• Policy violations
• Remediation time

What do proposed transition dates mean?

NIST’s IR 8547 remains a draft transition plan as of June 2026.

The draft and subsequent NIST presentations describe a proposed direction in which many currently approved quantum-vulnerable public-key mechanisms would be deprecated after 2030 and disallowed after 2035, with details depending on security strength and use case. [7]

These should be treated as planning signals rather than a universal final deadline for every organisation and jurisdiction.

A company may need to migrate earlier because:

• Its data must remain confidential beyond 2035.
• It operates long-lived devices.
• A customer requires PQC support.
• A regulator sets an earlier deadline.
• A national-security profile applies.
• A vendor retires a vulnerable configuration.
• Its migration programme will take many years.

The correct internal schedule should be based on exposure, data lifetime and replacement lead time—not only the last possible compliance date.

When is a product genuinely post-quantum ready?

A product is not post-quantum ready merely because one library contains ML-KEM.

A more complete readiness test asks whether the product can:

• Identify every important cryptographic dependency
• Negotiate approved PQC or hybrid profiles
• Protect and rotate PQC keys
• Process larger keys and signatures
• Issue and validate required certificates
• Verify post-quantum software signatures
• Update deployed devices
• Interoperate with required partners
• Fall back safely where policy allows
• Prevent unauthorised downgrade
• Monitor negotiated cryptography
• Replace algorithms again in the future
• Recover from implementation vulnerabilities
• Explain its supported standards accurately

How to evaluate a “quantum-safe” vendor claim

Request specific answers.

Algorithm

• ML-KEM?
• ML-DSA?
• SLH-DSA?
• Another scheme?
• Which parameter set?

Standard

• Final NIST FIPS?
• IETF RFC?
• Internet-Draft?
• Proprietary construction?

Protocol

• TLS?
• VPN?
• Code signing?
• Certificates?
• Data at rest?

Deployment model

• Pure PQC?
• Hybrid?
• Experimental?
• Production default?
• Optional feature?

Validation

• Which implementation?
• Which cryptographic module?
• Which security review?
• Which interoperability tests?
• Which supported versions?

Lifecycle

• How are keys rotated?
• How are certificates renewed?
• How are devices updated?
• What happens when the algorithm changes?
• How is telemetry provided?

“Uses post-quantum technology” is not a sufficiently precise product specification.

The broader lesson: prepare for cryptographic change, not only quantum change

Quantum computing is the immediate reason for a large cryptographic transition.

It will not be the last reason algorithms change.

Future migration may be triggered by:

• New cryptanalysis
• Implementation vulnerabilities
• Side-channel attacks
• Protocol defects
• Regulatory changes
• Performance requirements
• New hardware
• Revised standards

An application tightly coupled to one algorithm will face the same structural problem again.

A post-quantum programme should therefore leave the organisation with:

• Better cryptographic visibility
• Stronger key management
• Shorter certificate lifetimes
• Central policy
• Automated testing
• Replaceable providers
• Better protocol telemetry
• More disciplined vendor management

Those capabilities improve security even when a quantum attack never occurs on the predicted timeline.

Conclusion

Post-quantum readiness is not a race to insert a new algorithm into every codebase.

It is a programme to understand and modernise the trust foundations of software.

The first NIST post-quantum standards are already final and available for use.

The remaining challenge is integration.

Software teams must locate where quantum-vulnerable cryptography exists across:

• Applications
• APIs
• TLS
• Identity
• PKI
• Code signing
• Databases
• Devices
• Cloud services
• Supply chains

They must then build systems that can adopt new algorithms without destabilising the business.

The right question is not:

When will quantum computers break today’s encryption?

It is:

How long will our information and digital trust need to remain secure, how long will migration take, and can our software replace its cryptography safely when required?

Teams that answer those questions now can migrate deliberately.

Teams that wait for certainty may be forced into rushed upgrades, hardware replacement, compatibility failures and avoidable exposure.

Post-quantum readiness therefore begins before quantum computing arrives—and it begins with software architecture.

Frequently Asked Questions

What is post-quantum cryptography?

Post-quantum cryptography is cryptography designed to run on conventional computers while resisting known attacks from classical and quantum computers.

Is post-quantum cryptography available now?

Yes. NIST finalised ML-KEM, ML-DSA and SLH-DSA in August 2024, and states that organisations can begin using them now.

What is ML-KEM?

ML-KEM is a NIST-standardised post-quantum key-encapsulation mechanism used to establish shared cryptographic secrets.

Does ML-KEM encrypt application data directly?

No. ML-KEM establishes a shared secret that can then be used with symmetric encryption and authentication algorithms.

What is ML-DSA?

ML-DSA is a NIST-standardised lattice-based digital signature algorithm intended for general-purpose post-quantum signatures.

What is SLH-DSA?

SLH-DSA is a stateless hash-based digital signature standard that provides a different security foundation from ML-DSA.

Are RSA and ECC quantum-safe?

No. A sufficiently capable quantum computer could break the mathematical assumptions underlying RSA, Diffie–Hellman and elliptic-curve public-key cryptography.

Is AES broken by quantum computing?

Not in the same way as RSA or ECC. Quantum search affects symmetric security margins differently, so organisations should follow current guidance on suitable key sizes rather than replacing AES with a PQC public-key algorithm.

What is harvest now, decrypt later?

It is the strategy of collecting encrypted information today and preserving it until future technology can decrypt it.

What is crypto agility?

Crypto agility is the ability to replace or adapt cryptographic algorithms, protocols, keys and certificates without redesigning or interrupting the complete system.

What is hybrid post-quantum cryptography?

Hybrid cryptography combines classical and post-quantum algorithms during migration so protection does not rely entirely on one new or old algorithm.

Should developers implement PQC algorithms themselves?

No. Most teams should use standardised algorithms through maintained, reviewed and validated cryptographic libraries or managed services.

What should be migrated first?

Prioritise systems protecting long-lived confidential information, code-signing infrastructure, root PKI, identities, embedded devices and systems with long replacement cycles.

Does upgrading TLS make an organisation quantum-safe?

No. TLS is one part of the problem. PKI, code signing, identity, devices, archives, databases and vendor systems must also be addressed.

What is a cryptographic inventory?

A cryptographic inventory records where algorithms, protocols, keys, certificates and cryptographic libraries are used across the organisation.

What is a cryptographic bill of materials?

A cryptographic bill of materials is a structured record of cryptographic components and dependencies in a product. It may form part of a broader organisational cryptographic inventory.

Do certificates need to change for PQC?

Yes. Certificate authorities, certificate formats, signature algorithms, trust stores, hardware and relying applications may all require changes.

Will PQC increase key and certificate sizes?

Frequently, yes. The exact increase depends on the algorithm and protocol, and can affect networking, storage, parsers and constrained devices.

Should personal data be re-encrypted immediately?

Not necessarily. Teams should first assess how bulk data, keys and key-wrapping mechanisms are protected and prioritise based on confidentiality lifetime and exposure.

When should a software team start?

Now. Discovery, inventory, vendor engagement and crypto-agility work can begin without waiting for every protocol migration profile to become final.