Post-Quantum Cryptography: What Every Business Needs to Know in 2026

Why Post-Quantum Cryptography Exists

Every secure connection on the internet depends on public-key cryptography. When you connect to a bank, send an encrypted email, sign a software update, or authenticate to a VPN, public-key algorithms handle the key exchange and identity verification. RSA, ECC, and Diffie-Hellman have served this role for decades. They work because the underlying math problems, factoring large numbers and computing discrete logarithms, are infeasible for classical computers to solve.

Quantum computers change that equation. Shor's algorithm, published in 1994, demonstrated that a quantum computer with enough stable qubits can factor large numbers and compute discrete logarithms in polynomial time. In practical terms: RSA-2048 encryption that would take a classical computer millions of years to break could be broken by a sufficiently powerful quantum computer in hours.

No such quantum computer exists today. But progress is accelerating. Google's quantum computing team announced a 2029 PQC migration deadline on March 25, 2026, signaling that they expect cryptographically relevant quantum computers (CRQCs) to arrive within the next few years. IBM, Microsoft, and several nation-state quantum programs are investing billions in qubit count, error correction, and engineering maturity.

Post-quantum cryptography was developed to address this inevitability. Rather than relying on factoring and discrete logarithms, PQC algorithms use mathematical problems believed to be resistant to both classical and quantum attacks: lattice problems, hash-based constructions, code-based cryptography, and multivariate polynomial systems. For a broader view of how quantum computing intersects with organizational security, see our quantum computing cybersecurity guide.

The Three NIST Post-Quantum Standards

After an eight-year evaluation process involving submissions from research teams worldwide, NIST published three PQC standards in August 2024. These are not drafts or proposals. They are finalized Federal Information Processing Standards (FIPS) ready for production adoption.

ML-KEM (FIPS 203): Key Encapsulation

ML-KEM, based on the CRYSTALS-Kyber algorithm, handles key exchange. It replaces the RSA key exchange and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) that protect TLS connections, VPN tunnels, and SSH sessions. ML-KEM is a key encapsulation mechanism (KEM), which means it establishes a shared secret between two parties without transmitting the secret directly.

ML-KEM offers three parameter sets with increasing security levels:

For context, an RSA-2048 public key is 256 bytes and an ECDH P-256 key share is 32 bytes. ML-KEM keys are larger, which means TLS handshakes carry more data. In practice, the performance impact is modest. Google Chrome and Cloudflare have tested hybrid TLS with ML-KEM at internet scale, reporting latency increases of less than one millisecond for most connections.

ML-DSA (FIPS 204): Digital Signatures

ML-DSA, based on CRYSTALS-Dilithium, handles digital signatures. It replaces RSA signatures and ECDSA used in X.509 certificates, code signing, document signing, S/MIME email, and authentication protocols. ML-DSA is the primary general-purpose PQC signature algorithm.

ML-DSA signatures are significantly larger than ECDSA signatures (2,420 bytes for ML-DSA-44 versus 64 bytes for ECDSA P-256). This affects certificate chain sizes, TLS handshake overhead, and CI/CD pipeline bandwidth. Organizations must account for these increases in capacity planning, particularly for PKI infrastructure, OCSP responders, and code distribution systems.

SLH-DSA (FIPS 205): Hash-Based Signatures

SLH-DSA, based on SPHINCS+, provides an alternative signature algorithm using hash-based constructions. Its security depends only on the properties of hash functions, which are well-understood and have decades of cryptanalytic history. This makes SLH-DSA a conservative "insurance policy" against the possibility that lattice-based algorithms face unexpected attacks in the future.

The trade-off is size: SLH-DSA signatures can range from 7,856 to 49,856 bytes depending on the parameter set. This makes it impractical for high-frequency signing (like TLS certificate chains) but well-suited for long-lived, high-assurance artifacts such as firmware images, root certificates, and legal documents.

HQC: The Fourth Algorithm

