up:: Migration Architecture MOC

PQC for Databases and Data-at-Rest Key Wrapping

PQC for databases is the work of making a database estate quantum-safe, and it turns out to be mostly a key-wrapping and connection problem rather than a bulk re-encryption problem, because databases encrypt stored data with symmetric algorithms like AES-256 that survive quantum computers. The two surfaces that actually carry quantum exposure are the public-key layer that wraps and delivers the symmetric data-encryption keys (the envelope-encryption hierarchy that a KMS or HSM anchors) and the TLS channel that carries client connections to the database (the harvestable link where queries and result sets cross the wire).

So a database migration divides into two clean jobs: rotate the wrapping keys onto post-quantum protection in the key hierarchy, and move client-to-database TLS onto a hybrid post-quantum handshake. The stored ciphertext itself, in most designs, never has to be touched.

The short version:

1. Databases bulk-encrypt stored data with symmetric algorithms like AES-256, which survive quantum computers, so the archived data itself usually needs no re-encryption. This is the same reassurance as Re-Encrypting Data at Rest for PQC, applied to databases.
2. The quantum-vulnerable layer is the envelope-encryption hierarchy: a symmetric data-encryption key (DEK) protects the data, and a key-encryption key (KEK), often a public-key or KMS-anchored key, wraps the DEK. Shor’s algorithm breaks the public-key part of that wrapping.
3. Transparent data encryption (TDE) is the at-rest surface, where the fix is rotating the key-hierarchy and re-wrapping DEKs under quantum-safe protection rather than decrypting and re-encrypting tables.
4. TLS-to-database is the in-motion surface, the harvestable channel a client uses to reach the database, and it migrates by enabling a hybrid post-quantum handshake exactly like any other TLS connection.
5. The whole plan starts from discovery of which databases use which key hierarchy and which permit weak or classical-only client TLS, captured in the inventory.

Picture a vault of safe-deposit boxes. Each box is sealed with a heavy combination lock that a quantum computer can’t crack (the symmetric data-encryption key). All those combinations are written on a card kept inside one master safe, and that master safe uses the old kind of lock a quantum computer can open (the public-key wrapping). Someone who cracks the master safe gets every combination card and therefore every box.

Fixing the vault doesn’t mean re-sealing thousands of boxes. It means replacing the lock on the master safe and re-writing the cards, which is key rotation. And separately, the courier who carries a combination card from the vault to a customer walks an open street where anyone can photograph the card in transit, which is the TLS-to-database channel that needs its own protection.

What is envelope encryption, and where does the quantum exposure live?

Envelope encryption is the standard pattern databases and storage systems use to protect data at rest, where a symmetric data-encryption key encrypts the data and a separate key-encryption key encrypts (wraps) the data-encryption key, so you protect a lot of data with a small, tightly-guarded key at the top. The layers, and which one a quantum computer threatens:

1. The data-encryption key (DEK). A symmetric key, almost always AES, that actually encrypts the table, the file, or the block. It’s the workhorse, and it does the bulk cryptographic work. Because it’s symmetric, Grover’s algorithm only weakens it by a square-root factor, so an AES-256 DEK keeps roughly 128 bits of effective strength against a quantum attacker and survives.
2. The key-encryption key (KEK). The key that wraps the DEK, held in a key-management service or an HSM and never handed out in plaintext. In many designs the KEK layer, or the operation that delivers a DEK to a client, involves public-key cryptography (RSA key transport, ECDH), and that public-key operation is exactly what Shor’s algorithm breaks.

So the exposure sits in the wrapping, not the data. A KMS builds a hierarchy: a top key protects key-encryption keys, which wrap the data keys, which encrypt the data. AWS KMS describes exactly this, generating data keys under a KMS key so the data key is returned both in plaintext (to encrypt locally) and as ciphertext wrapped under the KMS key (to store alongside the data), and its own HSM-backed key hierarchy uses AES-256 domain and backing keys with RSA or elliptic-curve key material in the mix.

Source: AWS, “AWS Key Management Service concepts, envelope encryption and data keys,” docs.aws.amazon.com; the key-hierarchy layering (key-encryption keys wrapping data keys) follows NIST SP 800-57 Part 1 Rev. 5, §5 and §6, May 2020, SP 800-57.

The practical read is that a database migration is a key-hierarchy migration. You harden the top of the envelope so the wrapping survives a quantum computer, and the symmetric data underneath rides along unchanged.

Why doesn’t the stored data need re-encrypting?

