Why post-quantum cryptography matters now

I recently watched the latest video from John Savill (John Savill, Microsoft Azure architect) on quantum-safe cryptography, and it’s one of the clearer explanations I’ve seen on why this topic actually matters today.

Not for 20 years.
Not “once quantum computers exist”.
Today.

Quantum computing isn’t just about being faster

One of the most important things John says is that quantum computers don’t just make everything faster.

They are very good at solving very specific problems:

  • Factoring large numbers
  • Solving discrete logarithms
  • Finding the periods in mathematical functions

That’s exactly how modern public-key cryptography works.

RSA, ECC and Diffie-Hellman are all fundamentally broken once large quantum computers with the ability to tolerate faults are available.

Symmetric cryptography like AES-256 holds up better. Grover’s algorithm halves the effective key length, so AES-256 drops to 128-bit equivalent security, which is still strong. The urgent problem is asymmetric cryptography: your key exchanges and digital signatures.

The Real Threat: Harvest Now, Decrypt Later

The most uncomfortable part of the video is the reminder that attackers don’t need quantum computers today.

They can start capturing your encrypted traffic right now. Store it and decrypt it later when quantum computers are available.

If your data is important (like government or healthcare data, or data about who you are), then it could already be at risk in the future.

Post-Quantum Cryptography Helps

NIST finalized three post-quantum standards in 2024:

  • FIPS 203 — ML-KEM (Kyber) for key encapsulation
  • FIPS 204 — ML-DSA (Dilithium) for digital signatures
  • FIPS 205 — SLH-DSA (SPHINCS+) for hash-based signatures, as a conservative backup to ML-DSA

These algorithms don’t rely on math problems that quantum computers are good at solving. ML-KEM and ML-DSA are the ones you’ll see in TLS and certificate chains first. SLH-DSA is slower but relies only on hash function security, which makes it a useful fallback if lattice-based schemes ever get weakened.

Microsoft integrating these into SymCrypt, Windows, Azure, and M365 is a big step in the right direction.

Azure’s Advantage

One of the biggest benefits of using Azure’s services is that you don’t have to manage the cryptographic migration yourself.

Services like Azure App Service, Azure Storage, Azure SQL Database, and Azure Key Vault are continuously updated by Microsoft to support the latest cryptographic standards. As post-quantum algorithms become standardized, these services will incorporate them for the network transport layer (TLS).

That said, “automatic” has limits. Azure will update the TLS stack for managed services, so connections to those services get PQC protection without you doing anything. But if your custom applications pin specific cipher suites, use hardcoded certificate validation, or implement their own cryptographic operations (signing tokens, encrypting data at the application layer), those won’t update themselves. The automatic migration covers the transport layer, not your application logic.

What this means for you:

  • Transport-layer agility: Managed service endpoints will adopt PQC cipher suites as they become available. No manual patching for the network layer.
  • Application-layer responsibility: Custom cryptographic code, hardcoded cipher suites, and application-level encryption need manual review and migration.
  • Defense in depth: Multiple security layers matter more than any single cryptographic choice.

Practical Steps for Azure Customers

While Azure’s services handle much of the heavy lifting, you should still:

  1. Inventory your cryptography usage: Use Azure Policy and Microsoft Defender for Cloud to identify where cryptography is configured in your environment
  2. Review custom applications: Check any custom code that implements cryptography directly
  3. Enable TLS 1.3: Already supported across Azure services and includes more modern cipher suites (use the Azure TLS checker to audit your current state)
  4. Plan for Private Endpoints: Reduce exposure by keeping traffic within Azure’s backbone network
  5. Monitor security recommendations: Microsoft Defender for Cloud will flag outdated cryptographic configurations

But here’s the critical part:

Cryptography has never compensated for bad architecture.

Quantum-safe algorithms won’t work if:

  • Your traffic is out in the open for everyone to see.
  • Your data doesn’t have to leave your device, but it often does.
  • You share information that is too sensitive.

What Actually Makes Sense Today

What I took away from the video is not panic, but preparation:

  • Reduce data exposure wherever possible
  • Prefer private networking over public endpoints (Azure Private Link, VNet integration—the subnet calculator can help plan your address space)
  • Understand where and how cryptography is used in your systems
  • Start inventorying crypto dependencies in custom applications
  • Use Azure Key Vault for all key management (Microsoft manages the quantum-safe migration roadmap)
  • Enable Azure Policy to enforce minimum TLS versions across your subscriptions—see EPAC introduction for managing policies at scale or the broader governance framework

Vendors will take care of most of this for services. The real work is usually in your own code or cloud foundation.

Final Thoughts

Quantum computing will definitely change security.
But the basics stay the same:

  • Defense in depth
  • Minimize attack surface
  • Don’t rely on crypto alone to save you

And if you’re using Azure’s services, you’re already on the right path.

Sources

  1. John Savill, “Quantum-Safe Cryptography Explained,” YouTube, https://www.youtube.com/watch?v=5—yBhgDrXM

  2. Microsoft, “Azure Well-Architected Framework - Security,” Azure Documentation, https://learn.microsoft.com/en-us/azure/well-architected/security/

  3. NIST, “Post-Quantum Cryptography Standards,” NIST Computer Security Resource Center, https://csrc.nist.gov/projects/post-quantum-cryptography

  4. Microsoft, “Azure Key Vault Security Features,” Azure Documentation, https://learn.microsoft.com/en-us/azure/key-vault/general/security-features

  5. Microsoft, “Microsoft Defender for Cloud,” Azure Security Documentation, https://learn.microsoft.com/en-us/azure/defender-for-cloud/