No quantum computer in existence today can break the RSA or elliptic-curve cryptography protecting a typical corporate VPN, TLS certificate, or SSH session. But that is not the reason IT teams should start paying attention to post-quantum cryptography now.

The real reason is more practical. Replacing the cryptography inside a modern enterprise is a multi-year infrastructure project. The replacement standards already exist. And some of the data moving across networks today needs to stay confidential well past the point where quantum computers might eventually catch up. NIST finalized its first three post-quantum cryptography standards in August 2024, closing an eight-year evaluation process. Organizations that wait for a working quantum computer before they start planning will still be migrating years after the threat becomes operational.

This is not an article about quantum physics. It sets that part aside and focuses on what IT managers, CISOs, and infrastructure leads actually need to do between now and whenever “later” turns out to be.

What Quantum Computers Actually Threaten

A cryptographically relevant quantum computer, meaning one capable of attacking real-world cryptographic systems that classical computers cannot feasibly attack, does not exist yet. NIST said as recently as mid-2026 that current quantum computers remain too small and unstable to threaten deployed cryptography.

The threat that eventually arrives is specific, not universal. It comes from Shor’s algorithm, a method published in 1994 that gives a sufficiently powerful quantum computer an efficient way to solve two mathematical problems: factoring large integers and computing discrete logarithms. Classical computers find these problems practically infeasible at today’s key sizes, which is exactly why RSA, Diffie-Hellman, ECDH, ECDSA, and EdDSA are considered secure. A large, stable, fault-tolerant quantum computer would remove that difficulty. It would not brute-force these algorithms faster; it would solve the underlying math directly.

In enterprise terms, that puts two functions at risk: establishing a shared secret between two parties, and proving who signed or authenticated something. Nearly everything built on RSA, Diffie-Hellman, ECDH, ECDSA, or EdDSA does one of those jobs, or both.

Symmetric cryptography sits on different mathematical ground. AES, SHA-2, SHA-3, and password-hashing functions such as Argon2 or PBKDF2 do not rely on factoring or discrete logarithms. The relevant quantum technique here, Grover’s algorithm, offers a much smaller speedup, and NIST’s own FAQ states it provides little or no practical advantage against AES, with AES-128 expected to remain secure for decades. Quantum computing does not make encryption in general obsolete. It targets the specific mathematics behind public-key cryptography.

TLS is a useful illustration. A typical HTTPS connection uses public-key cryptography for key establishment and authentication, then uses symmetric encryption such as AES to protect the actual data. A future quantum computer running Shor’s algorithm could recover the session key by attacking the key-establishment step, not by cryptanalyzing AES. Once the key exchange is quantum-resistant, the AES layer behind it may not need to change.

Why Waiting Is Risky: Harvest Now, Decrypt Later

If today’s encryption is safe from today’s quantum computers, the obvious question is why act now. The answer is a pattern called harvest now, decrypt later, sometimes called store now, decrypt later: an adversary captures encrypted traffic or steals encrypted data today and simply holds onto it until a capable quantum computer can decrypt it.

This matters only for information that will still be worth reading in five, ten, or twenty years, but plenty of enterprise data fits that description:

• Intellectual property, product designs, and research data
• Strategic plans, along with merger and acquisition materials
• Financial records and long-range forecasts
• Healthcare records and other personal data with long retention requirements
• Legal advice, litigation files, and privileged communications
• Long-lived credentials, API keys, and recovery material
• Research archives and backups whose encryption keys were established through public-key methods

A practical way to decide what deserves early attention is to add the data’s required confidentiality lifetime to the realistic time it will take to migrate the system protecting it, then weigh that combined figure against the genuine uncertainty over when a capable quantum computer might arrive. The UK’s National Cyber Security Centre recommends much the same exercise: record data lifetime and adversary value, then prioritize the services processing the most valuable or longest-lived data. Nobody can answer the timeline question precisely, and the exercise doesn’t require them to. Its purpose is to surface systems where the confidentiality window and the migration timeline already stretch further than anyone can comfortably guarantee, not to produce a prediction of a specific date.