NIST selected HQC (Hamming Quasi-Cyclic) as an additional KEM based on code-based cryptography. It provides diversity against the possibility that lattice-based problems (underlying ML-KEM) prove weaker than expected. HQC is in the final stages of standardization as of early 2026.

What Breaks and What Stays Secure

Understanding the scope of the quantum threat helps organizations prioritize migration resources. Not everything needs to change.

The practical implication: PQC migration focuses on the public-key layer. Symmetric encryption, hashing, and MACs need minor adjustments at most (upgrading to AES-256 and SHA-384 where not already in use). The heavy lifting is in replacing key exchange and signature algorithms across TLS, PKI, VPNs, code signing, SSH, email encryption, and authentication systems.

The Compliance Timeline Businesses Must Track

PQC migration is not just a technical upgrade. It is a compliance obligation with concrete deadlines. Organizations in regulated industries, government contracting, or handling sensitive data need to map these dates against their migration planning.

• August 2024: NIST published FIPS 203, 204, and 205. PQC standards are finalized and available for adoption.
• December 2025: NIST published CSWP 39 (crypto agility guidance), providing a framework for how organizations should approach PQC migration.
• March 2025: PCI DSS 4.0 mandated cryptographic inventory and migration planning for payment processing systems.
• March 25, 2026: Google announced a 2029 deadline for PQC migration, signaling browser and web ecosystem timeline expectations.
• September 21, 2026: CISA CMVP module transition deadline for cryptographic validation programs.
• January 1, 2027: NSA CNSA 2.0 requires all new National Security System acquisitions to be quantum-resistant. Defense contractors and federal system integrators are directly affected.
• 2030: NSA CNSA 2.0 legacy system phase-out begins. G7 financial sector targeting critical systems quantum-safe by 2030-2032.

For defense contractors operating under CMMC, the CNSA 2.0 timeline creates upstream pressure. Subcontractors and suppliers in the defense industrial base should expect PQC requirements in future CMMC assessment criteria. For healthcare organizations, the proposed HIPAA encryption rule (expected around May 2026) will likely reference PQC-ready encryption as a best practice for protecting electronic protected health information (ePHI).

How Post-Quantum Migration Actually Works

PQC migration is not a one-day cipher swap. It is a multi-year program that touches every layer of an organization's technology stack. The SHA-1 to SHA-2 migration, which involved replacing a single hash algorithm, took the industry over a decade. PQC migration is more complex because it affects key exchange, signatures, authentication, certificates, firmware signing, and stored data protection simultaneously.

Phase 1: Cryptographic Inventory

Before you can migrate anything, you need to know where cryptography lives in your environment. Build a cryptographic bill of materials (CBOM) covering:

• TLS certificates on all internal and external endpoints (web servers, load balancers, API gateways, CDNs)
• VPN configurations and tunnel endpoints
• SSH keys across all servers, CI/CD systems, and development machines
• Code signing certificates and build pipeline signing configurations
• Email encryption (S/MIME, PGP) deployments
• KMS and HSM integrations for data-at-rest encryption
• IoT and OT device certificates and firmware signing chains
• Third-party and SaaS vendor cryptographic dependencies

Automated scanning tools can discover TLS endpoints and certificate details. For deeper inventory (embedded crypto in applications, custom protocols, HSM firmware versions), manual assessment is typically required.

Phase 2: Risk Prioritization

Not all systems need to migrate at the same time. Prioritize by two factors: data confidentiality lifetime and exposure to harvest-now-decrypt-later (HNDL) attacks. Systems protecting data that must remain confidential for 5+ years are highest priority. Internet-facing TLS endpoints where traffic can be intercepted rank above internal-only services.

Phase 3: Hybrid Deployment

Hybrid cryptography combines classical and PQC algorithms in a single operation. For TLS key exchange, this means combining X25519 (classical ECDHE) with ML-KEM (PQC KEM) so the session is secure if either algorithm remains unbroken. Hybrid deployment is the recommended transition strategy because it:

• Provides quantum resistance for the key exchange immediately
• Maintains backward compatibility with clients that do not support PQC
• Reduces risk if a PQC algorithm faces unexpected vulnerabilities during early deployment

