A plain-language guide to the threat model, the standards, and what post-quantum encryption looks like for teams building applications that handle data which has to stay confidential for years or decades.
Most software encrypts data in transit and at rest. The encryption is strong by current standards, and for data with a short sensitivity window — a session token, a payment transaction, a temporary file — that is enough. The data loses its value before anyone could break the encryption.
Long-lived data is different. A healthcare record may stay sensitive for 30 years. A genomic dataset may be relevant for a researcher's entire career. A government contract document may have implications for decades. Intellectual property in AI training data may hold commercial value well past the model's release. For this class of data, the protection has to last as long as the data does.
Today's most widely used asymmetric encryption — RSA and elliptic-curve schemes like X25519 — is secure against classical computers. It is not secure against a sufficiently capable quantum computer. The question is not whether capable quantum hardware will exist, but when, and whether the data you are encrypting today will still need to be confidential at that point.
The threat has a name because it is a real operational tactic. An adversary collects encrypted data today — from network traffic, from breached storage, from data shared across systems — and stores it. They cannot read it now. But they are betting that hardware will improve and that the data will still be valuable when it does.
This is not a theoretical concern. Nation-state adversaries have the storage capacity and the motivation to collect encrypted data in bulk. The highest-value targets are the ones with long-term significance: intelligence, medical research, engineering IP, government operations, financial records that create long-term liability or advantage.
The important operational implication: the encryption you apply at data creation determines the protection you have in the future. A file encrypted with RSA-2048 today that a sufficiently capable quantum computer could break in 2036 was, in retrospect, unprotected. There is no way to re-encrypt data that was already collected. The window to act is when the data is written.
Infrastructure encryption — TLS in transit, at-rest encryption on a storage volume — protects data from passive interception and media theft. It does not protect data from someone with legitimate database access, a compromised credential, or a misconfigured access policy. It also does not help if the harvested data was collected in transit before decryption at the server.
Application-layer encryption adds a different kind of protection. The data is ciphertext before it reaches storage. A breach of the database yields unreadable ciphertext, not plaintext. An adversary who collected the data in transit, where TLS terminated at a load balancer, still only gets ciphertext. The attacker also needs the private key material, which is managed separately from the application.
For long-lived sensitive data, this layer matters particularly because the risk windows are asymmetric. A storage breach might be discovered and contained in days or weeks. A harvest-now collection event might not be acted on for a decade. Application-layer encryption closes the second window because even a future adversary with quantum hardware needs the private key — and private keys can be managed, rotated, and protected independently of the data.
NIST published the first post-quantum cryptography standards in August 2024:
These algorithms are based on mathematical problems believed to be hard for both classical computers and quantum computers — primarily lattice-based constructions (ML-KEM, ML-DSA) and hash-based constructions (SLH-DSA). They are the result of a six-year competition and standardization process run by NIST, with broad cryptographic community review.
The recommended practice for most organizations migrating today is hybrid cryptography: apply classical and post-quantum algorithms together on the same data. If the post-quantum algorithm has an unforeseen weakness, the classical algorithm still protects the data. If the classical algorithm is broken by quantum hardware, the post-quantum algorithm still protects the data. You are never worse off than your current baseline.
CNSA 2.0 (the Commercial National Security Algorithm Suite, version 2) requires post-quantum algorithm adoption for national security systems by 2035. Organizations with federal customers or defense-adjacent work are already in scope for planning and migration timelines.
VellumGuard is a hosted encryption and key-management service that implements hybrid post-quantum cryptography at the application layer. The cryptographic suite:
VellumGuard handles key management: key generation, Cloud KMS-backed wrapping (raw DEKs never touch disk or logs), active key promotion, multi-DEK runtime support, identity key rewrap, and key retirement. The design is client-side encryption — plaintext is never sent to VellumGuard's servers. The SDK encrypts on the application side; the API handles key material and operations.
The ciphertext format is open and versioned, with published reference test vectors. Your encrypted data is decryptable with any conforming implementation — not dependent on VellumGuard's continued operation.
VellumGuard is in controlled beta and design-partner access. The platform is live and the key rotation lifecycle has been executed end-to-end in production. The current limitations are real:
No charges without a written agreement before general availability.
If you are building an application that handles data with a long sensitivity horizon and want to evaluate post-quantum application-layer encryption in a controlled beta, apply for design partner access or email us directly.
Email beta@vellumguard.com · Field Guides · Security model · SDK documentation