Organisations that have deployed hybrid TLS have protected data in transit. They have not protected data at rest in their databases. These are separate threat surfaces, and the assumption that one migration covers both is a planning gap that appears regularly in PQC programme reviews. This article addresses the specific technical structure of application-layer database encryption migration, why the migration is less operationally disruptive than most engineers expect, and where the genuine HNDL exposure concentrates in database environments.

The gap between TLS migration and database security

TLS post-quantum migration, whether hybrid X-Wing (RFC 9496) or full ML-KEM deployment, protects data moving between systems. Application-layer encryption (ALE), sometimes called field-level encryption, client-side encryption, or transparent data encryption (TDE), protects data written to database storage. An adversary who exfiltrates the database files themselves, or more commonly the backup files, is operating outside the TLS layer entirely. The TLS migration is irrelevant to them.

The HNDL threat model applies to database content with particular force. Database backup files are compact, portable, and frequently targeted by sophisticated adversaries for exactly the reasons that make databases valuable in the first place: they contain structured, high-density records of sensitive information. An adversary who harvests backup files today for decryption once a CRQC exists is not intercepting a TLS stream. They are working from files that already exist on backup tapes, in object storage, or in off-site archive systems. The Mosca inequality applies here exactly as it applies to TLS-protected traffic: sum the migration time for the database encryption and the data lifetime. If the sum exceeds the estimated time to a CRQC (approximately 2033 to 2035), migration is urgent. For databases containing personal data subject to storage limitation obligations, health records, or financial records with MiFID retention requirements, many organisations will find the Mosca calculation returns a positive result immediately. [INFERRED: GDPR Article 5(1)(e) establishes the storage limitation principle — that personal data should not be kept longer than necessary — rather than specifying particular retention periods; actual durations are determined by the applicable lawful basis and sector-specific requirements.]

The technical structure of the migration matters for planning. Most ALE and TDE implementations use a three-level key hierarchy. At the base is the data encryption key (DEK): an AES-256 key that encrypts the actual database data. The DEK is wrapped by a key encryption key (KEK), which is stored in an HSM or KMS. The KEK is typically protected by an asymmetric key pair, either RSA or ECDH. Post-quantum migration in this context means replacing the RSA or ECDH protection of the KEK with ML-KEM. The DEK itself, AES-256, does not need to change. The data itself does not need to be re-encrypted. The migration target is the key wrapping layer, not the database content.

How key re-wrapping works: the migration without data re-encryption

This is the point that most often changes a database engineer's assessment of the migration's operational complexity. Re-encrypting petabytes of database data is a months-long infrastructure project. Re-wrapping a key hierarchy is a multi-week key rotation exercise, comparable in operational scope to a standard certificate rotation.

The key re-wrapping operation is: generate a new ML-KEM-protected KEK in the PQC-capable KMS. Decrypt the existing DEK using the current RSA or ECDH KEK. Re-encrypt the DEK under the new ML-KEM KEK. Update the database's reference to the active KEK. Test decryption of a sample of database content. Retire the old RSA or ECDH KEK and revoke its certificate or key handle.

The database data is not touched at any step. The AES-256 key material in the DEK does not change. Only the asymmetric wrapping of the DEK changes. This means the migration window is determined by the key management operations, not by the data volume in the database. A 50 TB database and a 500 GB database have the same key re-wrapping operation once the KMS is PQC-capable.

For the KEM mechanics underlying the ML-KEM key encapsulation operation that replaces the RSA wrapping, see Key Encapsulation Mechanisms: A Guide for Security Architects.

Product-by-product status: CipherTrust, Vault, Always Encrypted, MongoDB CSFLE

The status below reflects publicly available vendor information as of knowledge cutoff August 2025. All vendor status must be verified against current product documentation before deployment planning. Database encryption product development is active and the landscape changes.

The Always Encrypted case is worth examining in detail. The quantum vulnerability is not "Always Encrypted uses RSA." The specific vulnerable component is the RSA-OAEP operation that wraps the column encryption key (CEK) using the column master key (CMK). The CEK protects the column data using AES-256-CBC or AES-256-GCM. The RSA-OAEP wrapping is the exposure. That specificity matters for the migration conversation: the column data itself does not need to be decrypted and re-encrypted; the CMK needs to be replaced with an ML-KEM-capable key type in the KMS.

The MongoDB CSFLE dependency chain is also instructive. MongoDB's driver does not independently control the key wrapping algorithm. The data key is wrapped by whichever KMP the deployment uses. If that KMP is AWS KMS, Azure Key Vault, or GCP KMS and those providers add ML-KEM key wrapping support, CSFLE inherits the post-quantum protection at the key management layer without any MongoDB driver changes. The migration path for CSFLE is determined entirely by the KMP readiness, not by MongoDB.

