TLS Just Got a Post-Quantum Standard: Why “Supported” Doesn’t Mean “Protected”

Every time you visit a secure website, your browser and that website’s server do a quick back-and-forth before any real data moves, agreeing on which encryption method they will both use for that specific connection. This is called a handshake, and it happens in a fraction of a second, invisibly, every time. The new standard adds post-quantum options to the menu of methods available during that handshake.

For a bank’s third-party risk team, the practical effect is that a vendor can now point at a named standard rather than a roadmap. That is a real improvement over the answers this space was getting a year ago. It is also the exact point at which most assessments stop asking questions, and the point at which they should keep going.

Here is the detail that matters. A real connection to a website rarely goes directly from your browser to one single server. It usually passes through several stops along the way, a content delivery network, a load balancer, a security gateway, before reaching the actual server. Each of those stops does its own separate handshake.

A website’s connection works the same way. Your browser might support the new post-quantum standard. The company’s server might too. But if the load balancer or gateway sitting in between has not been updated, that one stop can quietly fall back to older, non-post-quantum encryption, without anyone noticing, because the rest of the connection still works fine.

Once you can see the path, the single word “supported” splits into three quite different statements. They tend to arrive in a vendor response as though they were interchangeable. They are not.

That gap is exactly why “do you support post-quantum encryption” is the wrong question to ask a vendor. The better question is whether the whole path, every stop along the way, actually uses it, in practice, not just in theory.

A standard defines what is possible. Your actual configuration decides what is true.

1. 01

   Ask about the path, not the product. Request the list of hops a customer request passes through before it reaches the application, and the post-quantum status of each one. A vendor who cannot produce that list has answered a different question than the one you asked.

2. 02

   Ask what happens on fallback. Every deployment has a downgrade path for clients that cannot negotiate the preferred option. Ask what that path is, what triggers it, and whether anything logs or alerts when a connection takes it.

3. 03

   Ask for evidence from production, not from a lab. A named RFC in a roadmap is a plan. A record of what a live handshake actually negotiated, dated and repeatable, is evidence. The distinction is the whole subject of this post.

4. 04

   Re-ask after the next infrastructure change. A CDN swap, a new gateway, or a load balancer upgrade can reintroduce a weak hop without any change to the software list you were shown. Treat the answer as perishable rather than settled.