Plan a cryptographic migration

Operating objective

Replace cryptography before it becomes an emergency while preserving confidentiality, integrity, authenticity, availability, interoperability, and recoverability. The migration can respond to an obsolete algorithm, a vulnerable implementation, certificate or key change, protocol deprecation, compliance baseline, hardware retirement, or post-quantum transition.

Define the migration object. “Move to post-quantum” is not enough. State which protocol, application format, certificate profile, signature, key establishment, algorithm, parameter, library, hardware boundary, and population must change.

Build the inventory from several sources:

• Source and dependency search.
• Build artifacts and software bills of materials.
• Configuration, certificates, keys, trust stores, and infrastructure state.
• Network negotiation and protocol telemetry.
• Stored ciphertext, signatures, tokens, archives, and backups.
• Key-management and HSM inventory.
• Clients, upstreams, identity providers, external partners, appliances, and offline validators.
• Recovery images, disaster procedures, and rarely used administrative paths.

For every use, record owner, purpose, data or signature lifetime, algorithm, parameter, protocol, implementation, key, certificate, producer, consumer, environment, support status, and replacement constraint.

Signals and evidence

Prioritize by current security weakness, exposure, attacker opportunity, data lifetime, authority lifetime, active exploitation, algorithm status, implementation quality, upgrade support, and dependency lead time. Long-lived confidential traffic and long-lived signatures can require early post-quantum planning even when immediate exploitability is low.

Define measurable states:

1. Inventory complete for the scoped system.
2. New implementation passes standard test vectors and interoperability tests.
3. New readers or verifiers accept the new format under controlled policy.
4. New writers, signers, or handshakes use the new construction by default.
5. Stored material is migrated or assigned a bounded old-read period.
6. Every required consumer has adopted the new path.
7. Old negotiation and writing are rejected.
8. Old keys and certificates stop creating new authority.
9. Old reading and verification retire when data and evidence policy permit.
10. Recovery paths and backups use or correctly migrate the new state.

Collect telemetry by version and construction without exposing secret values. Measure handshake, signature, key, message, storage, CPU, memory, latency, fragmentation, failure, and fallback behavior. Record unknown and failed consumers.

Response and recovery

Use a phased, versioned plan. Develop against maintained libraries and final protocol profiles. Add explicit format and algorithm versions under server policy. Deploy read support before write use. Test mixed versions and rollback. Move writers only after readers are ready. Migrate stored data in bounded batches with reconciliation and integrity checks.

Prevent downgrade. A peer or record must not select an obsolete construction after policy retires it. Hybrid cryptography is used only when a defined protocol specifies the combination and security result. Do not concatenate independent secrets or signatures without a reviewed combiner.

Plan recovery for lost keys, unavailable HSMs, bad new releases, unreadable data, certificate failure, and partner delay. A rollback must not silently re-enable an unsafe algorithm for attackers. Keep a separately approved emergency path with narrow scope and expiry.

At the end, disable and remove old code, configuration, certificates, keys, trust anchors, libraries, hardware, test fixtures, and recovery images. Verify rejection. Preserve only the old verification capability required for retained signatures or evidence, under a bounded and isolated policy.

Design tradeoffs and residual risk

Dual support protects compatibility and expands parser, algorithm, key, and downgrade surface. Re-encrypting data simplifies final state and exposes plaintext during migration. Rewrapping data keys is faster and does not change the data construction. Long partner timelines can control retirement. Hardware acceleration and packet or certificate sizes can limit new algorithms.

Record each deferred consumer, old record class, or emergency fallback with owner, exposure, compensating control, deadline, and retirement trigger. Do not label the migration complete while an unmeasured old path remains.

Pomerium boundary

Pomerium upgrades determine which TLS, certificate, token, and library capabilities it supports. Operators control deployed versions, downstream clients, upstream services, certificate authorities, custom trust, and configured protocol behavior. Follow documented support and test the complete route.

Application ciphertext, signatures, data keys, and archives remain separate. Pomerium cannot migrate them. Do not enable broad legacy protocols around a protected route to preserve one old client without an explicit bounded decision.

Exercise

Choose one migration, such as retiring an old TLS version, replacing an application encryption format, rotating a signing algorithm, or preparing one service for post-quantum key establishment.

Produce:

1. Complete inventory with owners and consumers.
2. Risk and data-lifetime priority.
3. New standard and implementation profile.
4. Read, write, negotiation, key, certificate, stored-data, and recovery phases.
5. Interoperability, performance, failure, downgrade, rollback, and restore tests.
6. Telemetry and acceptance criteria for each phase.
7. Final removal and rejection proof.

Find one hidden dependency through traffic, storage, or recovery evidence that source search missed. Add it to the durable inventory and assign an owner.

Evaluation checklist

• Does the inventory cover source, build, configuration, traffic, storage, keys, certificates, hardware, partners, and recovery?
• Is priority tied to data and authority lifetime as well as current exploitability?
• Are new constructions final standards used through maintained protocols and libraries?
• Is the migration versioned and ordered as read-new, write-new, migrate, reject-old, and remove-old?
• Can a peer, record, rollback, or emergency path downgrade the result?
• Are mixed versions, backup restore, partner failure, performance, and new-key loss tested?
• Does completion evidence prove every old creation and negotiation path is rejected?