Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Post-quantum cryptography (PQC) is conventional cryptography designed to withstand attacks from future cryptographically relevant quantum computers. NIST finalized three PQC standards on August 13, 2024: ML-KEM for establishing shared secrets and ML-DSA and SLH-DSA for digital signatures. Organizations should begin discovery and planning now, but no single 2035, 2030, or 2027 date is a universal deadline for every company.
The dates come from different authorities and apply to different populations. NIST’s stated 2035 horizon concerns removing quantum-vulnerable algorithms from its standards; NSA’s 2027 and 2030 milestones apply to national security systems under CNSA 2.0. Migration also involves inventories, certificates, protocols, products, vendors, testing and long-lived data—not simply replacing one algorithm with another.
What is post-quantum cryptography?
Post-quantum cryptography refers to public-key algorithms intended to resist attacks by future cryptographically relevant quantum computers while running on ordinary computers, networks and software. It is not quantum cryptography and does not require a quantum communication channel. Quantum key distribution, for example, is a different technology and is not what the NIST standards discussed here specify.
The first NIST standards address two public-key jobs:
#1 Best Overall
- Key establishment: allowing two parties to derive a shared secret over a public channel so they can protect a session.
- Digital signatures: allowing recipients to authenticate a signer and detect unauthorized modification.
Public-key cryptography is embedded in web protocols, virtual private networks, email, identity systems, software updates, certificates, appliances, cloud services and operational technology. That breadth is why PQC migration is a program of discovery and engineering rather than a one-line configuration change.
There is no established date for a machine capable of breaking today’s widely deployed public-key systems. Estimates vary, and the arrival of a cryptographically relevant quantum computer is not a settled schedule. The present concern is that systems often protect information for many years, while their public-key dependencies can be difficult to locate and replace.
Which PQC standards has NIST finalized?
The U.S. Secretary of Commerce approved three Federal Information Processing Standards (FIPS), published by NIST on August 13, 2024. Two are lattice-based standards and one is stateless hash-based. Their functions and maturity are different from later candidates and from transition guidance.
| Standard | Algorithm | Primary function | Origin | Status |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | Key establishment: derives a shared secret over a public channel | Derived from CRYSTALS-KYBER | Final FIPS standard, August 13, 2024 |
| FIPS 204 | ML-DSA | Digital signatures for authentication and integrity | Derived from CRYSTALS-Dilithium | Final FIPS standard, August 13, 2024 |
| FIPS 205 | SLH-DSA | Stateless hash-based digital signatures | Derived from SPHINCS+ | Final FIPS standard, August 13, 2024 |
FIPS 203: ML-KEM
ML-KEM is the NIST-standardized mechanism for establishing a shared secret. A sender can use a recipient’s public information to create a ciphertext; the recipient uses the corresponding private information to recover the same secret. Applications then use that secret with their existing symmetric protection for a session. The standard does not by itself retrofit every protocol or certificate system that currently uses RSA or elliptic-curve key exchange.
FIPS 204: ML-DSA
ML-DSA is a digital-signature standard. Signatures let a verifier determine whether data was signed by the expected private-key holder and whether it changed after signing. Replacing an existing signature scheme can affect certificate profiles, trust stores, firmware-signing systems, code-signing services and protocol negotiation, so compatibility testing is part of adoption.
FIPS 205: SLH-DSA
SLH-DSA is a stateless hash-based signature standard derived from SPHINCS+. It provides a different design approach from ML-DSA and gives implementers an additional standardized signature option. Its suitability depends on the application’s protocol, implementation and operational constraints.
Rank #2
What about HQC?
NIST selected HQC for standardization as a backup key-establishment algorithm on March 11, 2025. HQC is not one of the three finalized FIPS standards listed above. A selection for standardization should therefore not be represented as a currently approved FIPS replacement or as a reason to delay inventory and planning.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →When should organizations start migrating to post-quantum cryptography?
Start with preparation now. CISA, NSA and NIST state in their August 17, 2023 quantum-readiness fact sheet that “A successful post-quantum cryptography migration will take time to plan and conduct.” Their guidance recommends a roadmap, an inventory of cryptographic use, risk assessment and engagement with vendors before final deployment decisions.
Beginning now does not mean enabling every new algorithm in production immediately. It means making the dependencies visible, identifying information that must remain confidential for a long time, confirming supplier support and creating a testable sequence for replacement.
- Assign ownership. Establish an executive sponsor and a working group spanning security, infrastructure, application engineering, identity, procurement, legal or compliance, and operational technology where relevant.
- Set a migration roadmap. Define how discovery, risk ranking, laboratory testing, pilot deployment, production rollout and retirement of vulnerable options will be approved and recorded.
- Inventory cryptography. Record where public-key algorithms, protocols, certificates, keys and cryptographic libraries are used, including systems managed by suppliers.
- Prioritize exposure. Rank assets by mission criticality, data sensitivity, confidentiality lifetime, external exposure, replacement difficulty and supplier readiness.
- Engage vendors. Ask for supported standards, protocol plans, dependency maps, lifecycle controls, test evidence and product retirement dates.
- Test interoperability. Validate negotiation, certificate chains, signatures, key exchange, logging, monitoring, backup and recovery in representative environments.
- Roll out in controlled stages. Use pilots and rollback plans, then update standards, procurement language and architecture baselines as production support matures.
What is the NIST PQC migration timeline?
NIST’s transition material should be read as standards guidance, not as a blanket private-sector compliance rule. NIST IR 8547 is listed as an initial public draft, published November 12, 2024. NIST’s PQC project guidance describes an end-state in which quantum-vulnerable algorithms are deprecated and ultimately removed from NIST standards by 2035, with higher-risk systems expected to transition earlier.
A draft transition plan can influence architecture and procurement decisions, but it does not automatically impose a legal deadline on an organization. A company’s binding obligations may instead come from a contract, sector regulation, national rule, customer requirement or an authority that specifically applies to its systems. Check the current status of NIST publications and any rule that actually governs your environment.
What do the 2035, 2030 and 2027 dates apply to?
These dates are often combined in headlines even though they have different issuers and scopes.
| Date | Authority and document | What it means | Who it covers | What it does not mean |
|---|---|---|---|---|
| 2035 | NIST PQC project guidance, including the transition direction associated with IR 8547 | Stated horizon for deprecating and removing quantum-vulnerable algorithms from NIST standards; higher-risk systems move earlier | Organizations that rely on NIST standards or use them as a planning reference | Not a universal statutory deadline for every private company |
| 2027 | NSA CNSA 2.0 guidance | New commercial national security systems must support NSA’s quantum-resistant algorithms | National security systems (NSS) | Not a date for ordinary commercial, consumer or non-NSS systems |
| 2030 | NSA CNSA 2.0 guidance | Legacy national security systems are scheduled for phaseout under the CNSA 2.0 transition | Legacy NSS | Not a general deadline for all sectors |
Procurement teams should ask which authority, contract or policy gives a date its force. If no applicable instrument names your organization, present these milestones as planning signals rather than claim that the organization is already out of compliance.
What is a harvest-now-decrypt-later attack?
In a harvest-now-decrypt-later scenario, an adversary records encrypted traffic or obtains encrypted files today and attempts to decrypt them in the future when a sufficiently capable quantum computer exists. The attack is most relevant to information whose confidentiality period extends for years or decades, such as strategic plans, personal records, health data, intellectual property, credentials, diplomatic material and long-lived archives.
The risk exists before a cryptographically relevant quantum computer is available because collection and decryption happen at different times. A network may appear secure against today’s attacks while the captured ciphertext remains valuable to a future attacker.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCISA, NSA and NIST also emphasize that public-key cryptography is spread across products, protocols and services, including deployments using RSA, ECDH and ECDSA. A mitigation plan therefore has to consider traffic capture points, stored archives, backups, third-party processing and the length of time each data class must remain secret.
How do I create a cryptographic inventory?
NIST describes an inventory as a record of cryptography across systems, applications, services, devices and data flows. It should contain metadata and relationships, not private key material. Use the following process to turn a list of algorithms into an actionable dependency map.
1. Define scope and owners
List business services, environments and suppliers in scope. Assign an owner who can answer what a system protects, how it communicates, when it can be changed and which supplier controls the implementation. Include information technology, operational technology and procurement representatives.
Rank #4
2. Discover cryptographic use
Search configuration, source dependencies, certificates, protocol settings, API gateways, identity platforms, network appliances, mobile or embedded software, backup systems and managed services. Ask suppliers to identify cryptography hidden behind an abstraction or delivered as a hosted service.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →3. Record useful fields
- Algorithm and mode, such as RSA, ECDH or ECDSA where present
- Protocol and application using it
- Key and certificate identifiers, owners, purpose, size or parameter set, creation date, expiry and rotation process
- Cryptographic library, hardware module, appliance, cloud service or supplier dependency
- Data flows, trust relationships and downstream consumers
- Whether the component supports ML-KEM, ML-DSA or SLH-DSA, and under which product version
- Data classification and the period for which confidentiality or signature validity is required
4. Map dependencies
Connect certificates to issuing authorities and applications, applications to libraries and libraries to operating-system or hardware versions. Record where a protocol negotiates algorithms and where a change could break a partner, customer or device.
5. Prioritize long-lived and critical data
Flag information that must remain confidential beyond the likely replacement cycle of the system. Give higher priority to systems with sensitive data, broad external exposure, difficult hardware refreshes, long procurement cycles or a single supplier with no documented PQC plan.
6. Keep the inventory current
Treat the register as a maintained control. Update it during architecture reviews, certificate renewals, acquisitions, software releases, supplier changes and incident response. An inventory that becomes stale cannot support a credible migration decision.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should I ask vendors about quantum readiness?
Procurement questionnaires should test evidence and dependencies rather than accept a marketing statement that a product is “quantum safe.” Ask for answers tied to versions, protocols and support dates.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Area | Questions to ask |
|---|---|
| Discovery coverage | Can the product identify cryptographic use in applications, devices, hosted services and embedded components? What is excluded? |
| Inventory and dependencies | Can it record algorithms, certificates, key lifecycle metadata, owners, data flows and upstream or downstream dependencies without collecting private key material? |
| Standards support | Which released versions implement FIPS 203 ML-KEM, FIPS 204 ML-DSA or FIPS 205 SLH-DSA? Are the implementations validated, experimental or scheduled? |
| Interoperability | Which protocols, certificate profiles, identity systems and partner products have been tested together? How are algorithm negotiation and mixed-version environments handled? |
| Performance evidence | What benchmarking methodology, hardware, workloads and parameter sets produced the results? Can your team reproduce the tests? |
| Lifecycle and support | How are key generation, rotation, revocation, backup, recovery, logging and incident response handled? What are the support and retirement dates for each relevant version? |
| Roadmap transparency | How will the supplier respond to NIST updates, additional standards such as HQC and changes in customer or regulatory requirements? |
NIST’s National Cybersecurity Center of Excellence work explicitly includes visibility and risk management, as well as interoperability and benchmarking. Those workstreams are useful criteria for evaluating a discovery or migration service, but they are not a product endorsement.
What are the main migration risks?
Hidden or inherited cryptography
Teams often know the algorithm in a flagship application but not in a load balancer, certificate authority, software-update process, backup appliance or supplier-managed component. Missing one dependency can prevent a complete migration or create an unmonitored vulnerable path.
Protocol and certificate incompatibility
Changing a key-establishment or signature algorithm can affect message formats, certificate chains, trust stores, hardware modules and counterparties. A component that supports a new algorithm in isolation may still fail when combined with an older peer.
Long-lived and constrained systems
Embedded devices, industrial equipment and archived data may remain in service longer than ordinary application software. Their replacement, firmware-signing and maintenance processes need early attention because a later emergency upgrade may be impractical.
Unclear standards maturity
Final FIPS standards, selected-for-standardization algorithms and draft transition guidance are not interchangeable. Record the status of each dependency so a pilot does not accidentally become a production requirement based on a draft.
Supplier and contract delays
A company can complete its own software changes and still be blocked by a certificate provider, managed service, partner protocol or hardware supplier. Put support commitments, notification duties, testing access and end-of-support dates into procurement and renewal discussions.
Assuming a drop-in replacement
PQC changes can alter key and signature sizes, message handling, certificate policy, performance and operational procedures. Even when an API looks familiar, test the complete protocol and lifecycle rather than swapping a library call and declaring the migration complete.
Where can you start your migration to PQC?
A practical starting sequence is:
- Within governance: name an accountable owner, define the systems and data in scope, and document which external rules or contracts actually apply.
- Within discovery: build the cryptographic inventory and identify RSA, ECDH, ECDSA and other public-key uses, including supplier-managed components.
- Within risk: mark information with long confidentiality lifetimes and systems that are difficult to replace, externally exposed or mission critical.
- Within architecture: map protocol, certificate, key-lifecycle and hardware dependencies before selecting a replacement.
- Within supplier management: obtain version-specific support statements, interoperability evidence, benchmark methods and lifecycle commitments.
- Within engineering: test ML-KEM, ML-DSA and SLH-DSA where appropriate in representative environments, with monitoring and rollback procedures.
- Within operations: update standards, runbooks, incident procedures, procurement clauses and the inventory as systems change.
NIST’s FAQ also names The PQC Migration Handbook: Guidelines for Migrating to Post-Quantum Cryptography as an additional resource. Treat any retail or edition information separately from the technical guidance; the standards and agency documents remain the authoritative references for the dates and algorithms described here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