Signatures raise a related but distinct concern. Capturing a signed document today does not let an attacker read it, but a future quantum computer could eventually let them forge new RSA or ECC signatures. Long-lived certificates, code-signing chains, and archived signed records deserve a separate look at how long their authenticity needs to hold.

Post-Quantum Cryptography Is Now a Standards Issue

Until August 2024, post-quantum cryptography was mostly a research topic. It no longer is. NIST finalized three standards that month, closing an eight-year public evaluation process:

• FIPS 203 (ML-KEM): a key-encapsulation mechanism used to establish a shared secret between two parties
• FIPS 204 (ML-DSA): a general-purpose digital signature algorithm
• FIPS 205 (SLH-DSA): a hash-based digital signature algorithm built on different mathematical assumptions from ML-DSA, providing an alternative standardized signature approach

Standard	Function	Status as of September 2026
FIPS 203 / ML-KEM	Key establishment (shared secret)	Final, published August 2024
FIPS 204 / ML-DSA	General-purpose digital signatures	Final, published August 2024
FIPS 205 / SLH-DSA	Hash-based digital signatures	Final, published August 2024
FIPS 206 / FN-DSA	Compact lattice-based signatures	Draft stage; not yet a final FIPS
HQC	Backup key encapsulation (different math)	Selected March 2025; not yet finalized

ML-KEM deserves a precise description, because it gets misdescribed often. It does not encrypt an entire network session or a file by itself. It replaces the classical key-establishment step, the RSA or Diffie-Hellman handshake, with a quantum-resistant equivalent, producing a shared secret that AES or another symmetric cipher then uses to protect the actual data. Swap ML-KEM into TLS and the data-plane encryption behind it barely changes.

Two more items are moving through NIST’s pipeline without being finished standards yet. FN-DSA, formerly known as Falcon and destined to become FIPS 206, is a compact lattice-based signature scheme. It remains at draft stage, and no final FIPS 206 had been published as of this writing. HQC was selected for standardization in March 2025 as an additional KEM based on different mathematics than ML-KEM, but it is not yet a finalized standard. Neither it nor FN-DSA should be treated as a finalized NIST standard yet, and neither is a reason to delay work on the algorithms that are already final.

The practical takeaway for a normal enterprise program: build on ML-KEM, ML-DSA, and SLH-DSA now, and treat everything else as something to track rather than something to deploy.

What IT Teams Should Actually Be Doing Now

None of the following requires a quantum computer to exist first. It requires treating cryptographic risk the way IT teams already treat any long-lived infrastructure dependency: find it, prioritize it, build in the ability to change it, confirm vendors can support it, plan for it in procurement, and test before rolling it out broadly.

1. Find Where Vulnerable Cryptography Is Being Used

A cryptographic inventory sounds like a scanning exercise, but a scanner alone will not produce one. Vulnerable public-key cryptography shows up in places that automated tools frequently miss: TLS certificates and web infrastructure, VPNs and IPsec gateways, SSH, PKI and certificate authorities, identity and authentication systems, HSMs and KMS platforms, APIs, application code and cryptographic libraries, databases, code and firmware signing pipelines, CI/CD tooling, cloud services and SaaS platforms, network and security appliances, IoT and OT devices, and backups and archives.

Architecture reviews, certificate repositories, source code, configuration files, vendor documentation, and plain conversations with system owners all contribute pieces that a scan cannot see on its own. This is not a one-time project. It is closer to an ongoing asset-management capability that stays current as systems change.

A useful inventory captures more than the algorithm in use. For each system, it should show which business function depends on it, who owns it, what information it protects, how long that information needs to stay protected, what vendor or hardware dependencies exist, when the system reaches end of life, and whether it can be upgraded in place or needs to be replaced outright.

