Diagram showing increasing post-quantum exposure windows from a TLS connection measured in seconds, to a primary database's TDE keys measured in years, to an offsite backup or DR replica measured in decades of retention

Most database teams that have started post-quantum planning have looked at their live connections and their primary encryption keys. Almost none have looked at their backups. That’s backwards: a database backup is the single longest-lived, most-copied artifact in the entire data lifecycle, and the software that protects it — Veeam, Commvault, Rubrik, and the rest of the backup and disaster-recovery stack — has only just started shipping post-quantum cryptography, years behind TLS libraries and cloud key management services. If harvest-now-decrypt-later is a race against retention time, your backups are already losing it.

What’s actually happening

Post-quantum cryptography (PQC) has rolled out unevenly across the stack, and backup and disaster-recovery (DR) software has been at the back of the queue. NIST finalized its first three PQC standards — ML-KEM for key exchange (FIPS 203), ML-DSA for digital signatures (FIPS 204), and SLH-DSA as a hash-based signature backup (FIPS 205) — in August 2024. Cloud providers began adding hybrid post-quantum TLS support to their KMS and networking layers through 2025. Backup platforms are only catching up now: Veeam shipped hybrid FIPS-plus-PQC support for handshake and key exchange in Backup & Replication 13.1, introduced at VeeamON in mid-2026, covering the transport paths used for replication and offsite copy jobs while leaving data-at-rest encryption on FIPS-certified AES (Veeam). That’s a meaningful step, and notably a recent one — which is exactly the point. If the vendor whose entire job is protecting your backup copies only started this work in 2026, the backups you made last year, and the ones you’ll make next month before you’ve evaluated whether to enable the new capability, are moving through the same classical key-exchange paths they always have.

The exposure math is different for backups than for anything else in a database environment. A live TLS connection is vulnerable for the duration of the session — seconds to hours. A primary database’s transparent data encryption (TDE) key is vulnerable until the next key rotation — typically months to a few years. A backup or DR replica is vulnerable for its entire retention period, which for regulated data commonly runs 7, 10, or 30-plus years, and backups also travel further: replicated to a secondary site, copied to cloud object storage for offsite retention, occasionally exported to tape or a third-party archive vendor for long-term compliance holds. Each hop is a copy an adversary only needs to intercept or exfiltrate once. Harvest-now-decrypt-later doesn’t require breaking your live production database — a stolen backup file sitting in cold storage is a static, patient target that never needs to be touched again until the decryption capability exists.

Recent research has also sharpened how seriously to take the “later” half of that equation. Multiple papers published between 2025 and early 2026 have pushed down the estimated quantum resource requirements for breaking RSA-2048, and while a cryptographically relevant quantum computer doesn’t exist yet, most serious estimates still see meaningful uncertainty in exactly when one will — which is precisely the kind of uncertainty that makes long-retention data the highest-priority category to protect first, since you don’t get to renegotiate the exposure window after the fact.

Who this affects

Backup and DR administrators are the ones who actually configure replication jobs, offsite copy targets, and archive tiers — and in most organizations, backup key management has historically been treated as a “set it once” task, not something revisited as cryptographic standards evolve. They’re also the ones who’ll need to evaluate and enable new PQC options as backup vendors ship them, rather than waiting for a default that may not arrive for years.

Database administrators and platform engineers need to stop treating “our database is encrypted” as a single fact. A database can have strong TDE with a recent key rotation and still ship every backup through a replication path using classical key exchange — the two aren’t the same control, and an audit that only checks the primary database’s encryption configuration will miss the backup path entirely.

CISOs and compliance leads own the crypto inventory that regulators and boards will eventually ask about, and that inventory is incomplete if it stops at production systems. Backup and archive copies of regulated data — health records, financial data, anything under a multi-decade retention mandate — carry the same confidentiality requirement as the source system, on a longer clock.

Procurement and vendor-risk teams need to add a specific question to every backup and DR vendor conversation: not “are you PQC-ready” in general, but which specific paths — replication transport, offsite copy, archive tier, key management integration — have shipped hybrid post-quantum support, and on what release and timeline. Vague affirmative answers to a vague question aren’t useful for a risk register.

When this becomes a real problem