KMS provider post-quantum readiness: AWS KMS, Azure Key Vault, GCP Cloud KMS

The most operationally important distinction in assessing cloud KMS PQC readiness is between two separate protections that are frequently conflated in vendor communications.

Protection A: post-quantum TLS for the channel to the KMS. This protects the HTTPS connection over which key material requests and responses transit. AWS enabled hybrid post-quantum TLS for its KMS API channel in 2023. Azure and GCP have published equivalent intentions. Protection A is more widely deployed because it only requires a TLS library update; it does not require changes to the HSM firmware or the key operations within the KMS. [ASSUMED: verify current AWS KMS, Azure Key Vault, and GCP KMS channel protection status before publication.]

Protection B: post-quantum protection of the key material stored within the KMS — meaning the key wrapping operations inside the HSM use ML-KEM to wrap DEKs, rather than RSA or ECDH. Protection B requires KMS firmware updates for hardware-backed key stores and is at earlier deployment maturity across providers as of 2025. Standard AWS-managed HSMs (the default AWS KMS multi-tenant path) and a dedicated AWS KMS Custom Key Store backed by a customer-provisioned AWS CloudHSM cluster are distinct configurations with separate roadmaps; the Custom Key Store path, where the customer controls the CloudHSM cluster, is the relevant one for Protection B planning.

• AWS KMS: Channel protection (A) deployed since 2023. For key material protection (B), the relevant path is an AWS KMS Custom Key Store backed by a customer-provisioned AWS CloudHSM cluster — not the default AWS-managed HSM path. CloudHSM firmware updates introducing FIPS 140-3 validated ML-KEM operations are in development. [ASSUMED: verify current AWS KMS Custom Key Store and CloudHSM documentation before planning.]
• Azure Key Vault and Azure Managed HSM: Key Vault supports RSA and EC key types. Azure Managed HSM provides FIPS 140-3 Level 3 validated dedicated hardware key storage. Microsoft has announced ML-KEM key type support for Azure Managed HSM. [ASSUMED: verify specific availability date and supported key operations in current Azure documentation before planning.]
• Google Cloud KMS: Cloud KMS has announced PQC alignment with NIST FIPS 203/204. Hardware and software key backends are on separate timelines. [ASSUMED: verify specific Cloud KMS ML-KEM feature availability by backend type in current Google Cloud documentation before planning.]

When evaluating KMS readiness for a database encryption migration programme, ask the provider two separate questions. First: is the channel to the KMS protected with hybrid ML-KEM TLS? Second: can the KMS wrap data encryption keys using ML-KEM inside the HSM? Most providers will currently answer yes to the first and "in development" to the second. That distinction determines when the key re-wrapping migration can actually begin.

For library selection and implementation decisions related to PQC cryptographic providers, see PQC Vendor Selection: Cryptographic Library Providers.

TDE migration: SQL Server, Oracle, PostgreSQL

Transparent Data Encryption encrypts database files at the storage layer using a two-level key hierarchy: the database encryption key (DEK) is encrypted by a master key or certificate stored in the database or in an external KMS. SQL Server TDE, Oracle Advanced Security TDE, and PostgreSQL via extensions all use this architecture.

For SQL Server TDE, the default configuration stores the master key as a certificate in the Windows Certificate Store, typically using RSA-2048. The quantum-vulnerable component is that certificate. The correct migration path routes through the Extensible Key Management (EKM) provider interface: configure SQL Server to use EKM with Azure Key Vault Connector (the Microsoft-provided EKM provider for Azure Key Vault), generate an ML-KEM-capable asymmetric key in Azure Key Vault Managed HSM, and set that key as the TDE protector. This is the supported integration path — not direct import of a Managed HSM certificate into SQL Server's local certificate store. The SQL Server database files are not decrypted at any step in this process. The DEK protecting the database files remains the same AES-256 key material; only its wrapping changes. [ASSUMED: verify current Azure Key Vault Connector EKM provider documentation for ML-KEM key type support before deployment.]

Oracle Advanced Security TDE uses a wallet-based master key protected by a Hardware Security Module. The migration path follows the same pattern: replace the HSM-held master key with an ML-KEM-protected equivalent, re-wrap the TDE master key under the new protection, rotate. PostgreSQL implementations using pgcrypto or similar extensions have their key management determined by the extension and external KMS configuration.

The principle generalises: for any TDE implementation, identify the asymmetric key protecting the master key, determine whether the HSM or KMS that holds it supports ML-KEM key operations, and plan the key rotation accordingly. The data files are not involved.

