Infrastructure for Post-Quantum Cryptography and Crypto-Agility

If your organization handles data that needs to stay confidential for years, financial records, health data, intellectual property, there’s a specific reason to start planning for post-quantum cryptography now instead of waiting for quantum computers to actually arrive.

That reason has a name in the security field: harvest now, decrypt later. An adversary doesn’t need a working quantum computer today to benefit from one eventually. They just need to capture your encrypted data now and hold onto it until the decryption capability exists.

Why This Is No Longer A Research Topic

NIST finalized its first set of post-quantum cryptography standards, ML-KEM, ML-DSA, and SLH-DSA, in 2024, and added a backup key-encapsulation method in 2025. That’s the algorithm side settled. The deadline side has moved just as fast. NIST’s transition guidance, IR 8547, sets an expected timeline of deprecating RSA-2048 and ECC P-256 by 2030 and removing quantum-vulnerable algorithms from federal standards entirely by 2035, while the NSA’s CNSA 2.0 guidance mandates PQC for new national security systems on a nearer-term timeline. Confirm IR 8547’s current publication status before citing it as final, since sources vary on exactly where it stands as of mid-2026. None of this is a “someday” problem regardless of that detail. It’s a project with a date attached.

Industry readiness hasn’t caught up to that timeline. DigiCert’s second annual PQC survey, released in July 2026 and covering 1,001 IT and cybersecurity decision-makers across the US, UK, and Australia, found that 87% of organizations report they’re planning, testing, or implementing PQC initiatives, but only 7% have actually deployed quantum-safe or hybrid cryptography across most of their infrastructure, and that figure moved just two percentage points in the year prior.

That gap, near-universal planning against almost no broad deployment, is exactly where harvest-now-decrypt-later makes the case urgent: long-retention data encrypted today, under current algorithms, is already exposed to a future decryption capability, regardless of when your organization actually gets around to migrating.

What Crypto-Agility Actually Means

Crypto-agility is the ability to swap cryptographic algorithms and key management approaches without re-architecting your entire infrastructure every time a standard changes. This isn’t hypothetical for the current transition. Most serious migration guidance recommends hybrid deployments, running classical and post-quantum algorithms side by side, rather than a single cutover, since new standards are still maturing and a hybrid approach limits the blast radius if a specific post-quantum algorithm is later found to have a weakness.

That means your infrastructure needs to support running multiple cryptographic schemes concurrently, managing keys for both, and being able to shift the balance between them as guidance evolves. This is fundamentally an infrastructure and operations question, not just a library upgrade, because it touches how keys are generated, stored, rotated, and audited across your entire stack.

Why This Needs Infrastructure You Actually Control

Crypto-agility is much easier to implement with direct, root-level access to the hardware running your cryptographic operations than inside a fully managed platform where key management is abstracted into a vendor’s proprietary service. If you need to run a hardware security module, integrate a specific PQC library, or manage a hybrid classical-and-post-quantum key hierarchy on your own schedule rather than whenever a managed provider decides to support it, dedicated infrastructure with full root access removes that dependency entirely.

This is the same argument that applies to other confidential-computing workloads: control over the hardware layer means you’re not waiting on someone else’s roadmap for a capability you need on your own timeline. For workloads where key material or cryptographic operations need to be isolated even from the infrastructure provider, Intel TDX confidential computing extends that control further, protecting data and key operations in memory during active processing, not just at rest.

The Data-At-Rest Problem Specifically

Harvest-now-decrypt-later is fundamentally a data-at-rest problem for anything with a multi-year retention requirement. Re-encrypting large volumes of existing data under new algorithms, and doing it incrementally as PQC libraries and hardware support mature, requires storage infrastructure that can be re-encrypted in place without an all-at-once migration event.

A large-scale Ceph storage cluster that you control directly supports this kind of staged re-encryption on your own schedule, rather than being dependent on when a managed storage provider adds support for a given PQC algorithm to their platform.

What This Doesn’t Solve

Post-quantum cryptography is largely a software and algorithm problem, not a hardware-mandatory one the way Intel TDX’s channel-population requirement is. Most of the actual PQC implementation work happens in cryptographic libraries, TLS stacks, and key management software.

What dedicated infrastructure adds is control over how and when you deploy that software, and isolation for the systems managing your keys, not a hardware requirement for PQC itself to function. If your organization is early in evaluating PQC migration, the algorithm and library decisions come first; infrastructure control matters most once you’re actually implementing a hybrid or crypto-agile deployment at scale.

Getting Started

Dedicated bare metal servers and hosted private cloud give you the root access needed to manage HSMs, key hierarchies, and hybrid cryptographic deployments on your own timeline. Current configurations are on our bare metal pricing page and cloud deployment page, and workloads that also need hardware-isolated key operations can pair bare metal with TDX confidential computing.

FAQ

What is harvest now, decrypt later?

It’s the practice of an adversary capturing encrypted data today with the intent to decrypt it once quantum computing capability exists to break current encryption algorithms. It makes data encrypted under today’s standards a future risk if it has a long retention requirement, regardless of how far off a working quantum computer actually is.

Has NIST finalized post-quantum cryptography standards?

Yes. NIST finalized its first three PQC standards, ML-KEM, ML-DSA, and SLH-DSA, in 2024, and added an additional backup key-encapsulation method afterward. The algorithm side of the transition is largely settled; organizational migration is the part still in progress.

Does post-quantum cryptography require special hardware?

Generally no. Most PQC algorithms run in software, in cryptographic libraries and TLS implementations, without a specific hardware mandate. What benefits from dedicated hardware is crypto-agility itself: managing hybrid deployments, HSMs, and key hierarchies with full control rather than waiting on a managed platform’s support timeline.

What does crypto-agility mean in practice?

The ability to run and switch between multiple cryptographic algorithms and key management approaches without re-architecting your infrastructure each time. During the current PQC transition, this commonly means running classical and post-quantum algorithms in hybrid deployments rather than a single abrupt cutover.