This isn’t a 2030s-only concern, but it isn’t a five-alarm fire this week either — calibrate accordingly. The mechanics are already in motion: backup vendors are shipping PQC support in 2026, incrementally and unevenly, which means most organizations’ backup estates today are still moving entirely through classical cryptography regardless of what the vendor’s latest release supports, because upgrading a backup platform version and actually enabling a new crypto mode are two separate projects with two separate timelines. The federal government’s post-quantum deadline — key establishment migrated by December 31, 2030, per the June 2026 executive order — sets a hard external date for organizations with federal contracts or federal-adjacent compliance obligations, but the retention-length math applies regardless of that deadline: any backup made today of data that must stay confidential past roughly 2035-2040 is already accumulating exposure time it can’t get back, independent of when a quantum computer capable of the attack actually arrives. The realistic planning horizon is: start the inventory and vendor-readiness assessment now (this can be done in weeks), plan the migration for 2026-2028 as vendors mature their offerings, and treat any backup platform still on classical-only crypto by 2029 as a compliance gap for long-retention data.

How this actually plays out in a database environment

Walk through a typical setup: a production SQL Server or PostgreSQL instance with TDE enabled, replicating transaction log backups to a secondary DR site every 15 minutes, with nightly full backups copied to cloud object storage and a monthly archive copy pushed to a third-party long-term retention vendor for compliance. Four distinct transport and storage legs, each currently likely secured with classical TLS and classical encryption-at-rest, each potentially on a different vendor’s PQC roadmap:

The log-shipping replication path to the DR site typically uses the database engine’s own encrypted connection or the backup software’s transport encryption — whichever it is, it’s worth confirming explicitly rather than assuming, because “the connection is encrypted” doesn’t specify with what.

The cloud object storage copy depends on the cloud provider’s server-side encryption and the TLS used to upload it — which may already have hybrid PQC available at the transport layer (several providers added this in 2025), but the object’s at-rest key-wrapping may still be classical, an important-but-often-missed distinction covered in more depth in this series’ cloud KMS post.

The third-party archive vendor is the least visible and often least scrutinized leg — a compliance-driven relationship where “they handle encryption” is frequently accepted without asking which algorithms, and where the data may sit for the longest of any of the four legs.

The backup software’s own management plane — the console, the catalog database, the credentials used to orchestrate all of the above — is itself a database, and its own security posture matters as much as the workloads it protects.

None of these four legs necessarily has the same PQC readiness timeline, and a team that’s inventoried only the production database’s TDE configuration has visibility into roughly one-quarter of the actual exposure surface.

Actions to take now

  1. Add backup and DR paths explicitly to your crypto inventory. If your PQC inventory currently lists only production database encryption, it’s incomplete. List every backup, replication, and archive leg separately, with its own algorithm and vendor.
  2. Ask your backup and DR vendor a specific question, not a general one. Not “are you PQC-ready” — ask which release introduced hybrid post-quantum support, which specific transport paths it covers (replication, offsite copy, cloud upload), and what remains classical-only today.
  3. Identify your longest-retention backup category first. Data under 10-plus-year retention mandates — health, financial, legal, government contract data — is where exposure time compounds fastest. Prioritize its backup and archive paths ahead of shorter-retention operational backups.
  4. Separate the third-party archive question from the internal backup question. Get an explicit answer from any tape or long-term archive vendor about their encryption and key-management approach; don’t accept “we handle that” without specifics.
  5. Pilot the new PQC options as vendors ship them, starting with your DR replication path. Veeam’s 13.1 hybrid mode is a concrete example available now — evaluate it (or your vendor’s equivalent) in a non-production environment before committing to a rollout timeline.
  6. Treat backup key management as a recurring review, not a one-time setup. Put backup and archive crypto configuration on the same review cadence as your production database’s key rotation policy, not a separate and less frequent one.
  7. Build the migration plan around retention length, not around the 2030 federal deadline alone. A federal contractor’s compliance clock and a backup’s actual confidentiality requirement are two different timelines — plan to the longer of the two for any given dataset.

Key takeaways

  • Backup and DR platforms only began shipping hybrid post-quantum cryptography in 2026, well behind TLS libraries and cloud KMS layers.
  • A database backup’s exposure window is its full retention period — often 10 to 30-plus years — far longer than a live connection or even a primary encryption key’s rotation cycle.
  • Most crypto inventories stop at the production database and miss replication, offsite copy, and third-party archive paths entirely.
  • Prioritize the longest-retention backup categories first; that’s where unprotected exposure time compounds fastest.
  • The 2030 federal PQC deadline is one forcing function, but backup retention math can require action on a similar or tighter timeline regardless of contractual obligations.

Auditing every backup and replication path for post-quantum exposure isn’t a project most teams have staffed for. Get in touch if your database’s backup and DR estate needs a crypto-agility assessment.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.