Major browsers (Chrome, Firefox, Edge) and CDN providers (Cloudflare, AWS CloudFront) already support hybrid TLS with ML-KEM. Enabling it on your internet-facing endpoints is often a configuration change, not a code rewrite.

Phase 4: PKI and Certificate Migration

Enterprise PKI migration is the most complex phase. Internal certificate authorities must issue PQC-signed certificates. Certificate chains grow larger (ML-DSA public keys and signatures are substantially bigger than ECDSA). OCSP responders, CRL distribution points, and certificate automation (ACME, EST, SCEP) must handle increased object sizes. Many organizations will run parallel classical and PQC certificate hierarchies during the transition.

Phase 5: Code Signing and Supply Chain

Software update chains, container signing, and firmware verification must transition to PQC signatures. Dual-signing (classical + PQC) maintains compatibility during the transition period. Build pipelines, package repositories, and runtime verifiers all need updates. This phase often takes the longest because it depends on platform vendor support (Windows Authenticode, Apple notarization, Android APK signing).

What Post-Quantum Cryptography Costs

PQC migration costs scale with organizational complexity. A useful framework for budgeting:

The cost of not migrating is harder to quantify but potentially catastrophic. If a CRQC breaks RSA before an organization has migrated, every encrypted communication, stored backup, and digitally signed artifact protected by RSA or ECC becomes compromised. The reputational, legal, and regulatory fallout would dwarf any migration budget.

Common Misconceptions About Post-Quantum Cryptography

"Quantum computers are decades away, so we can wait"

Google's March 2026 announcement of a 2029 migration deadline suggests otherwise. More importantly, harvest-now-decrypt-later attacks make the threat immediate for any data with a confidentiality window exceeding 5 years. The question is not when quantum computers arrive; it is whether your data's secrecy outlasts the current encryption protecting it.

"Our cloud provider handles encryption, so we do not need to do anything"

Cloud providers will migrate their managed services on their own timelines, but those timelines vary by service and region. More critically, customer-managed keys, custom applications, VPN configurations, and PKI hierarchies are your responsibility. Waiting for your cloud provider to solve the problem leaves significant gaps.

"AES-256 is quantum-safe, so our data at rest is fine"

AES-256 for bulk encryption is indeed quantum-resistant. But the key wrapping and key exchange mechanisms that protect the AES keys often rely on RSA or ECC. If an adversary can break the key exchange, they recover the symmetric key and decrypt the data. Migrating the key management layer to PQC is essential even when the data encryption itself is symmetric.

"PQC algorithms are too new to trust"

ML-KEM (Kyber) survived eight years of public cryptanalysis during NIST's evaluation process, with contributions from hundreds of researchers worldwide. The mathematical foundations (lattice problems) have been studied for over 25 years. Hybrid deployment further mitigates risk: the connection is secure if either the classical or PQC algorithm holds. This is a belt-and-suspenders approach, not a leap of faith.

How Petronella Technology Group, Inc. Helps with PQC Migration

Petronella Technology Group, Inc. offers quantum readiness assessments tailored for SMBs and mid-market organizations. Our team holds CMMC-RP and CMMC-CCA credentials with deep expertise in compliance-driven security, giving us a unique perspective on how PQC intersects with frameworks like CMMC, HIPAA, and NIST 800-171.

Craig Petronella, founder and principal consultant, brings 24+ years of cybersecurity experience, CMMC-RP and CMMC-CCA certifications, a Licensed Digital Forensic Examiner credential, and 15 published books on information security. This combination of AI-first technology consulting and deep compliance credentials means your PQC migration is planned by someone who understands both the cryptographic engineering and the regulatory landscape.

We serve defense contractors, healthcare organizations, financial services firms, and any business handling sensitive data that must remain confidential beyond the quantum horizon. Whether you need a standalone cryptographic inventory, a full migration roadmap, or ongoing advisory through each migration phase, our team is ready to help.