Because the bulk encryption is symmetric and symmetric cryptography survives the quantum era with a larger key, which databases already use. AES-256 under Grover’s algorithm drops to roughly 128 bits of effective security, which is still far above any practical attack threshold, so the tables, indexes, and backups a database wrote under AES don’t have to be decrypted and rewritten. NIST’s own position is that sufficiently long symmetric keys remain secure against quantum attack, which is why symmetric encryption and hashing sit in the “monitor, strengthen in place” lane rather than the “replace” lane.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, NISTIR 8105; AES-256 is standardized in FIPS 197, FIPS 197, and its security strengths are tabulated in NIST SP 800-57 Part 1 Rev. 5, SP 800-57.

The one exception worth naming is data that must stay confidential for a very long time and was exposed through a quantum-vulnerable channel or wrapping while in transit or at delivery. That’s a harvest-now-decrypt-later question about the transport and the wrapping, not about the AES ciphertext sitting in the file, and it’s handled by fixing the channel and rotating the wrapping keys ahead of the exposure, covered in depth in Re-Encrypting Data at Rest for PQC.

How does transparent data encryption (TDE) migrate to PQC?

Transparent data encryption is the database feature that encrypts data files, logs, and backups at rest automatically, and it migrates by rotating its key hierarchy onto quantum-safe wrapping rather than by re-encrypting the tables. TDE already uses the envelope pattern internally: a symmetric key encrypts the database files (the equivalent of the DEK, called a database encryption key or table key depending on the product), and that key is protected by a master or wrapping key held in a keystore, a KMS, or an HSM.

The migration moves in the same order for every major TDE implementation:

1. Keep the symmetric file encryption. The AES encryption of the data files stays, because it survives quantum. This is what spares you the multi-terabyte re-encryption.
2. Harden the wrapping key. Move the master or wrapping key onto quantum-safe protection in the key hierarchy, so the operation that unwraps the file-encryption key isn’t gated by a quantum-vulnerable public-key step. Where the wrapping key lives in an HSM or KMS, this is a firmware-and-capability question for that device.
3. Rotate the keys through the existing machinery. TDE products support key rotation as a routine operation, so re-wrapping the file-encryption keys under the new top key is a rotation, not a rebuild, which is the same move Re-Encrypting Data at Rest for PQC describes for storage generally.

The honest scope, then, is that TDE migration is a key-management exercise. The friction is in the key hierarchy and the hardware that anchors it, which is why the HSM and KMS firmware timeline is the real constraint, and why databases whose keystores can’t yet accept post-quantum wrapping become a vendor-dependency line in the plan.

Why is the database connection (TLS) the harvestable surface?

Because the client-to-database connection is a live TLS channel carrying queries and result sets, and that traffic can be recorded today and decrypted later once a quantum computer exists, which is the harvest-now-decrypt-later problem applied to database traffic. The data sitting in the tables is protected by symmetric encryption that survives, but the data crossing the wire between an application and the database is protected by a TLS handshake whose key exchange is classical ECDH by default, and that key exchange is harvestable.

This makes database TLS the higher-urgency of the two surfaces, and it migrates exactly like any other TLS connection:

1. Enable a hybrid post-quantum handshake. Move the client-to-database TLS onto a hybrid key exchange like X25519MLKEM768, so the session key holds even against a future quantum computer, closing the harvesting window on new connections. The mechanics are identical to those in TLS 1.3 Hybrid Key Exchange.
2. Cover every hop. A connection often passes through a connection pooler, a proxy, or a load balancer before it reaches the database, and the rule that a protocol is only as quantum-safe as its weakest endpoint holds here too, so every hop on the path has to negotiate the hybrid handshake.
3. Confirm the negotiated group, don’t assume it. The database driver and server both have to support and actually select the hybrid group, and a connection can silently fall back to classical, so verification on the wire is a distinct step from enabling it, exactly as testing requires.

The reason this matters more than the at-rest surface for many estates is timing. Stored ciphertext is safe as long as its wrapping keys are rotated before a quantum computer arrives, but any sensitive query result harvested off an un-migrated database connection today is already a future liability, so the connection is the piece to move first.

What does a good database PQC posture look like?

A good posture treats the two surfaces separately, sequences the harvestable one first, and drives both from a real inventory rather than a blanket project. The table lays out the two surfaces, what actually changes, and why.

Surface	What’s quantum-vulnerable	The fix	Urgency
Client-to-database TLS connection	Classical ECDH key exchange in the handshake, harvestable today	Enable a hybrid handshake (X25519MLKEM768) across every hop	High, because it’s harvestable now
TDE key wrapping (envelope)	The public-key or KMS operation that wraps the symmetric data key, breakable by Shor’s algorithm	Rotate the key hierarchy and re-wrap DEKs under quantum-safe protection	Deliberate, gated by HSM / KMS firmware
The stored data itself (AES ciphertext)	Nothing, symmetric encryption survives quantum with a large key	No change, it rides along unchanged	Monitor only

