- A STRIDE-based risk assessment across nine cloud architectural layers reveals quantum vulnerabilities from networking to application level — most enterprises have assessed zero of them
- Cloud migration to post-quantum cryptography (PQC) follows three distinct transition phases, each introducing unique attack surfaces including side-channel vulnerabilities in PQC implementations themselves
- AWS, Azure, and GCP are already building quantum-safe strategies — organizations that delay risk assessment beyond 2027 face compounding migration costs and harvest-now-decrypt-later exposure
Why Your Cloud Infrastructure Is Already Under Quantum Threat
Every encrypted data packet your organization sends through AWS, Azure, or GCP today can be captured, stored, and decrypted once a cryptographically relevant quantum computer comes online. This harvest-now-decrypt-later (HNDL) attack vector means the threat window isn’t theoretical — it opened years ago.
A comprehensive security analysis published as arXiv:2509.15653v4 maps quantum threats across the full cloud computing stack, from networking protocols to application-layer encryption. The research identifies vulnerabilities spanning nine architectural layers: application, data, runtime, middleware, operating system, virtualization, server, storage, and networking. Each layer relies on classical cryptographic primitives — RSA, ECC, AES key exchange — that quantum algorithms like Shor’s and Grover’s will compromise.
For CISOs managing multi-cloud deployments, the attack surface isn’t a single endpoint. It’s every TLS handshake, every encrypted database connection, every signed API call across your entire distributed infrastructure.
The Nine-Layer Quantum Risk Model: A Technical Breakdown
Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to resist attacks from both classical and quantum computers. Unlike quantum key distribution (QKD), which requires specialized hardware, PQC algorithms run on existing infrastructure — making them the practical migration path for cloud environments.
The research framework applies STRIDE threat modeling — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — aligned with NIST SP 800-30 risk assessment methodology to evaluate quantum threats at each cloud layer.
Layer-by-Layer Exposure
| Cloud Layer | Primary Quantum Risk | STRIDE Category | Migration Priority |
|---|---|---|---|
| Networking | TLS/IPsec key exchange broken by Shor’s algorithm | Information Disclosure, Tampering | Critical — data in transit exposed first |
| Storage | Encrypted-at-rest data vulnerable to HNDL collection | Information Disclosure | Critical — retroactive decryption risk |
| Server | Hardware root-of-trust signatures compromised | Spoofing, Elevation of Privilege | High — firmware integrity at risk |
| Virtualization | Hypervisor attestation certificates weakened | Spoofing, Tampering | High — multi-tenant isolation depends on this |
| Operating System | Code signing and update verification broken | Tampering, Elevation of Privilege | High — supply chain integrity |
| Middleware | Service mesh mTLS and message queue encryption | Information Disclosure | Medium — internal traffic exposure |
| Runtime | JVM/container signing, runtime integrity checks | Tampering | Medium — depends on deployment model |
| Data | Database encryption keys, tokenization schemes | Information Disclosure | High — PII and financial data |
| Application | API authentication tokens, OAuth/OIDC signatures | Spoofing, Repudiation | High — application-layer identity |
The networking and storage layers represent the highest-priority migration targets. Networking because every external communication depends on key exchange protocols vulnerable to Shor’s algorithm. Storage because data encrypted today with classical algorithms can be harvested now and decrypted later — the damage is already accumulating.
This nine-layer model gives security architects a structured way to prioritize migration efforts rather than attempting a simultaneous overhaul that no organization has the budget or staffing to execute.
NIST-Standardized PQC Algorithms
NIST has standardized several PQC algorithms that serve as migration targets:
- ML-KEM (CRYSTALS-Kyber) — lattice-based key encapsulation for TLS and encrypted transport
- ML-DSA (CRYSTALS-Dilithium) — lattice-based digital signatures for code signing and certificates
- SLH-DSA (SPHINCS+) — hash-based signatures offering conservative security assumptions at the cost of larger signature sizes
Each algorithm presents different trade-offs in key size, computation time, and bandwidth overhead. Lattice-based schemes like ML-KEM offer smaller key sizes and faster operations but rest on newer mathematical assumptions. Hash-based schemes like SLH-DSA rely on well-understood hash function security but produce significantly larger signatures — a concern for bandwidth-constrained environments.
| Algorithm | Type | Primary Use Case | Key Size Trade-off | Maturity of Math |
|---|---|---|---|---|
| ML-KEM (Kyber) | Lattice-based | Key encapsulation / TLS | Moderate | Newer assumptions |
| ML-DSA (Dilithium) | Lattice-based | Digital signatures | Moderate | Newer assumptions |
| SLH-DSA (SPHINCS+) | Hash-based | Conservative signatures | Large | Well-established |
Three Transition Phases — and the Risks Each One Creates
The research identifies three distinct phases of quantum migration, each with its own threat profile. Organizations that treat migration as a single event will miss the compounding risks of the hybrid middle phase.
Phase 1: Pre-Transition (Now)
Classical cryptographic vulnerabilities are the baseline. RSA-2048 and ECC-256 remain computationally secure against classical attacks, but HNDL collection is underway. Every day of delay increases the volume of encrypted data that adversaries can stockpile for future decryption.
Your exposure: Any data with a secrecy requirement beyond 10-15 years is already at risk.
Phase 2: Hybrid Transition (Near-Term)
This is where migration risk peaks. Organizations deploying hybrid cryptographic strategies — running classical and PQC algorithms simultaneously — face a new attack surface:
- Algorithmic combiners that concatenate or nest classical and PQC key exchanges can introduce implementation bugs at the combination layer
- Dual certificates (X.509 certificates carrying both classical and PQC public keys) increase certificate size and complicate chain validation
- Protocol-level migration (e.g., TLS 1.3 with PQC key exchange) requires client and server coordination that creates backward-compatibility gaps
Side-channel attacks on PQC implementations represent the most underestimated risk of the hybrid phase. Lattice-based algorithms like ML-KEM are mathematically sound, but their software implementations can leak timing information, power consumption patterns, or cache access patterns that reveal secret keys. The transition to PQC doesn’t eliminate implementation-level vulnerabilities — it shifts them to less battle-tested code.
Phase 3: Post-Transition (Long-Term)
Full PQC deployment across all nine cloud layers. The primary risks shift to:
- Performance overhead from larger key sizes and slower operations impacting latency-sensitive workloads
- Interoperability gaps between cloud providers running different PQC implementations
- Ongoing side-channel hardening as PQC implementations mature
How AWS, Azure, and GCP Are Preparing
The three major cloud service providers (CSPs) are developing quantum-safe strategies at different velocities and with different architectural approaches. Security architects evaluating multi-cloud PQC readiness should assess each provider’s roadmap independently.
The research analyzes quantum-safe strategies from AWS, Microsoft Azure, and Google Cloud Platform, noting that each provider’s approach reflects their existing infrastructure investment. AWS has focused on hybrid key exchange integration in its TLS implementations. Google has invested in post-quantum experimentation within Chrome and internal infrastructure. Azure has aligned with NIST standardization timelines for enterprise certificate management.
For multi-cloud organizations, the critical concern is cryptographic agility — the architectural capability to swap cryptographic algorithms without re-engineering application code. Organizations locked into provider-specific encryption APIs face the highest migration friction.
The research framework positions cryptographic agility as a mandatory architectural requirement, not an optional enhancement. The paper identifies six critical research directions, stating:
“We identify six critical research directions: standardization and interoperability, hardware acceleration and performance optimization, AI-enhanced security and threat mitigation, integration with emerging cloud technologies, systemic preparedness and workforce development, and migration frameworks with crypto-agility.” — arXiv:2509.15653v4
The Workforce Problem No One Is Talking About
Among the six research directions identified, systemic preparedness and workforce development stands out as the bottleneck most likely to delay enterprise migration. PQC expertise sits at the intersection of quantum physics, applied cryptography, and cloud architecture — a combination that barely exists in today’s security talent pool.
Organizations that wait for the “right” hire will wait too long. The practical path forward involves upskilling existing cloud security teams on PQC fundamentals while partnering with vendors who have embedded PQC expertise into their platforms.
The BeQuantum Perspective: Cryptographic Agility as Architecture
BeQuantum’s approach to the quantum migration challenge centers on cryptographic agility by design — the principle that no encryption decision should be permanent.
Our Digital Notary platform implements algorithm-agnostic verification: documents and data authenticated today through BeQuantum’s PQC Layer can have their cryptographic proofs upgraded as algorithms evolve, without invalidating existing attestations. This addresses the dual-certificate complexity that the research identifies as a hybrid-phase risk.
The IceCase hardware module provides a physical trust anchor that isolates PQC key operations from the side-channel attack vectors the research highlights as PQC implementation weaknesses. By moving lattice-based key generation and signing into dedicated hardware, organizations reduce the software implementation surface where timing and cache-based side-channel attacks operate.
This isn’t about replacing your CSP’s encryption. It’s about adding a verification layer that remains valid regardless of which PQC algorithm your cloud provider adopts — or changes to.
What You Should Do in the Next 90 Days
1. Map your nine-layer cryptographic inventory (Weeks 1-4) Conduct a STRIDE-based assessment of your cloud infrastructure using the nine-layer model above. Identify every service, protocol, and data store that depends on RSA, ECC, or classical AES key exchange. Prioritize networking and storage layers.
2. Evaluate your CSP’s PQC roadmap (Weeks 4-8) Request quantum-readiness documentation from AWS, Azure, and GCP account teams. Assess whether your current encryption APIs support algorithm substitution without application code changes. If they don’t, your cryptographic agility debt is already accumulating.
3. Deploy a hybrid pilot on one critical data flow (Weeks 8-12) Select a single high-value data pipeline — preferably one with long-term secrecy requirements — and implement hybrid key exchange using ML-KEM alongside your existing classical algorithm. Measure the performance impact (latency, bandwidth, certificate chain validation time) against your SLAs.
Frequently Asked Questions
Q: When will quantum computers actually break current encryption? A: No one can give a precise date, but the consensus among cryptographic researchers places cryptographically relevant quantum computers within a 10-15 year horizon. The HNDL risk means data encrypted today with classical algorithms is already vulnerable if it needs to remain confidential beyond that window. The question isn’t “when will quantum break encryption” but “how long does your data need to stay secret.”
Q: Can’t we just wait for our cloud provider to handle the PQC migration? A: CSPs will migrate their infrastructure-level encryption, but application-layer cryptography — API tokens, database encryption keys, custom certificate chains — remains your responsibility. Organizations that assume CSP migration covers their full stack will discover gaps at the application, data, and middleware layers when compliance audits catch up.
Q: What is cryptographic agility and why does it matter for PQC migration? A: Cryptographic agility is the architectural capability to swap cryptographic algorithms across your stack without re-engineering application code. It matters because PQC standardization is still evolving — NIST may update algorithm recommendations, new vulnerabilities may emerge in specific implementations, and different cloud providers may adopt different algorithms at different timelines. Building agility now prevents a second costly migration later.
Last updated: April 15, 2026
[IMAGE: A towering cloud server rack array dissolving into quantum circuit patterns, with nine distinct horizontal layers glowing in graduated cyan-to-teal tones, each layer showing different network topology symbols — photorealistic, dark data center environment, dramatic low-angle perspective, 8K resolution]
