Your Passwords Aren't Safe Forever: The Post-Quantum Cryptography Countdown

The most misleading phrase in the post-quantum cryptography debate is the title phrase itself. Your password is not the main thing a future quantum computer is expected to break. The larger problem is the public-key cryptography wrapped around modern systems: TLS certificates, VPN handshakes, code-signing chains, software update verification, device enrollment, and the asymmetric keys that help establish trust before a password or passkey even matters. That distinction is not semantic. It changes the timeline, the migration burden, and the organizations that need to act first. As of June 1, 2026, the credible official guidance is not that a cryptanalytically relevant quantum computer already exists. It is that the standards are now real, the transition will take years, and long-lived data and long-lived trust chains are already on the clock (NIST, 2024; NIST, 2025; CISA, NSA, and NIST, 2023).

NIST finalized the first three U.S. post-quantum cryptography standards on August 13, 2024. FIPS 203 defines ML-KEM for key establishment, FIPS 204 defines ML-DSA for digital signatures, and FIPS 205 defines SLH-DSA as a hash-based signature backup (NIST, 2024). That was the turning point from laboratory competition to migration work. NIST's current project page now states that organizations should begin applying these standards and that, under the transition timeline in NIST IR 8547, quantum-vulnerable algorithms will be deprecated and ultimately removed from NIST standards by 2035, with higher-risk systems moving earlier (NIST, 2025). This is why the countdown is operational rather than cinematic. The problem is not that the internet falls apart next year. The problem is that replacing cryptography across real systems is slow, dependent on vendors, and buried in places many organizations do not even inventory well today.

The Countdown Is About Trust Infrastructure, Not Just Passwords

Most people hear post-quantum cryptography and imagine a hacker guessing passwords faster. That is the wrong mental model. Quantum risk lands first on the asymmetric cryptography used to create shared secrets and verify identities. FIPS 203 describes a key-encapsulation mechanism, or KEM, that lets two parties establish a shared secret over a public channel, after which symmetric cryptography can protect the session (NIST, 2024). FIPS 204 describes ML-DSA, a digital signature standard for authentication, integrity, and non-repudiation (NIST, 2024). Those are the layers beneath secure web sessions, software updates, enterprise certificates, and signed artifacts. In practice, the first post-quantum migration wave is about key exchange and signature plumbing, not about replacing every login screen on earth.

This is why official guidance keeps returning to inventory. The joint CISA, NSA, and NIST factsheet on quantum readiness tells organizations to build a roadmap, prepare a cryptographic inventory, examine supply-chain dependence, and engage vendors early (CISA, NSA, and NIST, 2023). NIST's migration project frames the first practical step the same way: discover where public-key cryptography is actually used before trying to replace it (NCCoE, 2026). That advice sounds dull because it is real infrastructure work. A large enterprise may rely on vulnerable algorithms in certificate authorities, hardware security modules, firmware-signing tools, mobile device management stacks, archived backups, partner APIs, and embedded products that have not been touched in years. The migration challenge is not primarily mathematical. It is architectural and organizational.

The phrase "harvest now, decrypt later" explains why the timeline feels urgent even without a production-grade quantum attacker. Microsoft's current Active Directory Certificate Services overview names two concrete risks. The first is long-lived trust, where root certificate authorities, code-signing certificates, and similar identities issued today may need to remain trustworthy for many years. The second is deferred decryption, where adversaries collect encrypted traffic now and wait for better capabilities later (Microsoft, 2026). That framework is clearer than sensational predictions because it maps to actual system lifetimes. If a secret must stay secret for ten or fifteen years, waiting until quantum hardware is undeniable is too late.

What Changed After August 13, 2024

Before the 2024 standards, many security leaders could plausibly say they were waiting for NIST to finish the main selection and naming work. That excuse is gone. FIPS 203 states that ML-KEM has three parameter sets, from ML-KEM-512 to ML-KEM-1024, and describes it as a standard meant to establish shared secret keys for encrypted communications (NIST, 2024). FIPS 204 does the equivalent job for signatures with ML-DSA (NIST, 2024). NIST's broader PQC project page now says plainly that these standards can and should be put into use now, while additional algorithms such as HQC and Falcon-derived work continue through the backup and alternative pipeline (NIST, 2025). That does not mean every protocol is finished or every compliance profile is settled. It means the core standards are no longer hypothetical.

