The UK's National Cyber Security Centre has published recommendations for configuring post-quantum cryptography in TLS, and its message to operators is blunt: now is the time to migrate. The update was announced in a blog post, Post-quantum updates to our TLS guidance, which signals that the agency's TLS advice now covers how to deploy post-quantum algorithms rather than just whether to think about them someday.

That shift matters for anyone running identity infrastructure in the UK, which is to say everyone with a login page. TLS is the transport under every SAML assertion, every OIDC token exchange, every SCIM provisioning call and every API that hands out a bearer token. If the key exchange protecting those sessions can eventually be broken by a quantum computer, the identity layer breaks with it. NCSC is now telling operators to stop treating that as a research topic and start treating it as configuration work.

The announcement itself is short. It states that NCSC has published its recommendations for configuring post-quantum cryptography in TLS and that migration should begin. It does not, in the material reviewed here, set a deadline, name a mandatory algorithm or attach any enforcement. Readers should go to the full NCSC guidance for the specific configuration recommendations rather than rely on summaries, including this one.

Some general context helps explain why TLS is the first target. The near-term quantum risk to TLS is not that attackers break today's sessions in real time. It is "harvest now, decrypt later": an adversary records encrypted traffic today and decrypts it once a sufficiently capable quantum computer exists. That makes the key exchange the urgent part, because it protects the confidentiality of everything that follows. Signatures and certificates matter too, but a forged certificate is only useful at the moment of the attack, while a recorded session stays recorded forever. This is why industry work on post-quantum TLS, including drafts in the IETF TLS working group on hybrid key exchange, has focused on combining a classical key agreement with a post-quantum key encapsulation mechanism so that the session is safe if either one holds. NIST has published final standards for post-quantum algorithms, including the key encapsulation mechanism ML-KEM in FIPS 203, which is the building block most of these hybrid deployments use. Whether and how NCSC's guidance aligns with those specifics is for the guidance itself to say.

For IAM teams, the uncomfortable truth is that TLS configuration is usually somebody else's problem until it isn't. Identity providers, reverse proxies, API gateways, load balancers and the odd forgotten Java keystore all terminate TLS, and they rarely share a single owner. Post-quantum key exchange tends to arrive as a client and server negotiation feature, so a modern browser talking to a modern CDN may already be using it while the LDAP-over-TLS connection to the on-premises directory is negotiating cipher suites that were fashionable when flip phones were. The good news is that most of the work is inventory and upgrades, not cryptographic invention. Nobody is being asked to implement a lattice scheme in a weekend. They are being asked to know what they run, update it, and turn the right options on.

There is also an encouraging precedent. The migration from TLS 1.0 and 1.1, and the earlier retirement of SHA-1 certificates, both looked endless at the time and both got done, largely because browsers and libraries moved first and the rest of the ecosystem followed. Post-quantum TLS is shaping up the same way. The organizations that treat NCSC's guidance as a checklist now will spend the next few years quietly patching. The ones that wait will get to rediscover every undocumented TLS endpoint in their estate during an incident, which is a terrible way to build an asset register but, admittedly, a very thorough one.

What to check: start with an inventory of every TLS termination point in the identity path, including IdP endpoints, token and introspection APIs, SCIM connectors, LDAPS and any service mesh sidecars, and record the library or appliance version behind each one. Read the NCSC guidance in full and compare its configuration recommendations against what those endpoints can negotiate today, paying particular attention to key exchange. Then open tickets with the vendors that can't yet do it, because a supported upgrade path is the one thing a configuration change can't fake.