Post-Quantum Security Is Not a Future Problem — RFC 9964, ML-DSA and What I Already Run in Production

TL;DR — the 90-second summary

Most organisations still file Post-Quantum cryptography under “interesting, but not now”. Understandable — the threat from quantum computers sounds like science fiction. The problem is that the standards, libraries, and platforms are being built right now.

RFC 9964 standardises ML-DSA for JOSE and COSE systems. That means JWTs, OAuth tokens, and OpenID Connect flows can now be migrated to Post-Quantum signatures through a standardised path. Keycloak — the most widely used open-source IAM platform — is actively watching this space.

Caddy, which I run as my reverse proxy and TLS terminator, already supports Post-Quantum hybrid key exchange in its production TLS stack. Compatible clients benefit from hybrid PQ key exchange today, on every connection.

The real question is not whether, but when and how fast. Anyone building platforms for the next five to ten years needs to embed Crypto Agility as an architectural principle — the ability to swap cryptographic algorithms in a controlled way, before an incident forces the issue.

This is not a future topic — the standards are being built right now

Mention Post-Quantum cryptography and you often get the same response: “Yes, that will matter one day. But quantum computers aren’t breaking encryption today.“ That is true. And it still misses the point.

The question is not whether a quantum computer will break RSA in real time tomorrow. The question is when the algorithms your platform runs on will be considered insufficient — and how much lead time you will have then.

What has happened over the past few years was not an academic exercise:

• NIST has finalised ML-DSA (FIPS 204) and ML-KEM (FIPS 203) as Post-Quantum standards.
• The IETF has defined a standardised integration path for ML-DSA in JOSE and COSE with RFC 9964.
• Projects like Keycloak are beginning to look at PQ signature support for OAuth and OpenID Connect.
• Production infrastructure components like Caddy already support PQ hybrid key exchange in the TLS handshake today.

This is not a research agenda. It is the production roadmap for the next five years.

RFC 9964 — what this means for digital identities in practice

RFC 9964 may look like yet another IETF specification in a long line. But what it addresses is directly relevant to modern platform architecture.

Virtually every API layer, every identity system, and every service-to-service communication today relies on JOSE-based protocols:

• JSON Web Tokens (JWTs)
• OAuth 2.0 access tokens
• OpenID Connect ID tokens
• Machine identities and API keys with signature validation

These protocols use cryptographic signatures — so far based on RSA or ECDSA. RFC 9964 defines how ML-DSA is integrated as a Post-Quantum signature algorithm into this world: with standardised algorithm identifiers, key representations, and signature formats for JWS and JWK.

What this means: identity providers, API gateways, and every platform that issues or validates JOSE-based tokens now has a standardised migration path — without proprietary workarounds.

This is the moment Post-Quantum cryptography stops being theory.

Caddy — Post-Quantum TLS already running in my production stack

More concrete than RFC 9964 is what I already have in production.

I run Caddy as my reverse proxy and TLS terminator. Caddy supports Post-Quantum hybrid key exchange in the TLS handshake — specifically hybrid key exchange combining classical Elliptic-Curve Diffie-Hellman with ML-KEM.

What this means in practice:

• Classic clients connect as normal — no interruption, no compatibility issues.
• Compatible clients — current Chrome and Firefox, Cloudflare endpoints — already benefit from hybrid Post-Quantum key exchange on every connection.
• For connections running over PQ hybrid, Forward Secrecy holds even against future quantum attacks.

This is not a lab experiment and not a pilot. It is my production default stack.

The advantage for me: I am building operational experience with PQ hybrid before anyone forces my hand. If in three years an identity provider requires PQ signatures, or an audit asks about PQ readiness, I have an answer based on production data — not a slide deck.

Why Keycloak makes this development interesting

Caddy handles TLS. RFC 9964 handles the signature standard for JOSE. The next escalation step comes when identity providers actually start issuing PQ signatures.

Keycloak is the central IAM platform for many mid-market stacks: Single Sign-On, OAuth 2.0, OpenID Connect, LDAP integration. When Keycloak starts supporting ML-DSA signatures in JWTs, the trust graph changes across every downstream service.

I am actively watching the ongoing work on Keycloak Post-Quantum signature support — not because I am planning a migration any time soon. But because the moment an identity provider starts issuing PQ tokens is the moment every downstream system needs to be able to validate them.

Anyone who hears about that for the first time when it happens will not have time for a calm architectural decision. Anyone who already knows it today has a structural advantage.

Crypto Agility — the real architectural challenge

Whether you are already running ML-DSA or ML-KEM is the wrong question. The right question is: How quickly could you, if you had to?

That is Crypto Agility — the ability to swap cryptographic algorithms in a controlled way, without operational disruption and without an architectural emergency.

What Crypto Agility requires:

• Visibility into the cryptography you run: Which algorithms run where? TLS versions, certificate types, signature algorithms in token validation, encryption in storage.
• Centralised identity management: A single identity provider that rolls out algorithm changes centrally — not twenty distributed systems each managing their own certificate lifecycle.
• Automated certificate management: ACME, automatic renewal, no manual certificate lifecycle.
• Infrastructure as Code: Cryptographic configuration lives in code, not an admin handbook.
• DevSecOps processes: Algorithm changes go through the same review and deployment pipeline as code changes.

Organisations that already have this in place will roll out PQ migrations like a planned upgrade. Everyone else will experience them as an emergency operation.

What this means for your platform in concrete terms

I do not recommend rushed migrations today. Anyone who hastily integrates a PQ algorithm into their platform without the foundations in place creates more attack surface than they remove.

What makes sense — and makes sense now:

Understand your cryptographic inventory. Where are certificates in use? Which systems issue or validate tokens? Which algorithms do your TLS connections, identity providers, and API gateways rely on? Anyone who cannot answer this has no basis for a migration — regardless of which algorithm they choose.

Prefer modern platform components. Caddy over older reverse proxies. Keycloak over proprietary legacy IAM systems. Automated certificate management over manual renewal. These decisions are sensible in their own right — and as a side effect they build the foundation for a PQ migration when it becomes necessary.

Establish Crypto Agility as an architectural principle. Cryptographic configuration in code, centralised key and certificate management, processes for controlled algorithm changes. Not because quantum computers are knocking on the door tomorrow — but because algorithm changes are a normal part of platform operations, and in a functioning DevSecOps structure they should never be an emergency.

Conclusion

Post-Quantum Security is not a topic you can defer to “someday”. The standards are set. The first platform components are implementing them. The identity systems will follow.

What I do: where technologies are production-ready, I use them. Caddy runs with Post-Quantum hybrid key exchange. I am actively watching RFC 9964 and the Keycloak developments. And the architectural principles — Crypto Agility, centralised identity management, automated certificate management — are not Post-Quantum measures. They are good platform architecture that delivers PQ readiness as a side effect.

Good security architectures do not emerge when a migration becomes unavoidable. They emerge by understanding technological developments early, evaluating them honestly — and integrating them sensibly into modern platforms.