The consequence is that the countdown has become uneven. Some environments can move first because they control both ends of the connection or because they already operate modern certificate and key-management systems. Others are constrained by protocol standards, hardware dependencies, or vendors that still need hybrid support, validation, and interoperability testing. NIST's project page captures that tension by pairing immediate adoption language with a long deprecation timeline through 2035 (NIST, 2025). The migration is urgent and gradual at the same time. That is normal for cryptography. The standard can be final long before every implementation surface is ready.

There is another shift worth noticing. The strongest official language has moved away from vague quantum futurism and toward migration mechanics. NIST IR 8547 is not a speculative essay about what a quantum computer might someday do. It is a transition report identifying which standards are vulnerable, which replacements exist, and how federal agencies, industry, and standards bodies should orient their timelines (NIST IR 8547, 2024). When a technical field starts producing documents like that, the maturity signal is not dramatic capability. It is governance readiness. The countdown becomes real when procurement, inventories, certificate chains, and validation programs start moving.

Why Consumer Platforms Are Already Quietly Moving

The fastest way to understand the shift is to watch platform vendors. Apple did not wait for a public crisis to redesign iMessage around PQ3. Its security engineering team argues that a messaging system needs more than one post-quantum key exchange at the start of a conversation. Apple describes PQ3 as Level 3 security because post-quantum cryptography is used for both the initial key establishment and ongoing message exchange, with periodic rekeying to limit damage from key compromise (Apple, 2024). That is a practical lesson. Quantum readiness is not only about choosing a new primitive. It is also about rethinking protocol behavior, recovery, and message overhead.

Google is moving on the platform side as well. In March 2026, Google announced that Android 17 begins the first phase of Android's post-quantum transition, integrating ML-DSA into Android Verified Boot, bringing ML-DSA support to Android Keystore, and enabling hybrid signing support for Google Play app distribution (Google, 2026a). That matters because it shifts PQC from research features into software authenticity, device trust, and developer tooling. In February 2026, Chrome's security team also announced a new program to make HTTPS certificates secure against quantum computers while explicitly acknowledging the performance and bandwidth costs introduced by larger post-quantum cryptography artifacts (Google, 2026b). This is the shape of a real migration: not a single switch, but a series of protocol, certificate, and platform adaptations designed to preserve usability while changing the math underneath.

Those examples also correct a common misunderstanding. Post-quantum cryptography is not only for governments, classified systems, or academic labs. It is becoming part of mainstream consumer infrastructure because mainstream products rely on long chains of trust. If your operating system signs software updates, if your phone proves device state to a service, if your browser verifies certificates, or if your messaging app wants to limit future exposure from captured traffic, then PQC eventually becomes your problem whether you understand the acronyms or not. The countdown is visible first inside platform plumbing, not on consumer marketing pages.

What Organizations Actually Need To Do

The first task is inventory with a purpose. It is not enough to make a spreadsheet of cryptographic libraries. Teams need to know which business functions depend on quantum-vulnerable public-key cryptography, how long the protected data must remain confidential, and whether the system can be updated on a realistic schedule. That means ranking assets by exposure and longevity. Public websites with short-lived session keys do not carry the same profile as root certificate authorities, regulated archives, software-signing systems, industrial devices, or systems that broker identity across many downstream environments. The phrase "where are we using RSA or elliptic curve cryptography" is too broad. The better question is "where would a delayed migration create irrecoverable trust or confidentiality debt."

The second task is vendor pressure. The 2023 CISA, NSA, and NIST factsheet emphasizes supply-chain engagement for a reason (CISA, NSA, and NIST, 2023). Most organizations do not own the full stack. Their identity provider, browser fleet, VPN concentrator, endpoint tooling, code-signing service, HSM vendor, and embedded-product suppliers all influence the migration schedule. That makes contract language and roadmap scrutiny part of security work. A technically mature organization can still be delayed by one black-box dependency that has not published a credible hybrid or PQC roadmap.

The third task is crypto agility rather than brute-force replacement. In some systems, hybrid modes will be the bridge because they preserve classical compatibility while adding post-quantum protection. Apple describes PQ3 as hybrid by design. Google is doing the same with application signing and certificate evolution. The point is not ideological purity. The point is survivable transition. Pure post-quantum deployments may make sense in some controlled environments, but broad ecosystems often need intermediate formats, interoperability testing, and phased validation. The organizations that treat this as a capability to build, not a one-time swap, will move faster and break less.