The maturity ladder is the same shape as the wider migration: a database estate that can rotate its wrapping keys and renegotiate its client TLS through configuration is quantum-ready, and one hard-wired to a single key hierarchy or a classical-only TLS setup has to be re-architected first, which is the crypto-agility question landing on the data layer.

How does this fit the rest of the migration?

It slots into the discovery-first sequence the whole migration follows. You can’t plan a database migration without knowing which databases use TDE, which key hierarchy anchors each one, and which permit weak or classical-only client TLS, so it starts with discovery and lands in the CBOM. From there the two surfaces sequence differently: the harvestable client TLS moves onto the protocol migration track with the rest of the estate’s TLS, and the at-rest key wrapping moves onto the key-management and HSM track, gated by hardware firmware.

The Re-Encrypting Data at Rest for PQC note carries the general storage version of the same reasoning, and this note is its database-specific application: same envelope model, same “fix the wrapping, not the data” conclusion, with the added TLS-to-database surface that a database estate carries and a pure file archive does not.

Common misconceptions

1. “We have to re-encrypt the whole database for quantum.” Almost never. The tables are encrypted with symmetric AES-256 that survives quantum, so the work is rotating the wrapping keys and moving the client connection to a hybrid handshake, not decrypting and rewriting the data.
2. “TDE makes the database quantum-safe.” TDE protects the data at rest with symmetric encryption, which does survive, but the key that wraps the data key and the TLS connection into the database are the quantum-vulnerable parts, and TDE alone addresses neither.
3. “The stored data is the urgent surface.” The connection is. Stored ciphertext is safe while its wrapping keys are rotated in time, but a query result harvested off an un-migrated database TLS channel today is already exposed under harvest-now-decrypt-later.
4. “The DEK is what’s vulnerable to quantum.” The data-encryption key is symmetric and survives. The key-encryption key layer, where a public-key or KMS operation wraps the DEK, is the part Shor’s algorithm threatens.
5. “Enabling PQC on the database is one setting.” It’s two independent jobs on two surfaces, the client TLS handshake and the at-rest key wrapping, each gated by different dependencies, one on driver and proxy support and one on HSM or KMS firmware.

Questions people ask

Do I have to re-encrypt my database for post-quantum? Usually not. The data is bulk-encrypted with symmetric AES-256 that survives quantum, so the migration is rotating the key hierarchy that wraps the data keys and moving the client-to-database TLS onto a hybrid handshake, which is the same conclusion as Re-Encrypting Data at Rest for PQC.

What’s the difference between a DEK and a KEK? A data-encryption key (DEK) is the symmetric key that actually encrypts the data, and a key-encryption key (KEK) is the key that wraps the DEK so you can store it safely alongside the data. The DEK is symmetric and survives quantum; the KEK layer often uses public-key cryptography and is the part that has to migrate.

Is transparent data encryption enough for quantum safety? No. TDE encrypts the data files with symmetric encryption that survives, but its wrapping key and the database’s client TLS connection are the quantum-vulnerable surfaces, so TDE is the starting point rather than the finish line.

Which database surface do I fix first? The client-to-database TLS connection, because it’s harvestable today. The at-rest key wrapping is important but moves on a more deliberate track, gated by the HSM or KMS that anchors the keys.

What blocks the at-rest migration? The HSM or KMS firmware. Re-wrapping data keys under quantum-safe protection depends on the hardware or service that holds the wrapping key supporting post-quantum algorithms, so a keystore that can’t yet accept post-quantum wrapping becomes a vendor-dependency line in the plan.

Does my cloud provider handle database PQC automatically? Partly, and you have to verify it. Managed database and KMS services move on the provider’s schedule, so the migration for those surfaces is a vendor dependency you track, while the client-side TLS and driver configuration is usually yours to set. Confirm both against the provider’s primary documentation rather than assuming.

How do I find which databases need this? Through discovery, the same as the rest of the estate. You inventory which databases use TDE, which key hierarchy each depends on, and which permit weak or classical-only client TLS, and you record it in the CBOM so the migration is sequenced against evidence rather than a guess.

---

Everything here is the map, given freely. When your team needs its database estate inventoried, its client connections moved onto a hybrid handshake, and its key hierarchies rotated onto quantum-safe wrapping without a needless re-encryption project, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.