Legacy archive risk: where the HNDL exposure is highest

The "no data re-encryption required" conclusion has one important exception that must be addressed explicitly in any database encryption migration programme.

Standard operational databases: the DEK protecting the data is wrapped by a KEK in an HSM or KMS. Once the KEK wrapping is migrated to ML-KEM, the historical data protected by the DEK is no longer at HNDL risk, because an adversary harvesting backup files from this point forward will find a database whose DEK is ML-KEM-wrapped. They cannot use a CRQC to break the key management chain.

Legacy archives: backup files and data archives that were created before the key hierarchy migration, using a DEK that was distributed or protected solely by RSA or ECDH, remain at HNDL risk even after the current system's key hierarchy is migrated. An adversary who harvested those backup files before the migration occurred holds encrypted data whose key wrapping is still RSA or ECDH. The key re-wrapping operation on the live system does not retroactively protect files already in adversarial possession.

For backup files and archives with retention requirements extending into the 2030s, this is a genuine exposure. The mitigation requires: identifying all archive repositories containing data protected by RSA or ECDH key wrapping; decrypting those archives using the original key material (which requires the original RSA or ECDH private key); and re-encrypting them under a new ML-KEM-protected key hierarchy. This is the one scenario in database encryption migration that does require data re-encryption. The Mosca inequality applied to the archive data determines whether this is urgent: seven-year or longer retention requirements combined with any reasonable migration timeline will typically return a positive result.

The five-step migration sequence and the regulatory frame

The five steps below produce specific artefacts, not general activities. Each step has a named output.

1. Database cryptographic inventory. Identify all databases with ALE or TDE enabled. For each: document the DEK algorithm and size; the KEK storage location (Azure Key Vault, AWS KMS, HSM, local certificate store); the asymmetric algorithm protecting the KEK; and the data classification and retention lifetime of the database content. Output: inventory spreadsheet with one row per database system.
2. Mosca inequality assessment. For each database in the inventory, calculate T_migration + T_data_lifetime against the CRQC window. Tier the results: Tier 1 (migrate within 18 months), Tier 2 (migrate within 36 months), Tier 3 (standard refresh cycle). Output: Mosca assessment with tier classification per database system.
3. KMS and HSM readiness confirmation. For each database, confirm whether the KMS or HSM holding the KEK currently supports ML-KEM key operations (not just ML-KEM TLS channel protection). If not, document the provider's roadmap and whether migration to a PQC-capable KMS is required before the key hierarchy migration can proceed. Output: KMS readiness register with yes/no/roadmap per provider.
4. Key hierarchy migration. For each Tier 1 and Tier 2 database, once the KMS is PQC-capable: generate a new ML-KEM-protected KEK, re-wrap the existing DEK under the new KEK, update the database's active key reference, test decryption, and retire the old RSA or ECDH KEK. Output: key rotation log per database system, signed off by the database owner and the KMS administrator.
5. Legacy archive review. Identify all backup files and data archives with retention requirements extending beyond 2030, where the DEK was distributed under RSA or ECDH wrapping before the key hierarchy migration. Assess whether those archives are in external storage locations accessible to a sophisticated adversary. For archives meeting the HNDL exposure criteria, plan and execute data re-encryption under the new ML-KEM key hierarchy. Output: archive review report with re-encryption scope and completion dates.

The regulatory frame for this migration is not advisory. GDPR Article 32 requires "appropriate technical measures to ensure a level of security appropriate to the risk," including encryption of personal data. Recital 83 identifies encryption as a measure that renders personal data unintelligible to unauthorised persons. An organisation whose database encryption uses RSA or ECDH key wrapping for data with confidentiality requirements extending into the CRQC window cannot demonstrate that its encryption provides security appropriate to the quantifiable HNDL risk. The Mosca inequality is the risk quantification tool; GDPR Article 32 is the legal obligation it must inform.

NIS 2 Directive (EU) 2022/2555, Article 21(2)(h), requires covered essential and important entities across 18 sectors to implement "the use of cryptography and, where appropriate, encryption." For entities subject to NIS 2, database encryption migration is not a best-practice recommendation. It is a component of the Article 21(2)(h) compliance obligation. For financial entities additionally subject to DORA, Article 9(2) and RTS (EU) 2024/1774 Article 6 create the equivalent obligation. UK organisations operate under UK GDPR (Data Protection Act 2018) and the NIS Regulations 2018 (SI 2018/506); the EU GDPR Article 32 and NIS 2 Article 21(2)(h) obligations described here have UK equivalents under those instruments, but the underlying legal texts differ and UK organisations should verify compliance against the domestic legislation. The migration is not optional for covered entities with data retention requirements extending into the 2030s.