Post-Quantum Cryptography in Spring Boot: Four Patterns You Can Ship This Sprint

Key Takeaways

• If you are already on JDK 24, you can start using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) and Module-Lattice-Based Digital Signature Algorithm (ML-DSA) through the standard Java Cryptography Extension (JCE) API with no extra library. The JDK upgrade (JDK 24) you were probably already planning also unblocks your entire post-quantum cryptography (PQC) migration.
• Someone is storing your RSA-wrapped TLS sessions right now to decrypt later, so any customer SSNs, transaction records, and Know Your Customer (KYC) documents flowing between your services today are already at risk. Waiting for PQC TLS to arrive at your cloud provider is not a migration plan.
• Encrypting a database field with a Kyber key is not the hard part; rather, the hard part is making sure that key does not live in your JVM heap, because one server restart or one heap dump undoes every encrypted row in your database. Kay Management Services (KMS) or HashiCorp Vault integration needs to come before anything is deployed to production.
• OAuth2 tokens and service account credentials used by core banking, fraud detection, and regulatory reporting pipelines often live for months or years, making them a higher priority for PQC migration than short-lived customer session tokens.
• Start your PQC migration with the data that lives the longest, not with the authorization layer that feels most familiar, because loan agreements and KYC records signed with RSA today will have forgeable signatures around 2035. Therefore, you cannot go back and re-sign archived documents after the fact.