Post-quantum readiness and cryptographic agility

The first clock is the arrival of a cryptographically relevant quantum computer. Its date is uncertain. The second is the lifetime of protected data, and that one is easier to estimate. An attacker can collect encrypted traffic now and wait for a future capability to decrypt it. This store-now-decrypt-later model matters where intercepted material remains sensitive for many years. It matters less for data whose value expires quickly.

Signature risk has a different shape. A future ability to forge a signature could affect software updates, legal records, device trust and identity assertions. Old signatures may need proof that they were valid under the policy at signing time. Timestamping, audit evidence and re-signing procedures therefore belong in the plan. Do not treat confidentiality and authenticity as one risk score. They protect different assets and can require different migration order.

A system is agile when an approved algorithm or parameter can change without redesigning every business workflow. Applications should request a policy such as approved transport or durable signature rather than instantiate a named primitive throughout the codebase. Central libraries, service mesh policy, certificate automation and key-management APIs can reduce duplication, provided they do not become opaque single points of failure.

Data formats need algorithm identifiers, versioned parameters and enough space for larger keys and signatures. Protocol negotiation must resist downgrade attacks. Configuration changes should be deployable by environment, tenant or partner so teams can canary a new mode. Tests must include unsupported peers and rollback. Agility also means deletion: deprecated algorithms should be disabled after migration, not left enabled forever as a compatibility escape hatch.

Post-quantum key establishment and signatures have different performance, key-size and message-size characteristics from familiar elliptic-curve systems. Standardised schemes such as ML-KEM for key establishment and ML-DSA or SLH-DSA for signatures provide reviewed building blocks. An organisation should consume them through maintained protocol and library implementations rather than assembling mathematical primitives into a private wire format.

Hybrid deployment combines a classical and post-quantum mechanism so security does not depend on only one family during transition. The combination needs a published construction inside the protocol. Simply concatenating secrets or signatures without a defined combiner can introduce parsing, binding or downgrade errors. Track the exact protocol profile and implementation version. Interoperability tests should use more than one implementation where the interface permits it, because agreement with your own code proves little.

Enterprise cryptography is often certificate lifecycle management in disguise. Roots, intermediates, leaf certificates, enrolment, revocation and renewal already cross teams and vendors. Larger public keys or signatures can affect certificate chains, handshake messages, constrained devices and middleboxes. A laboratory handshake between two current servers does not prove that a production proxy, inspection device or older client will pass the same traffic.

Create a test hierarchy separate from production. Issue representative chains, exercise automated renewal, test revocation behaviour and measure handshake size and latency across real paths. Code-signing migration needs special care because old devices may only trust an existing algorithm while new releases need a future-safe path. Transitional packages may require multiple signatures or a staged trust-store update. Losing the ability to update a device is worse than carrying two signature paths for a controlled period.

A new algorithm does not repair weak key custody. Generation, access approval, rotation, backup, destruction and audit remain necessary. Hardware security modules and cloud key services may add support on different schedules. Ask what operation occurs inside the boundary, whether keys can be exported, how backups work and which firmware or certification constraints apply. A service that advertises one algorithm may not support the required protocol or key lifecycle around it.

Separate cryptographic keys by purpose and environment. A transport key should not become a signing key because both use public-key operations. Keep usage policy with the key record and enforce it in the calling interface. Rotation procedures need overlap, because distributed services and partners will not all switch in one instant. Log key version and algorithm with each protected artefact so a later investigation can identify which policy applied.

Payment gateways, government interfaces, telecom providers, identity platforms and document exchanges may control their own protocol schedule. Your internal services can migrate quickly and still remain tied to a classical algorithm at the boundary. Catalogue those dependencies, assign an owner and record the provider contact or contract path for change. An unanswered questionnaire is not an interoperability plan.

Build adapters so partner-specific cryptography terminates at a narrow boundary. Internal data can then use the organisation’s selected protections without spreading old compatibility through every service. Where a partner cannot migrate, assess data lifetime and compensating controls such as private connectivity, payload-level protection or reduced retained fields. Those controls should have an expiry review. Temporary exceptions have a habit of becoming architecture.

Roll out by protocol and risk tier. Start with test environments, internal low-risk paths and clients that the organisation controls. Measure negotiation outcome, handshake failure, message size, CPU cost, latency and fallback. A dashboard should distinguish peers that selected the new mode, peers that used an approved hybrid, peers that fell back and peers that failed. One aggregate success rate hides the very compatibility edge the migration is trying to find.

Rollback is allowed during a controlled test, but it must not silently re-enable a forbidden algorithm after the final cutoff. Put algorithm policy in version control and review it like code. Record who approved an exception, the systems covered and the end date. Incident response playbooks should include cryptographic failure: expired chains, broken negotiation, invalid signatures, inaccessible keys and unexpected downgrade. Teams need to rehearse these failures before a high-pressure standards change.

Post-quantum migration is only one reason to change cryptography. Libraries develop vulnerabilities. Certificate authorities change. Parameters age. A vendor stops supporting a device. A private key leaks. Systems that centralise inventory, policy, rollout evidence and key ownership respond better to all of these events. The programme should be judged by how quickly it can identify exposure and move a defined population to an approved state.

Create measurable exercises. Pick a non-production algorithm or certificate profile, declare it deprecated, locate every dependency and replace it through the intended path. Check whether the inventory was complete and whether owners could explain exceptions. Repeat with a partner endpoint and a long-lived signed artefact. The exercise will find missing configuration, manual renewals and hidden appliances long before the mathematical threat becomes immediate.

A useful readiness record contains the cryptographic bill of materials, data-lifetime assessment, migration tiers, approved profiles, partner dependencies, test evidence and exception register. It states what is unknown. This is more credible than claiming that an organisation is quantum safe, a phrase that has no meaning without scope, algorithm, protocol, implementation and operating assumptions.

The first delivery can be small: inventory one critical service path, move algorithm selection behind policy, add negotiation telemetry and rehearse a certificate profile change. That work produces evidence and exposes organisational friction. Repeat by risk tier. The goal is controlled change. A company that can identify, replace and verify its cryptography is better prepared for post-quantum standards, library flaws and the next algorithm retirement nobody has predicted yet.