The algorithms that secure most digital communications today, such as RSA and elliptic curve cryptography, rely on math problems that traditional computers cannot solve in any reasonable amount of time, even with the computing advances of the last few decades. Quantum computers, however, work on fundamentally different principles. A traditional computer uses “bits” that hold a single value, either 0 or 1. A quantum computer uses “quantum bits” or “qubits” that exist in a combination of the 0 and 1 states at the same time, each with its own weight. Physicists call this a superposition, and it is profoundly non-intuitive, defying the logical world of defined states we’re accustomed to.
Those non-intuitive properties can be used in productive ways, though. For example, qubits can be entangled with each other so that they behave as a linked group rather than as separate pieces. A quantum computer can work across potentially billions or hundreds of billions of such states at once, using a process called interference to cancel out wrong answers and reinforce the right ones. The net effect is that some problems that would take a traditional computer billions of years would become solvable in a much shorter window. This is welcome for many problems, like drug discovery and climate modeling, but unfortunately, it could pose a challenge for today’s cryptography. A quantum computer’s ability to manage many states efficiently also allows it to potentially break multi-bit encryption techniques like RSA-2048 or ECDSA in hours.
Fortunately, the capabilities to break encryption are real, but not yet realized at useful scales. Today’s quantum computers are small, noisy, and error-prone, and the largest numbers anyone has factored on actual quantum hardware are still tiny compared to cryptographic key sizes. The engineering challenges of building a quantum computer capable of breaking real cryptography are significant, and that work is being pursued actively by researchers and governments around the world. Therefore, while the threat is credible, there is enough time to prepare a resilient solution before its arrival.
The specific danger to modern cryptography comes from quantum algorithms that solve problems traditional computers cannot. The most important is Shor’s algorithm, published in 1994. It targets the hard math problems behind RSA and elliptic curve cryptography, the backbone of public-key cryptography on the internet today. Those problems are effectively unsolvable with traditional computers at the key sizes we use, which is why current cryptography works. A sufficiently capable quantum computer running Shor’s algorithm would solve them quickly enough to break the confidentiality of TLS sessions, the integrity of code signatures, and the trust anchors of public key infrastructure.
The question is when, not whether. Progress in quantum computing is accumulating, and the inertia of deployed systems means that by the time a capable quantum computer exists, the migration will already need to be well underway. This is especially true because adversaries can steal encrypted data today and decrypt it later once these capabilities emerge, an attack called “harvest-now, decrypt-later.” Data with a long confidentiality lifetime, whether medical records, trade secrets, or government communications, is already at risk from capture today.
The response is Post-Quantum Cryptography, or PQC, which is a new generation of cryptographic methods and algorithms designed to be secure against both quantum computers and traditional ones. The US National Institute of Standards and Technology (NIST) has been driving the initiative to establish standards in this area in recent years, all in collaboration with international bodies including the European Telecommunications Standards Institute (ETSI), the International Organization for Standardization (ISO), and the Internet Engineering Task Force (IETF). In 2024, after several years of research, NIST issued its PQC standards, which are a principal set of encryption algorithms that they have vetted to be designed to withstand cyberattacks from a quantum computer. Additional algorithms are expected to be standardized through 2027, and NIST has a parallel track for selecting more signature schemes beyond that.
Having standards in place is only the beginning. Actually adopting them touches software, hardware, and standards across the entire industry. Regulators across the world, including in the European Union, United Kingdom, and United States, have already established a phased roadmap, and migration deadlines for PQC.
Before walking through what needs to change, it is worth noting what does not. Much of what happens inside VMware Cloud Foundation (VCF) already uses cryptography that is less likely to be seriously threatened by quantum computers.
The cryptography that is most at risk is public-key cryptography, the kind that lets two parties who have never met establish trust over a network. Every time a browser reaches a website it has never seen, or a phone connects to a corporate VPN, or a software update gets verified against a vendor’s signature, public-key cryptography is doing that work. This is what RSA, elliptic curve, and the NIST-standardized PQC algorithms address, and it is where the bulk of the migration work lives. But a lot of what secure systems actually do is protect bulk data once trust is established, and that work is done by symmetric cryptography, where both sides share the same secret key. AES for encryption and SHA for hashing are the two most common examples. Both are far less vulnerable to quantum attack than public-key cryptography, and at the key and output sizes VCF uses, they remain strong well into the foreseeable future.
In practical terms, this means VCF already has a meaningful degree of quantum resistance built in. Features such as VMware vSAN data-at-rest encryption, VM encryption, and vMotion encryption all use AES with at least 256 bits. Hashing within the platform uses SHA-256 or stronger as the default. No immediate migration is required for any of this.
The internal trust model of a VCF deployment also matters here. A lot of the public-key cryptography at risk from quantum computers is used to establish trust between parties that have never met and cannot verify each other directly. VCF operates differently. Trust within a deployment is anchored by your organization itself: administrators confirm cryptographic host fingerprints when adding hosts to a cluster, certificates are issued and managed by infrastructure the organization controls, and identities are verified against directories the organization owns. An attacker with a quantum computer still cannot substitute themselves into that chain without also compromising the administrative controls that anchor it. That does not make the public-key cryptography inside VCF irrelevant to the PQC migration, but it does mean the stakes of a compromise are different from an open-internet scenario where trust is established purely through math.
Broadcom is not waiting for the full PQC standards to mature to start shipping post-quantum protection either. The VMware Avi Load Balancer already supports hybrid post-quantum key exchange in TLS, helping you protect your public-facing communications today. Other parts of VCF will gain PQC support on similar terms as upstream cryptographic libraries and higher-layer standards mature.
Broadcom’s commitment: Broadcom is committed to adopting PQC-resistant algorithms and methods for VCF on the timelines mandated by the NSA through CNSA 2.0, with full transition to quantum-resistant algorithms required by 2035. NIST has set an aligned technical deadline in its IR 8547 transition plan, deprecating RSA-2048 and other quantum-vulnerable algorithms by 2030 and disallowing them by 2035. Reaching full PQC support in VCF depends on work happening outside of Broadcom: cryptographic libraries need to be updated and FIPS-certified, upstream software components that VCF depends on need to consume those libraries, and higher-layer standards for how PQC algorithms are used in certificates and protocols need to be finalized. Broadcom’s role in that transition is to prepare the VCF stack now so that post-quantum support can land as those upstream pieces become available.
Dependencies on libraries and standards: PQC implementation in VCF is gated by work that has to happen upstream before anything can be enabled in production. VCF is FIPS-compliant, which means PQC algorithms cannot be enabled until FIPS-certified implementations are available. NIST published final versions of ML-KEM, ML-DSA, and SLH-DSA in August 2024, and the major cryptography libraries have been moving quickly to adopt them. Recent releases of libraries such as OpenSSL and Bouncy Castle include implementations, and FIPS certification of those implementations is in progress. It will take additional time for certified versions to be broadly available, and longer still before they are consumed by software components that VCF depends on. Standards bodies are also still finalizing how the algorithms will be used at higher layers. FIPS 206, which will further standardize signature algorithms, is currently expected in late 2026 or early 2027. Other higher-layer standards, such as the X.509 certificate format for PQC keys and signatures, as well as standards for hybrid communications, are still working their way through their respective standards bodies. Migrating PKI to PQC is more than replacing signing algorithms; it reaches into certificate authority infrastructure, revocation systems, and the certificate lifecycle tooling that most organizations rely on for automation.
Work already underway inside VCF: Broadcom has shipped and is building specific capabilities that move VCF toward PQC readiness. We have shipped TLS Profiles for both the hypervisor and VMware vCenter, letting organizations easily set, apply, and audit pre-defined TLS configurations across their fleet. That capability is expanding as part of our vision for VCF. We are also building a Crypto Bill of Materials (CBOM) that maps the cryptographic algorithms in use across VCF and identifies which areas will be affected by PQC migration. And we are continuing to invest in certificate management, including automated rotation with minimal operational impact, work that benefits organizations today and carries forward directly into PQC certificate rollout.
Participation in standards bodies: Broadcom is actively participating in the industry bodies that will define how PQC lands across the ecosystem. That includes the Trusted Computing Group, which released TPM 2.0 v185 with ML-KEM and ML-DSA support in early 2026 and gives hardware vendors a foundation to build toward. It includes the UEFI Forum, which is still working through what PQC support looks like for Secure Boot and across the full firmware ecosystem, with broader guidance expected during 2026. And it includes the Confidential Computing Consortium, where trusted execution environments and attestation protocols also need to migrate to PQC algorithms. Being a member of these bodies means Broadcom is helping to shape how these solutions look and interoperate, not just waiting for them to emerge.
Data in transit: Hybrid TLS key exchange is the industry’s converged answer for protecting data in transit during the PQC transition. Hybrid schemes combine a conventional algorithm with a PQC algorithm, typically ML-KEM, so that the resulting session is secure against attackers using either traditional or quantum computers. An adversary recording today’s traffic would need to break both algorithms to decrypt it later. NIST recommends hybrid modes during the transition to PQC, and supporting hybrid key exchange in VCF is one of the first ways that PQC adoption will show up once the relevant libraries are available.
Digital signatures: Digital signatures are the harder half of the PQC migration. Signatures anchor trust at nearly every layer of a modern computing stack: Secure Boot verifies firmware and bootloaders at startup, Trusted Platform Modules (TPMs) provide hardware-rooted attestation, package managers and update services verify software before installation, and certificate authorities sign the certificates that underpin trusted communications. Each of these systems was designed around today’s signature algorithms, and each carries its own industry standards, hardware dependencies, and upgrade paths. The signature migration will play out across years as vendors, hardware platforms, and downstream software consume the standards.
Hybrid signing in VCF: Broadcom is preparing the VCF code signing and verification infrastructure to support multiple signatures over the same data, so code can be signed with both traditional and post-quantum signatures during the transition. This lets VCF verify code integrity whether the component doing the verification has migrated to PQC or not.
Crypto-agility as the larger goal: The PQC migration is also an opportunity to build something larger: lasting crypto-agility across VCF. NIST defines crypto-agility as the ability to replace cryptographic algorithms across protocols, applications, software, hardware, and infrastructure on a timeline driven by need rather than by platform constraints. Treating PQC as a one-time swap of one set of algorithms for another would leave us facing the same scramble the next time a cryptographic break, a new standard, or a regulatory shift demands change. The work underway to support PQC, both in upstream cryptographic libraries and in the VCF architecture itself, is designed to make future transitions easier. When the world discovers something new about cryptography, VCF will be able to adapt at a pace driven by the discovery, not by the platform.
For the VCF platform itself, the defaults give you a head start. AES-256 is the default for symmetric encryption, SHA-256 or stronger is the default for hashing, and TLS 1.3, which PQC requires, is the default across the VCF stack. The VCF Security Configuration Guide and the DISA STIG readiness guides provide specific examples of how to audit these defaults and tighten them further for environments with higher assurance requirements. Beyond the platform, the steps that matter most are in your own environment. Inventory where cryptography lives across TLS configurations, certificates issued to workloads, hardware security modules, and code signing and artifact verification. Coordinate the platform, the workloads running on it, and any external services those workloads depend on, because that coordination is the part of the migration most organizations underestimate. Pay particular attention to long-lived signing keys used for firmware, code, and long-term archives, and plan the migration of those signing operations to PQC as the tooling becomes available. For data that must remain confidential beyond the quantum transition, hybrid transport encryption (once available) helps protect against harvest-now, decrypt-later attacks. And invest in crypto-agility wherever deployment lifecycles allow, so the next cryptographic change can land as a smooth upgrade. That work unfolds alongside a much bigger industry effort.
Broadcom is actively preparing VCF for quantum readiness alongside the standards bodies, cryptographic library maintainers, and upstream software projects whose work on which VCF depends. The standards are still maturing, but the starting position is better than it might look: VCF’s symmetric cryptography is already strong, the internal trust model is anchored by your organization, and post-quantum support is already shipping where VCF meets the open internet. As the rest of the ecosystem catches up, you will receive the benefits as smooth upgrades rather than as a disruptive migration. Please reach out to your Technical Account Manager and account team if you have questions.
Further Reading
For readers who want to go deeper:
(Thank you to Devyani Pisolkar, Bob Plankers, Adam Hawley, Jesse Pool, Chip Childers, Yogi Bhasin, and Ali Emadi for their contributions to this post)
Subscribe to get the latest posts sent to your email.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。