2. Prioritize Rather Than Trying to Migrate Everything

Not every RSA certificate deserves the same urgency. A research VPN carrying confidential intellectual property that needs to stay secret for fifteen years is a different problem than a public marketing website serving information that is worthless within hours.

Useful factors for setting priority include data sensitivity, the required confidentiality or authenticity lifetime, how exposed the system is to capture today, business criticality, how hard the migration will be, hardware replacement cycles, vendor dependencies, and whether the system is already considered legacy. Systems that score high across several of these deserve attention well ahead of systems that score low on all of them.

3. Build Crypto-Agility

Crypto-agility means designing systems so that algorithms, key sizes, certificates, and cryptographic providers can change without redesigning the application around them. In practice that means avoiding hard-coded algorithm choices, relying on maintained cryptographic libraries and providers instead of custom implementations, keeping those libraries independently upgradeable, supporting controlled algorithm negotiation, maintaining telemetry on what is actually being used in production, designing certificate and key rotation properly from the start, and making obsolete algorithms genuinely removable rather than merely disabled by default.

This matters beyond the current transition. Post-quantum cryptography will probably not be the last cryptographic migration any organization faces, and systems built with agility in mind will handle the next one far more cheaply than systems that had algorithms baked in from the start.

4. Ask Vendors What Their PQC Roadmap Actually Is

Almost no enterprise builds its own cryptography from scratch, which means vendor readiness sets the pace of migration as much as internal planning does. Worthwhile questions for suppliers include which finalized NIST standards they support and in which product versions, whether that support is generally available or still experimental, whether adoption requires firmware, software, licensing, or hardware changes, whether hybrid classical and post-quantum modes are supported, whether existing HSMs, VPN appliances, or PKI infrastructure will support the upgrade or require replacement, when classical-only operation will be removed, whether administrators can actually verify which algorithm was negotiated in a given session, and what happens to products that reach end of life before PQC support arrives.

Vague “quantum-safe” marketing language is not an answer to any of these questions, and it should not be accepted as one.

5. Put PQC Into Procurement Now

This matters most for equipment expected to stay in service for years: VPN and security appliances, network infrastructure, PKI, HSM, and KMS platforms, IoT and OT equipment, long-lived software platforms, and multi-year cloud or managed-service contracts.

The goal is not to require every new purchase to run post-quantum cryptography immediately. It is to avoid buying long-lived systems in 2026 that have no credible path to supporting it later, which would simply recreate today’s legacy problem on a new timeline. CISA’s product-category guidance lists categories where PQC-capable products are already widely available, including cloud services, web software, and parts of endpoint security, alongside further categories where implementation is still being encouraged rather than assumed. That split is worth factoring into contract timelines.

6. Test Before Broad Migration

Post-quantum algorithms are not always a drop-in replacement. Larger public keys and ciphertexts can affect packet size and fragmentation. Larger signatures expand certificate chains and can trip up applications that assumed fixed field sizes. Proxies, middleboxes, and monitoring or inspection tools may not parse the new handshakes correctly. HSMs and secure elements may not support the new formats yet. Embedded devices may run into RAM, flash, or bandwidth constraints that a workstation never encounters.

None of this means post-quantum cryptography is slow. Size and integration constraints tend to matter more than raw computation. The practical response is the same one IT teams already use for any major infrastructure change: run a pilot on a service with good observability, expand through canary deployment, keep a rollback plan ready, and verify from telemetry which algorithm actually got negotiated rather than assuming the configuration worked as intended.

Why Hybrid Cryptography Is Appearing First

Many early production post-quantum deployments are hybrid, combining a classical algorithm with a post-quantum one rather than switching outright. A hybrid TLS key exchange, for example, performs a conventional exchange such as X25519 alongside an ML-KEM exchange, then combines both results to derive the session key.

