Post-quantum cryptography
A large enough quantum computer would break the public-key cryptography that protects today's TLS, VPNs, code signing and wallets, and data recorded now can be decrypted later. In August 2024 NIST published the first three finalized post-quantum standards: FIPS 203 (ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a digital signature scheme derived from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, a hash-based signature derived from SPHINCS+, a backup built on different mathematics).
What we do
- Cryptographic inventory across TLS, VPN, SSH, mail and signing
- Hybrid ML-KEM plus X25519 rollout plans
- Post-quantum certificate and PKI roadmap
- liboqs-based prototypes and interoperability tests
- Algorithm-agility design for custom software
- Post-quantum signing for wallets and ledgers
- Board-ready harvest-now risk summaries
In practice the first step is hybrid key agreement. The TLS 1.3 group X25519MLKEM768 combines classical X25519 with ML-KEM-768, so a connection stays safe if either is broken; it is now a Standards Track document in the IETF. Cloudflare reports hybrid key agreement on all TLS 1.3 sites, which is post-quantum only when the client also supports it, and ML-DSA for the Cloudflare-to-origin hop. Signatures are harder: certificate chains and hardware support lag key agreement, and AD CS can already issue ML-DSA certificates.
Our work is inventory and migration, not hype: find where RSA and elliptic-curve keys live (TLS, VPN, SSH, S/MIME, code signing, backups, wallets), choose hybrid modes first, test with open-source libraries such as liboqs, and plan algorithm agility so the next change is a configuration. The same ideas apply to wallet signing, key management and PKI.
Leading platforms we work with
- NIST post-quantum standards
- Open Quantum Safe liboqs
- Cloudflare
- Microsoft Active Directory Certificate Services
- OpenSSL
- Google Chrome
- Apple
- Signal
- AWS KMS
Platforms and practices
- ML-KEM (FIPS 203)
- ML-DSA (FIPS 204)
- SLH-DSA (FIPS 205)
- Hybrid X25519MLKEM768 for TLS 1.3
- Cryptographic inventory
- Algorithm agility
- Post-quantum certificates
- liboqs prototypes
- Harvest-now, decrypt-later risk assessment
- Post-quantum signing for wallets
References
- NIST: first three finalized post-quantum standards
- NIST FIPS 203: ML-KEM
- NIST FIPS 204: ML-DSA
- NIST FIPS 205: SLH-DSA
- IETF: hybrid ECDHE-MLKEM key agreement for TLS 1.3
- Cloudflare: post-quantum cryptography
- Open Quantum Safe: liboqs
- Microsoft: AD CS overview (ML-DSA)
- RFC Editor: RFC 10024, PQ/T hybrid key agreement for TLS 1.3 (Proposed Standard, 2026)
Sources last checked .
Product names are trademarks of their owners and are listed to describe our experience; they do not imply endorsement or partnership.
A WireGuard handshake in two messages
The initiator already knows the responder's public key, so Noise IK needs only one message each way. Both sides then derive the same pair of transport keys, data flows as ChaCha20‑Poly1305 packets over UDP, and the initiator quietly repeats the handshake when the session key gets old.
How we use Post-quantum cryptography for clients
Cybersecurity
We find out whether everything you run is safe from attackers, then we fix it.
Learn moreTailored Software
Software built around your business in weeks, and you own the code.
Learn moreManaged IT Services
We run your IT day to day so it stays secure: help desk, devices, Microsoft 365, Exchange, Active Directory, backups, networks and monitoring.
Learn moreFrequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWhat are the new post-quantum standards?
In August 2024 NIST published the first three finalized standards: FIPS 203 (ML-KEM, for key encapsulation), FIPS 204 (ML-DSA, a digital signature scheme) and FIPS 205 (SLH-DSA, a hash-based signature built on different mathematics as a backup). They derive from CRYSTALS-Kyber, CRYSTALS-Dilithium and SPHINCS+.
Why does harvest now, decrypt later matter for us?
Someone records encrypted traffic today and decrypts it once a large enough quantum computer exists. Data that must stay secret for many years is exposed first. We assess which of your data has that long life, then prioritize key agreement for those flows.
What is hybrid key agreement?
The TLS 1.3 group X25519MLKEM768 combines classical X25519 with ML-KEM-768, so a connection stays safe if either one is broken. It is now a Standards Track document in the IETF. It is the practical first step, and it protects only when both client and server support it.
Is our website already protected?
Possibly in part. Cloudflare reports hybrid key agreement on all TLS 1.3 sites, but that is post-quantum only when the visitor's client also supports it. Your origin servers, VPNs, SSH, mail and signing keys need their own inventory. We check each hop instead of assuming.
Why are signatures and certificates harder than key agreement?
Certificate chains, browsers and hardware support lag key agreement, so the ecosystem is not ready for every use. Active Directory Certificate Services can already issue ML-DSA certificates, which suits internal testing. We plan signatures carefully and prototype first with open-source libraries such as liboqs.
What do you actually deliver?
Inventory and migration, not hype. We find where RSA and elliptic-curve keys live (TLS, VPN, SSH, S/MIME, code signing, backups, wallets), choose hybrid modes first, test, and build algorithm agility so the next change is a configuration. We are not a certified provider of any standard.