The fourth task is calendar discipline. NIST's project page gives a 2035 outer timeline for removing quantum-vulnerable algorithms from its standards, but that is not an excuse to wait until the 2030s (NIST, 2025). High-risk systems move earlier, and vendor roadmaps, validation cycles, compliance work, and protocol updates all take time. If a company starts in 2032, it is not "cutting it close." It is likely already late, especially if it depends on external suppliers. Good security teams should interpret 2035 as a boundary marker, not as a recommended start date.

What Is Known, What Is Inferred, and What Is Still Unknown

What is known is straightforward. NIST finalized three major PQC standards in August 2024. NIST now says they should be used and plans to deprecate quantum-vulnerable algorithms by 2035. CISA, NSA, and NIST have all told organizations to inventory systems and prepare migration roadmaps. Apple, Google, and Microsoft have public documentation showing that mainstream platforms are already integrating post-quantum techniques into messaging, boot security, certificate services, app signing, and HTTPS experiments. Those are established facts from official sources.

What is inferred is the timetable for broad ecosystem conversion. It is reasonable to infer that consumer operating systems, large cloud vendors, and enterprise PKI tooling will continue to move first because they own strategic trust surfaces and can spread migration costs across large installed bases. It is also reasonable to infer that smaller organizations will migrate later and less cleanly, especially where they depend on appliances or older embedded systems. Those are evidence-based inferences from how previous crypto transitions have behaved and from the structure of the current roadmaps. They are not guaranteed dates.

What remains unknown is when a quantum computer capable of breaking widely deployed public-key cryptography will actually arrive. None of the official sources used here claim that capability exists today. That uncertainty does not weaken the migration case. It strengthens it. When the arrival date is uncertain but the replacement cycle is undeniably long, the rational response is to start before certainty arrives. Security programs are full of deadlines that cannot be negotiated once the window closes. Post-quantum cryptography is becoming one of them.

Bottom Line

Your passwords are not safe forever only in the limited sense that they live inside larger trust systems that are not safe forever under current public-key assumptions. The urgent work is not to panic about quantum laptops. It is to map where asymmetric cryptography sits inside real infrastructure, identify which secrets and trust anchors have long lifetimes, and move toward standards that are already finalized. The countdown is credible because the standards exist, the migration is slow, and the leading platforms have already stopped treating PQC as a science project.

The organizations that handle this well will not be the ones that predict the exact year of a cryptographically relevant quantum computer. They will be the ones that reduce dependence on brittle trust chains before the date matters. That is what the current official record points toward on June 1, 2026.

Key Takeaways

• Post-quantum risk is mainly about key exchange, certificates, signatures, and trust infrastructure, not about a quantum machine guessing your password directly.
• NIST finalized FIPS 203, FIPS 204, and FIPS 205 on August 13, 2024, which moved PQC from research into standards-based migration work.
• NIST now says organizations should begin applying these standards and plans to remove quantum-vulnerable algorithms from its standards by 2035, with higher-risk systems moving earlier.
• Cryptographic inventory and vendor engagement are the first practical steps because many organizations do not know where vulnerable public-key cryptography is embedded.
• Apple, Google, and Microsoft are already integrating PQC into messaging, Android trust chains, HTTPS certificate work, and enterprise certificate services.
• The exact arrival date of a code-breaking quantum computer is unknown, but the migration timeline is long enough that waiting for certainty is a bad strategy.

Sources

• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
• NIST Post-Quantum Cryptography Project
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards
• CISA, NSA, and NIST: Quantum-Readiness Migration to Post-Quantum Cryptography
• NIST NCCoE: Migration to Post-Quantum Cryptography FAQ
• Microsoft Learn: Post-Quantum Cryptography in AD CS Overview
• Apple Security Research: iMessage with PQ3
• Google Security Blog: Implementing Post-Quantum Cryptography in Android
• Google Security Blog: Cultivating a Robust and Efficient Quantum-Safe HTTPS

Keywords

post-quantum cryptography, ML-KEM, ML-DSA, quantum security, cryptographic inventory, quantum readiness, digital signatures, TLS certificates, Android security, iMessage PQ3, NIST PQC, crypto agility

Explore Lexicon Labs Books

Discover current releases, posters, and learning resources at LexiconLabs.store.

Purchase Social Media Physics

Stay Connected

Follow us on @leolexicon on X

Join our TikTok community: @lexiconlabs

Watch on YouTube: @LexiconLabs

Learn More About Lexicon Labs and sign up for the Lexicon Labs Newsletter to receive updates on book releases, promotions, and giveaways.