The logic is straightforward: the connection stays protected as long as at least one of the two algorithms holds up. That hedges against a future quantum break of the classical algorithm and against the possibility that a newer post-quantum algorithm turns out to have an unexpected weakness of its own, while easing the rollout because both endpoints can negotiate compatible options during a gradual transition.

Hybrid deployment is already showing up in real infrastructure. OpenSSH made an ML-KEM and X25519 hybrid exchange its default starting in version 10.0. Microsoft made hybrid ML-KEM TLS key exchange generally available in Windows 11 and Windows Server 2025, though administrators still have to enable it. AWS has rolled out hybrid ML-KEM support across services including Secrets Manager, and Cloudflare reports that over 65% of human traffic to its network is post-quantum encrypted, while the certificate authentication side of the same connections is still classical.

It is worth being precise about what this protects. A hybrid key exchange secures the session key. It does not automatically make the rest of the system post-quantum. Certificate authentication, code signing, and other components in the same connection may still rely entirely on RSA or ECC, and each of those needs its own migration path.

Singapore and Hong Kong Are Already Moving From Awareness to Preparation

Singapore has taken the clearer official position of the two markets. Its Cyber Security Agency, together with GovTech and IMDA, released a Quantum-Safe Migration Handbook and a companion Quantum Readiness Index in mid-2026, both built around risk assessment, governance, cryptographic discovery, vendor coordination, and phased testing. Singapore has explicitly named PQC, using NIST’s standards, as its mainstream migration path, with quantum key distribution treated as a complementary technology for niche, high-assurance use rather than a substitute for enterprise cryptography. The Monetary Authority of Singapore has separately pushed financial institutions toward cryptographic inventories, crypto-agility assessments, and vendor engagement.

Hong Kong’s most concrete evidence comes from its banking sector. The Hong Kong Monetary Authority’s 2026 Quantum Preparedness Index put the initial sector score at 2.3 out of 10 among the Authorized Institutions that responded to its survey. Around 68 percent of those banks showed awareness or had moved into planning or piloting, yet roughly half still had no formal PQC plan, a gap between awareness and readiness that HKCERT’s public guidance echoes in its call for organizations to prepare rather than wait for quantum attacks to become practical. No general Hong Kong business deadline exists yet; these figures describe banking-sector survey respondents, not the wider economy.

The pattern across both markets matches the guidance shaping this transition globally: treat quantum readiness as a planning and infrastructure problem to start on now, not a future event to react to later.

What IT Teams Should Not Do

A short list of mistakes is worth naming directly, because most of them come from good intentions applied at the wrong moment.

• Do not invent proprietary “quantum-proof” cryptography instead of using validated, standards-based implementations.
• Do not deploy research candidates, such as unfinished signature schemes still under NIST evaluation, as though they were finalized standards.
• Do not replace sound symmetric encryption like AES-256 without a real reason to.
• Do not attempt an uncontrolled, all-at-once migration across the entire environment.
• Do not assume that buying one “quantum-safe” product solves the problem for the whole organization.
• Do not assume that vendor support for an algorithm means it is actually being used; verify what gets negotiated.
• Do not wait for a demonstrated attack on production RSA before starting discovery and planning.

The Real Question for 2026

The right question in 2026 is not when quantum computers will break RSA. Nobody can answer that with confidence, and waiting for a firm date is itself a decision, just not usually a good one.

The better question is how long it would take an organization to discover, prioritize, test, and replace the cryptography its business already depends on. For most organizations, the honest answer is several years, or simply unknown. Either answer means there is work to do now, while the timeline still allows for a controlled transition instead of a rushed one.

FunctionEight works with IT teams across Singapore and Hong Kong on the infrastructure foundations that make transitions like this manageable: understanding system dependencies, modernizing legacy platforms, reviewing security architecture, and building environments that are easier to update as standards evolve. Post-quantum migration is one more reason that groundwork is worth doing now rather than later.