Quantum-Safe Cryptography

Enterprise security depends on two kinds of cryptography, and quantum computing threatens them unequally.

Asymmetric cryptography is the exposed flank

RSA, Diffie-Hellman, and elliptic-curve cryptography (ECC) secure key exchange, digital signatures, and certificates. Their security rests on the difficulty of integer factorization and discrete logarithms — problems a sufficiently large, error-corrected quantum computer solves efficiently using Shor's algorithm. When that machine exists, RSA-2048 and ECC-256 offer no protection.

Symmetric cryptography is weakened, not broken

AES and SHA-2 face Grover's algorithm, which provides only a quadratic speedup. The practical mitigation is straightforward: double key lengths. AES-256 remains secure against known quantum attacks, and SHA-384 or SHA-512 preserve hashing strength.

The cryptographically relevant quantum computer (CRQC)

Security planning centers on the CRQC — a machine capable of breaking real-world key sizes. Expert estimates vary widely, and no one can name a date. That uncertainty is precisely the problem: migration must be complete before the CRQC arrives, not started when it does.

The relevant question is not "when will quantum computers break RSA?" but "how long must my data stay confidential, and how long will migration take?" If the sum exceeds the time until a CRQC, you are already exposed.

The most urgent quantum risk requires no quantum computer today. It only requires patience.

How the attack works

Nation-state and well-resourced adversaries capture encrypted data now — intercepted network traffic, stolen encrypted databases, exfiltrated backups — and store it. When a CRQC becomes available, they decrypt the archive retroactively. The encryption that looked strong at capture time provides no protection against future decryption.

Which data is at risk

The threat applies to any secret whose value persists. Consider:

• State secrets and intelligence, classified for decades.
• Health records and genomic data, which remain sensitive for a lifetime.
• Financial and legal records, trade secrets, and intellectual property.
• Long-lived credentials and root keys that anchor trust across an organization.

The Mosca inequality

Cryptographer Michele Mosca framed the risk simply: if the time your data must remain secure, plus the time needed to migrate your systems, is greater than the time until a CRQC exists, you must act now. For most enterprises the migration term alone spans several years, which collapses any comfortable margin. GuardsArm helps organizations quantify these three variables against their own data classification and system inventory.

After a multi-year global competition, NIST published the first finalized PQC standards in 2024, ending the ambiguity about which algorithms to adopt.

The three finalized standards

• FIPS 203 — ML-KEM (derived from CRYSTALS-Kyber): a key-encapsulation mechanism for establishing shared secrets, the general-purpose replacement for classical key exchange.
• FIPS 204 — ML-DSA (derived from CRYSTALS-Dilithium): the primary lattice-based digital signature scheme for authentication and integrity.
• FIPS 205 — SLH-DSA (derived from SPHINCS+): a stateless hash-based signature scheme, valued as a conservative backup whose security rests on well-understood hash assumptions rather than lattice problems.

Why more than one signature scheme

NIST deliberately standardized signatures on different mathematical foundations. If a weakness is later found in lattice cryptography, SLH-DSA provides an independent fallback. This diversity is a feature, not redundancy.

Practical trade-offs

PQC algorithms differ from their classical counterparts in ways that affect systems: larger key and signature sizes, different performance profiles, and bigger handshake payloads. These do not prevent adoption, but they surface in constrained environments — embedded devices, high-volume TLS termination, and protocols with tight message-size limits — which is why testing precedes production rollout.

Standardization removes the excuse to wait. The algorithms are final, vetted, and available in mainstream cryptographic libraries.

You cannot migrate cryptography you cannot see. The foundation of any PQC program is a complete inventory of where and how cryptography is used — often called a cryptographic bill of materials (CBOM).

What to inventory

• Protocols and services: TLS endpoints, VPNs, SSH, email encryption, and their negotiated cipher suites.
• Certificates and PKI: every certificate authority, certificate, and the algorithms and key sizes behind them.
• Code signing and firmware: signing keys for software, updates, and device firmware — often long-lived and high-impact.
• Data at rest: encrypted databases, backups, and archives, noting their retention requirements.
• Embedded and third-party cryptography: hardware security modules, IoT devices, and cryptography buried inside vendor products.

Discovery is harder than it sounds

Cryptography hides in application code, configuration files, hardware appliances, and supplier dependencies. Automated discovery tools and network scanning surface much of it, but manual review of critical systems and vendor attestation fill the gaps.

Turning inventory into priorities

Each inventoried use of cryptography should be tagged with its data sensitivity, retention period, and exposure. This transforms a flat list into a risk-ranked migration backlog — the deliverable that drives every subsequent decision. GuardsArm's assessment engagements typically begin by producing exactly this artifact.

The single most valuable capability an enterprise can build is not a specific algorithm — it is the ability to change algorithms quickly. This is crypto-agility.

Why agility matters more than any one algorithm

PQC standards are new. Implementations will contain bugs, and cryptographic assumptions may shift. An organization that has hard-coded algorithms into applications faces a painful rebuild every time guidance changes. One that abstracts cryptography behind well-defined interfaces can swap primitives with configuration changes.

Designing for agility

• Isolate cryptographic operations behind internal libraries and APIs rather than scattering primitives through application code.
• Negotiate algorithms dynamically rather than pinning them.
• Centralize certificate and key management so rotation is routine, not exceptional.
• Version cryptographic policy so changes are auditable and reversible.

Hybrid mode as a bridge

Most early PQC deployments use hybrid schemes that combine a classical algorithm (such as ECDH) with a post-quantum one (such as ML-KEM). A session is secure unless both are broken. This hedges against undiscovered flaws in the young PQC implementations while delivering quantum resistance today. Major browsers and cloud providers have already enabled hybrid key exchange in TLS.

Adopt hybrid first. It provides quantum protection now without betting everything on the maturity of brand-new algorithms.

Post-quantum migration is a program measured in years, sequenced to protect the most exposed data first.

Phase 1 — Prepare and inventory

Establish executive sponsorship, build the cryptographic inventory, and classify data by retention and sensitivity. Immediately raise symmetric strength to AES-256 and SHA-384/512 where feasible — a low-cost, high-value quick win.

Phase 2 — Prioritize and pilot

Rank systems by the harvest-now, decrypt-later risk: long-lived confidential data and high-value signing keys go first. Pilot hybrid key exchange on non-critical services to validate performance, interoperability, and message-size impacts.

Phase 3 — Migrate high-priority systems

Roll out PQC to prioritized surfaces: external-facing TLS, VPNs, PKI, and code signing. Update certificate authorities to issue PQC-capable certificates and coordinate with vendors on their migration timelines.

Phase 4 — Broaden and sustain

Extend to remaining systems, embedded devices, and third-party dependencies. Institutionalize crypto-agility so future algorithm changes are routine.

Engage the supply chain

Much enterprise cryptography lives in purchased products. Add PQC-readiness questions to procurement and vendor risk reviews now, so suppliers align to your timeline rather than dictating it.

Every phase should end with a measurable milestone — inventory completeness, percentage of traffic on hybrid key exchange, high-priority certificates re-issued — not just activity.