The migration problem
A sufficiently capable cryptographic quantum computer would break widely used public-key systems based on integer factorization and discrete logarithms. Symmetric cryptography and hash functions have different quantum effects and can use suitable security strengths. Post-quantum cryptography provides standardized public-key constructions designed to resist known classical and quantum attacks.
NIST has standardized ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures. Algorithm availability does not make every protocol, certificate, library, hardware device, and partner ready.
Data and authority lifetime
Prioritize from the duration that confidentiality or signature trust must survive. An adversary can collect encrypted traffic now and attempt decryption later. Long-lived software, firmware, identity roots, archives, and signed artifacts may need migration before a cryptographically relevant quantum computer exists.
Inventory public-key uses, key lifetimes, data lifetimes, certificate chains, protocols, message sizes, performance limits, hardware, external dependencies, and upgrade paths. Include recovery and offline verification.
Controlled adoption
Use final standards through maintained libraries and protocols. Do not deploy an experimental primitive or invent a hybrid combiner. Follow the protocol owner's migration profile. Test larger keys, signatures, certificates, messages, handshake behavior, memory, latency, fragmentation, storage, logging, and intermediary limits.
Hybrid operation can combine classical and post-quantum mechanisms during transition when a defined protocol specifies how. It increases code and failure paths. Prevent downgrade and record which construction protected each session or artifact.
Failure and residual risk
Premature custom deployment can create more immediate risk than it removes. A post-quantum algorithm does not fix endpoint compromise, weak randomness, key custody, protocol confusion, or authorization. Long-lived signatures need timestamp, trust, revocation, and archival design. External certificate and protocol ecosystems can control the practical schedule.
Pomerium boundary
Pomerium's post-quantum readiness depends on supported TLS, certificate, library, platform, client, and upstream capabilities. Operators must follow supported releases and interoperability guidance. Do not wrap Pomerium traffic or assertions in an unreviewed custom cryptographic layer. Application owners separately manage long-lived encrypted data and signatures.
Evaluation checklist
- Which data and authority need confidentiality or authenticity for the longest time?
- Where are public-key algorithms used in protocols, certificates, signatures, archives, hardware, and partners?
- Are selected algorithms final standards used through a maintained protocol and library?
- Have message size, performance, fragmentation, storage, and intermediary limits been tested?
- Does any transition permit downgrade or ambiguous hybrid verification?
- Can old keys, algorithms, verification code, and stored material be retired safely?
