> ## Content Index > Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt > Use this file to discover other available public pages before exploring further. # Harvest Now, Decrypt Later What Post-Quantum Actually Means for Your VCF Estate - URL: https://www.mohammadsiddiqui.com/harvest-now-decrypt-later-what-post-quantum-actually-means-for-your-vcf-estate/ - Published: 2026-09-04T04:47:32.000Z - Updated: 2026-09-04T04:47:31.000Z - Description: RSA-2048 gets deprecated in 2030 and disallowed in 2035. That's closer than it sounds when the migration touches Secure Boot, TPMs, code signing and every certificate authority you run. Here's the honest position, including the parts that don't need fixing. - Author: Mohammad Siddiqui - Tags: security, architecture, Newsletter Post-quantum cryptography is one of those topics that arrives in a design review either as vague anxiety or as a slide with a picture of a quantum computer on it. Broadcom published a piece in April that's more useful than either, and it's worth reading properly because it's unusually clear about what isn't a problem as well as what is. The author is Paul Turner, Chief Product Officer of the VCF Division. When commitments to specific regulatory deadlines appear under that name, they carry more weight than a marketing post. ## The threat, briefly Shor's algorithm, published in 1994, solves the mathematical problems underneath RSA and elliptic curve cryptography. A sufficiently capable quantum computer running it would break TLS session confidentiality, code signature integrity, and the trust anchors of public key infrastructure. Current quantum computers are small, noisy and error-prone, and the largest numbers factored on real hardware remain trivial next to cryptographic key sizes. So the threat is credible rather than imminent. The reason that doesn't mean you can wait is harvest-now, decrypt-later. An adversary can capture encrypted traffic today and decrypt it once the capability exists. Anything with a long confidentiality life is already exposed: medical records, trade secrets, government communications, and in a financial services context, anything covered by a retention obligation measured in years. That reframes the timeline. The question isn't when quantum computers arrive. It's how long your data needs to stay confidential, measured from today. ## The part most posts skip: what isn't at risk This is the section I'd point people to first, because it prevents a lot of wasted anxiety. The vulnerability is in public-key cryptography, the kind that establishes trust between parties who have never met. Symmetric cryptography, where both sides already share a key, is far less exposed. AES for encryption and SHA for hashing remain strong at the sizes VCF uses. In practical terms, that means several things in your estate need no migration at all: • vSAN data-at-rest encryption, VM encryption and vMotion encryption all use AES with at least 256 bits. • Platform hashing defaults to SHA-256 or stronger. There's a second argument in the post worth understanding, because it changes the risk calculus for a private cloud specifically. **Trust inside a VCF deployment is anchored by your organisation, not by strangers.** Administrators confirm cryptographic host fingerprints when adding hosts. Certificates come from infrastructure you control. Identities verify against directories you own. An attacker with a quantum computer still can't insert themselves into that chain without also compromising the administrative controls that anchor it. That doesn't make the public-key cryptography inside VCF irrelevant to the migration. It does mean the stakes differ from an open-internet scenario where trust rests purely on maths. Useful nuance if someone in your organisation is treating PQC as an emergency. ## The deadlines that actually matter These are the numbers to put in a planning document. 2024 NIST publishes final ML-KEM, ML-DSA, SLH-DSA (August) 2026 TPM 2.0 v185 with ML-KEM and ML-DSA support (early 2026) UEFI Forum guidance on Secure Boot PQC expected during 2026 2026/27 FIPS 206 expected (further signature standardisation) 2027 Additional NIST algorithms expected through this year 2030 NIST IR 8547 deprecates RSA-2048 and other quantum-vulnerable algorithms 2035 NIST IR 8547 disallows them NSA CNSA 2.0 requires full transition to quantum-resistant algorithms Broadcom commits to adopting PQC-resistant algorithms for VCF on the CNSA 2.0 timeline. 2035 sounds distant until you consider that platform refresh cycles are five to seven years, which means the hardware you buy in the next couple of cycles needs to be able to get there. ## Why it can't just be switched on The gating dependency is worth understanding because it explains why no vendor can deliver this faster. VCF is FIPS-compliant. That means PQC algorithms cannot be enabled until FIPS-certified implementations exist. NIST published the final algorithm standards in August 2024, OpenSSL and Bouncy Castle have shipped implementations, and FIPS certification of those implementations is in progress. Certified versions then need to be consumed by the upstream components VCF depends on. Meanwhile the higher-layer standards aren't finished. FIPS 206 for signatures is expected late 2026 or early 2027\. The X.509 certificate format for PQC keys and signatures is still moving through standards bodies, as are hybrid communication standards. And there's a point in the post that deserves emphasis: migrating PKI to PQC is more than swapping signing algorithms. It reaches into certificate authority infrastructure, revocation systems, and the certificate lifecycle tooling most organisations depend on for automation. If your CA tooling assumes RSA key sizes and RSA-shaped certificates, that assumption is embedded in more places than you think. ## What's already shipping Not everything is waiting on standards. Three things exist now. • Avi Load Balancer already supports hybrid post-quantum key exchange in TLS. If you have public-facing services fronted by Avi, you can protect them against harvest-now, decrypt-later today. That's the single most actionable item in the whole post. • TLS Profiles for both the hypervisor and vCenter, letting you set, apply and audit predefined TLS configurations fleet-wide. Crypto configuration becomes a managed property rather than a per-host setting. • Certificate management with automated rotation, which is useful now and carries directly into PQC certificate rollout later. The certificate lifecycle work covered elsewhere in this series is groundwork for this. Also in progress: a Crypto Bill of Materials mapping which cryptographic algorithms are in use across VCF and which areas PQC migration will affect. A CBOM is the crypto equivalent of an SBOM, and it's the artefact that turns “where is our exposure” from a research project into a lookup. ## Signatures are the hard half Encryption gets the attention; signatures are the harder migration and the post is direct about it. Signatures anchor trust at nearly every layer. Secure Boot verifies firmware and bootloaders at startup. TPMs provide hardware-rooted attestation. Package managers verify software before installation. Certificate authorities sign the certificates underpinning trusted communications. Each of those was designed around today's algorithms, and each carries its own standards, hardware dependencies and upgrade path. Firmware signing in particular is constrained by hardware that may already be deployed and may not be replaceable on a software timeline. Broadcom's approach is hybrid signing: preparing VCF code signing and verification to support multiple signatures over the same data, so components can be signed with both traditional and post-quantum signatures during the transition. Verification then works whether or not the verifying component has migrated. That's the pragmatic answer to a migration that can't happen atomically. ## The goal underneath the goal The most useful framing in the post isn't about PQC at all. **Crypto-agility: the ability to replace cryptographic algorithms across protocols, applications, software, hardware and infrastructure on a timeline driven by need rather than platform constraint.** Treating PQC as a one-time algorithm swap leaves you facing the same scramble next time a cryptographic break or regulatory shift arrives. The architectural work being done for PQC is aimed at making future transitions routine. That's worth adopting as a design principle regardless of vendor. Anywhere your architecture hard-codes an algorithm choice, that's a future migration you've already committed to doing the hard way. ## What to do in your own estate The platform defaults give you a head start: AES-256 for symmetric encryption, SHA-256 or stronger for hashing, and TLS 1.3, which PQC requires, across the stack. The VCF Security Configuration Guide and the DISA STIG readiness guides show how to audit and tighten those. Beyond the platform, five things: • Inventory where cryptography lives. TLS configurations, certificates issued to workloads, hardware security modules, code signing and artefact verification. You can't plan a migration against an unknown surface, and this is the work that takes longest. • Identify long-lived signing keys used for firmware, code and long-term archives. These have the longest migration lead time because of hardware and toolchain dependencies. • Work out your data confidentiality horizon. Anything that must stay confidential past the quantum transition is exposed to harvest-now-decrypt-later today. In regulated industries, retention obligations often set that horizon for you. • Enable hybrid post-quantum key exchange where it's available now, starting with Avi-fronted public-facing services. • Coordinate platform, workloads and external services together. The post names this as the part most organisations underestimate, and it's a fair warning your platform being ready doesn't help if the applications on it aren't. For anyone in financial services: PQC readiness is starting to appear in regulatory conversations, and the 2030 and 2035 dates are firm enough to plan against. Getting the cryptographic inventory done early is the cheapest possible version of this work. Doing it under deadline pressure is not. ## Sources • [Broadcom Post-Quantum Readiness on VMware Cloud Foundation (Paul Turner, 28 April 2026)](https://blogs.vmware.com/cloud-foundation/2026/04/28/post-quantum-readiness-on-vcf/?ref=mohammadsiddiqui.com) • [NIST Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography?ref=mohammadsiddiqui.com) • [NSA Commercial National Security Algorithm Suite 2.0 FAQ (2035 transition target)](https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI%5FCNSA%5F2.0%5FFAQ%5F.PDF?ref=mohammadsiddiqui.com) • [CISA Post-Quantum Cryptography Initiative](https://www.cisa.gov/topics/risk-management/quantum?ref=mohammadsiddiqui.com) • [NCCoE Migration to Post-Quantum Cryptography project](https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms?ref=mohammadsiddiqui.com) • [Broadcom VMware Avi Load Balancer PQC support](https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/31-2/vmware-avi-load-balancer-configuration-guide/security/ssl-tls-profile/ssl-profile-templates/post-quantum-cryptography.html?ref=mohammadsiddiqui.com) • [Broadcom VCF Security Configuration Guide](https://brcm.tech/vcf-scg?ref=mohammadsiddiqui.com) • [GitHub VCF Security and Compliance Guidelines](https://github.com/vmware/vcf-security-and-compliance-guidelines?ref=mohammadsiddiqui.com) • [GitHub VCF 9.x STIG Readiness Guide](https://github.com/vmware/dod-compliance-and-automation/tree/master/vcf/9.x?ref=mohammadsiddiqui.com) Related coverage in this series: the certificate lifecycle piece, and the Frontier AI Security Readiness programme.