There is a good chance your product already uses post-quantum cryptography and nobody on your team decided to turn it on. Your users' browsers negotiate it. Your CDN negotiates it. If your laptop runs a current OpenSSH, your SSH sessions negotiate it. None of that was a project. It arrived in a version bump.
That is genuinely good news, and it is also the reason post-quantum readiness is confusing to reason about in 2026. The parts that upgraded silently are the parts that get written about. The parts that did not upgrade are behind your load balancer, inside your VPC, in your VPN concentrator, in the artifacts you sign, and in the data you wrote to disk three years ago. Nobody ships those for you.
This post is for a small engineering team that keeps seeing post-quantum headlines and cannot tell whether it is a problem this quarter, this decade, or never. What generic articles get wrong is the framing. They open with quantum computers breaking RSA and close with "start your migration now", which tells a six-person team nothing about what to do on Monday. The useful question is narrower: which of your connections and signatures are already covered, which are not, and which of the uncovered ones matter given what you store and who buys from you.
Quick context: where the standards actually landed
NIST finalised the first post-quantum standards in August 2024. Three matter in practice: FIPS 203 for ML-KEM, the key encapsulation mechanism derived from CRYSTALS-Kyber, and FIPS 204 for ML-DSA, the signature scheme derived from CRYSTALS-Dilithium, with SLH-DSA as a hash-based signature alternative in FIPS 205. Everything shipping in production today traces back to those documents.
The deployment pattern that followed explains the whole shape of the gap. Key agreement moved fast and signatures did not. Key agreement is the piece exposed to harvest-now-decrypt-later: an adversary who records your traffic today can decrypt it later if a cryptographically relevant quantum computer arrives, so the clock on confidentiality started running years ago. Signatures do not have that property. A signature you verify today cannot be forged retroactively by a machine that appears in 2033, because the handshake is already over. The industry did the urgent half first, in hybrid form. The IETF published RFC 9794 in June 2025 purely to standardise the vocabulary for those hybrid schemes, which tells you how much of this transition is happening in that mode.
1. TLS key agreement already happened, and you were not consulted
The hybrid in question is X25519MLKEM768: classical X25519 elliptic curve Diffie-Hellman and ML-KEM-768 run together, with the session key derived from both secrets, so the connection stays safe as long as at least one of the two holds. The construction is specified in the IETF's ECDHE-MLKEM draft for TLS 1.3.
Chrome shipped a hybrid Kyber key exchange by default in 2023 and then migrated to the standardised ML-KEM codepoint once FIPS 203 was final. Firefox and Edge followed. The effect at scale is visible in Cloudflare's numbers: their October 2025 state of the post-quantum internet reported that over half of human-initiated HTTPS traffic to their network was already using post-quantum key agreement, and Cloudflare Radar, which tracks it continuously, put the share at roughly two thirds by April 2026.
Nothing about that required a decision from you. If you terminate TLS at a modern CDN or managed load balancer, the browser-to-edge leg of your traffic is very likely post-quantum already.
Takeaway: before you plan any migration, confirm what you already have. One command tells you whether a hostname will negotiate the hybrid: openssl s_client -connect yourdomain.com:443 -groups X25519MLKEM768, on OpenSSL 3.5 or newer. A completed handshake means that leg is done.
2. SSH upgraded too, and it is about to start complaining
OpenSSH has been ahead of the curve here for years. Per the project's own post-quantum page, OpenSSH 9.0 in April 2022 made sntrup761x25519-sha512 a default key agreement, 9.9 added mlkem768x25519-sha256, and OpenSSH 10.0 in April 2025 made the ML-KEM hybrid the new default when both ends support it. The SSH side of the standards work is tracked in the IETF's ML-KEM hybrid key exchange draft for SSH.
The part that will actually reach your team is behavioural. OpenSSH 10.1 warns on connections that did not get a post-quantum key exchange, telling the user the session may be vulnerable to store-now-decrypt-later attacks and that the server may need upgrading. That warning is suppressible with WarnWeakCrypto, which is exactly what somebody will do at 2 a.m. instead of fixing the server.
The servers that trigger it are the ones you forgot: an old bastion pinned to a long-term-support image, a vendor appliance, a build runner nobody has rebuilt since 2023. Same class of problem as stale machine credentials, same fix, which is an inventory rather than a heroic upgrade. Our post on eliminating static service account keys covers the adjacent half.
Takeaway: run ssh -Q kex | grep mlkem on your clients to confirm support, and ssh -v host 2>&1 | grep 'kex:' to see what actually got negotiated against each server you care about. The servers that fall back are your upgrade list.
3. The real gap sits behind your CDN, not in front of it
This is the finding that should change what you do this month. In the same October 2025 report, Cloudflare put post-quantum support on connections from their network to customer origin servers at 3.7 percent, up from 0.5 percent in 2023. Compare that to more than half on the browser-facing side.
Read that as an architecture statement. The user-to-edge leg is post-quantum because browser vendors and CDNs shipped it. The edge-to-origin leg runs on whatever TLS library your origin happens to have, which is usually whatever base image you built from, which is usually not new enough. Same for service-to-service calls inside your cluster, calls from your API to third-party providers, and anything terminating TLS in an application runtime rather than at a proxy.
Whether that matters depends on your threat model. Edge-to-origin traffic over a provider backbone is a harder interception target than traffic crossing consumer networks. It is not zero risk, and if you handle data with a long confidentiality life, health records or financial identity, it is the leg most worth fixing.
Takeaway: the highest-value post-quantum work available to a small team right now is not a migration project. It is upgrading the TLS library on the origin so it can negotiate the hybrid the edge is already offering. Usually that means a newer base image and OpenSSL 3.5 or later.
4. Certificates are still classical, and that is genuinely fine for now
Here is the part that surprises people who assume post-quantum is finished. When your browser makes a post-quantum-secure connection, the certificate that authenticated it is still signed with RSA or ECDSA. Cloudflare's October 2025 write-up put it plainly: a large share of internet traffic is protected by post-quantum key agreement while not a single publicly trusted post-quantum certificate is in use.
The reason is partly standards sequencing. The CA/Browser Forum Baseline Requirements, which govern what public CAs may issue into browser trust stores, have not been amended to permit ML-DSA, and the X.509 encoding work is still moving through the IETF's LAMPS working group. The other reason is size. ML-DSA signatures and public keys are far larger than ECDSA ones, and a chain carries several, which is a real handshake cost on mobile networks.
Practitioner opinion: this is the correct order of operations and you should not fight it. Confidentiality is retroactively attackable and authentication is not, so shipping hybrid key agreement first and signatures later is the right risk sequencing, not an oversight. Certificate lifetimes are shrinking on a separate track, which we covered in the 47-day certificate post, and that automation work is what will make a future signature swap boring rather than painful.
Takeaway: do not go looking for post-quantum public TLS certificates. They are not purchasable and not needed. Spend the effort on certificate automation instead, because whoever can rotate in an hour will handle the algorithm change in an afternoon.
5. The connections nobody put a hybrid on
Browsers and SSH got the attention. Several other channels in a normal startup stack did not, and they are worth enumerating because each one is a different owner.
Database connections, where the client library often bundles its own older TLS. Message queue and broker links. Service mesh mTLS, with its own internal CA and algorithm config. Site-to-site VPN and IPsec tunnels to a partner or payment processor, usually on vendor appliances with slow release cycles. Anything using a language runtime's built-in TLS rather than the system library, where the runtime version sets the algorithm list.
The managed services have moved further than most people assume. AWS supports ML-KEM hybrid post-quantum TLS on KMS, Certificate Manager and Secrets Manager endpoints, described on the AWS post-quantum page and in the ML-KEM announcement, which also notes that the earlier Kyber support is being retired in favour of the standardised ML-KEM. Google publishes its own status on a Cloud post-quantum resource page. The catch is that support usually needs a recent SDK on your side, so the provider being ready does not mean your caller is.
Takeaway: list every long-lived encrypted channel you operate, not just the public one, and write down which library terminates each end. That list is the actual scope of post-quantum work for your company, and for most seed-stage teams it is shorter than they fear.
6. Signatures on things that outlive the question
The retroactive-forgery argument that makes certificate signatures low urgency does not extend everywhere. It fails whenever a signature has to stay verifiable for a very long time, or whenever the thing being signed grants durable trust.
Firmware and code signing are the clearest cases. A key that certifies a bootloader or device image may need to be trusted for a decade, so verification happens well inside the window people worry about. That is why the NSA's CNSA 2.0 suite puts software and firmware signing at the front of its schedule for United States national security systems rather than the back. Most startups do not sell into that market, but the reasoning is portable: the longer a signature must stay valid, the earlier it needs a quantum-resistant algorithm.
The startup version of this is narrower than firmware. Long-lived JWT signing keys, signed software artifacts your customers verify, signed audit logs you promise are tamper-evident, and any offline signing key with a multi-year life. The tooling exists today if you want it: OpenSSL 3.5 ships ML-KEM, ML-DSA and SLH-DSA, and private PKI can issue ML-DSA certificates now precisely because it does not depend on browser trust stores.
Takeaway: sort your signing keys by how long a signature must remain verifiable. Anything above roughly five years belongs on a post-quantum plan. Everything under a year almost certainly does not.
7. Data at rest is a different problem with an easier answer
Post-quantum conversations drift toward TLS because that is where the visible action is, but harvest-now-decrypt-later is fundamentally about stored ciphertext, and much of yours never crossed a network in a capturable form.
Symmetric cryptography is not in the same danger. Grover's algorithm gives a quadratic speedup against symmetric ciphers, not the exponential break Shor's algorithm gives against RSA and elliptic curves, so AES-256 remains comfortable and AES-128 is weakened but not broken. If your disks, snapshots and object storage use AES-256 through your provider's KMS, the bulk encryption is fine. What needs attention is the wrapping: any place you used RSA to wrap a key guarding long-lived data, including a backup exported to a partner years ago that you cannot re-encrypt.
Takeaway: confirm AES-256 on storage encryption, then go looking specifically for asymmetric key wrapping over data with a long confidentiality life. That is where the at-rest exposure actually lives, and it is a much smaller search than auditing all of your encryption.
8. The deadlines that actually apply to a company your size
Two clocks get quoted at startups, and neither is the one that will reach you first.
The first is NIST's transition roadmap. The initial public draft of NIST IR 8547, published in November 2024, sets out the intended path: RSA, ECDH, ECDSA, DSA and finite-field Diffie-Hellman at the 112-bit security level become deprecated after 2030, meaning continued use requires a documented risk justification, and disallowed after 2035, at which point the option to accept the risk goes away. The second is CNSA 2.0, whose earliest milestones start in 2027, and which binds United States national security systems and their suppliers rather than the general market.
Practitioner opinion: for a pre-seed or seed company the binding deadline is neither. It is the first enterprise or regulated customer whose security questionnaire adds a post-quantum row, which is already happening in financial services procurement. That question arrives years before any regulator does, and the honest answer, that your public traffic is hybrid today and you have an inventory with a sequenced plan for the rest, beats a rushed migration nobody asked for. Same dynamic as every compliance framework we have covered, including SEBI's CSCRF reaching vendors through contracts.
Takeaway: write the inventory now because it is the artifact that answers the questionnaire. The migration itself can follow the vendor upgrade cycle for most of your stack.
9. The ninety-minute inventory
Everything above collapses into one afternoon of work.
Start with what you already have. Test your public endpoints for the hybrid group with openssl s_client -connect host:443 -groups X25519MLKEM768 on OpenSSL 3.5 or later, and record pass or fail per hostname. Then do the same for your origin, directly, bypassing the CDN, because that is the leg most likely to fail. Check your SSH fleet with ssh -v and read the negotiated kex line for each server. Note the OpenSSL or equivalent TLS library version in every base image you ship, since that single number predicts most of your results.
Then list what the tests cannot see: VPN and IPsec tunnels, database and broker client libraries, service mesh mTLS config, third-party SDKs that pin their own TLS stack, and every signing key with its maximum required signature lifetime written next to it. Sort the combined list by data sensitivity multiplied by how long that data stays sensitive, and stop. That sorted list is your plan. The rest is version upgrades on a normal cadence, the same discipline that keeps Kubernetes security features from quietly passing you by.
Takeaway: the deliverable is a one-page table, not a program. If somebody proposes a post-quantum migration project before that table exists, the table is the cheaper next step.
Where each part of your stack actually stands
| Channel or asset | Status in 2026 | Your move |
|---|
| Browser to CDN or edge | Hybrid ML-KEM by default, majority of traffic | Verify, then leave it alone |
| Edge to your origin | Mostly still classical, low single-digit adoption in 2025 | Highest value fix, upgrade the origin TLS library |
| SSH to your servers | Default hybrid since OpenSSH 10.0, warnings from 10.1 | Find and upgrade the stragglers |
| Public TLS certificates | Still RSA or ECDSA, no public post-quantum issuance | Nothing to buy, invest in rotation automation |
| VPN, IPsec, DB and broker links | Depends entirely on the vendor and client library | Inventory and ask vendors for their roadmap |
| Code and firmware signing | Standards ready, tooling ready, adoption early | Plan by signature lifetime, longest first |
| Data at rest | AES-256 is fine, key wrapping may not be | Hunt asymmetric wrapping over long-lived data |
| Regulatory pressure | Deprecation after 2030, disallowed after 2035 in the NIST draft | Customer questionnaires arrive far sooner |
What to do at your stage
Pre-seed. Do the ninety-minute inventory and nothing else. Verify your public endpoints negotiate the hybrid, upgrade base images to a TLS library that can, write the one-page table. Do not buy a crypto-agility platform, hire a consultant, or open a migration epic. Your exposure is small and your best move is answering the question accurately.
Seed, with enterprise or regulated customers. Add the edge-to-origin leg and the signing-key lifetime list. This is the stage where the questionnaire arrives, and where an inventory with dates beats a vague reassurance. If you sell into financial services in India, Singapore or the UAE, expect the question sooner than the global average.
Series A. Crypto-agility becomes the goal rather than any single algorithm: knowing every place an algorithm is named in config, changing it without a rewrite, rotating certificates and keys on automation rather than a calendar reminder. Practitioner opinion: teams that can already rotate everything in a day will find the eventual signature migration unremarkable. Teams that cannot will find it expensive whenever it lands.
If you want a second opinion on where you stand
MatrixGard runs a free 20-minute review for founders and CTOs. What your stack already negotiates, which legs are still classical, and whether any of it is worth your time before your next customer asks. Straight read, no NDA needed for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure on AWS, GCP, and Azure.
Methodology note. Algorithm standards are cited from NIST's published documents: FIPS 203, FIPS 204, and the initial public draft of NIST IR 8547, which is a draft and not final guidance. Version history and the 10.1 warning behaviour for SSH are from the OpenSSH project's own post-quantum page. Adoption figures, including the browser-side majority and the 3.7 percent origin-side figure, are from Cloudflare's October 2025 state of the post-quantum internet, with the more recent share from Cloudflare Radar; those measure traffic across Cloudflare's network specifically, not the whole internet. Provider support is cited from the vendors' own pages. Protocol details are from the relevant IETF drafts, which are drafts and may change. Sequencing advice, stage recommendations, and any judgement about what is worth your time are practitioner opinion, labelled inline. This post is engineering guidance, not a cryptographic assessment of your environment or legal advice.
