Cyber Security
Post-Quantum Cryptography is a new generation of security algorithms designed to protect digital information from attacks by future large-scale quantum computers. Although these algorithms address a future threat, they run on conventional computers, servers, phones, networking equipment, and security devices.
Today, public-key cryptography protects websites, virtual private networks, software updates, digital certificates, email, financial transactions, cloud services, and connected devices. However, a sufficiently capable quantum computer could threaten several public-key algorithms that organisations currently depend on.
Therefore, businesses cannot wait until such a computer becomes available before beginning their transition. A complete migration may involve software, hardware, protocols, certificates, vendors, policies, and long-lived data.
Post-Quantum Cryptography: Quick Answer
- Post-Quantum Cryptography uses algorithms designed to resist attacks from classical and future quantum computers.
- It runs on current computers and does not require quantum hardware.
- It mainly replaces vulnerable public-key cryptography used for key establishment and digital signatures.
- NIST published its first three final PQC standards in 2024 for shared-secret establishment and digital signatures.
- Organisations should begin preparation now because cryptographic migrations can take several years.
- Long-lived confidential data faces an earlier risk from attackers collecting encrypted information today for possible future decryption.
In practice, post-quantum preparation should begin with discovery, risk assessment, planning, testing, and vendor coordination. Organisations should also avoid custom cryptographic designs and use maintained implementations based on recognised standards.
What Is Post-Quantum Cryptography?
Post-Quantum Cryptography, commonly shortened to PQC, refers to cryptographic algorithms designed to remain secure even when an attacker has access to a cryptographically relevant quantum computer.
Despite its name, post-quantum technology does not work only after quantum computers arrive. Instead, organisations can deploy these algorithms now through familiar software and hardware environments.
For example, developers can eventually integrate PQC into web protocols, operating systems, security libraries, applications, identity platforms, hardware security modules, and connected devices.
Most importantly, the goal is to replace or supplement public-key systems that could become vulnerable while preserving practical security against current classical computers.
What Is Quantum Computing?
A classical computer processes information through bits that represent values such as zero or one. In contrast, a quantum computer uses quantum bits, commonly called qubits, which follow principles of quantum mechanics.
Quantum computers do not make every computing task instantly faster. Nevertheless, specialised quantum algorithms can approach certain mathematical problems more efficiently than classical systems.
This difference matters because widely used cryptographic systems rely on mathematical problems that are extremely difficult for current computers. Consequently, a sufficiently powerful and stable quantum computer could weaken some of those protections.
Researchers continue to improve quantum hardware, control systems, error correction, and algorithms. However, the exact date when a cryptographically relevant quantum computer may become available remains uncertain.
Why Quantum Computers Threaten Public-Key Cryptography
Public-key cryptography uses related public and private keys. A public key can be shared openly, whereas the corresponding private key must remain secret.
These systems support secure key establishment, digital signatures, authentication, and certificate-based trust. Their security depends on mathematical problems that are difficult to reverse without the private key.
However, a sufficiently capable quantum computer could solve several of those problems much more efficiently. As a result, systems based on integer factorisation or certain discrete-logarithm problems could become unsafe.
This concern affects technologies based on RSA, finite-field Diffie-Hellman, elliptic-curve Diffie-Hellman, DSA, and elliptic-curve digital signatures.
Which Systems Could Be Affected?
Quantum-vulnerable public-key algorithms appear throughout modern technology. For instance, they may protect or authenticate:
- HTTPS connections and website certificates.
- Virtual private networks and remote access.
- Secure Shell connections.
- Email encryption and signing.
- Software and firmware updates.
- Mobile and desktop application packages.
- Cloud-service connections.
- Certificate authorities and identity systems.
- Smart cards and hardware tokens.
- Payment systems and financial messaging.
- Connected vehicles and Internet of Things devices.
- Industrial equipment and operational technology.
- Document signatures and long-term archives.
- Blockchain and distributed-ledger systems.
Moreover, organisations do not configure every cryptographic operation directly. Security functions may be embedded inside operating systems, libraries, databases, appliances, cloud platforms, network equipment, and vendor-managed applications.
Public-Key Cryptography vs Symmetric Cryptography
Public-key cryptography uses separate public and private keys. Symmetric cryptography, on the other hand, uses the same secret key or closely related secret material for encryption and decryption.
Quantum computing creates the most significant concern for several widely used public-key algorithms. Symmetric encryption and secure hash functions are also affected by quantum search techniques, although the impact is different.
In many cases, organisations can address the symmetric-key risk by using appropriate algorithms and larger security parameters. Therefore, PQC standards primarily focus on replacing vulnerable public-key key-establishment and digital-signature algorithms.
Even after migration, strong symmetric encryption, secure hashing, authenticated encryption, random-number generation, and key management will remain essential.
What Is Harvest Now, Decrypt Later?
Harvest now, decrypt later describes an attack in which an adversary collects encrypted information today and stores it for possible future decryption.
At present, the attacker may be unable to break the captured communication. However, a future quantum computer could potentially defeat the public-key protection that established the encryption keys.
As a result, stored communications may become readable years after they were originally collected. This risk matters most when information must remain confidential for a long time.
Examples may include government records, intellectual property, research, legal documents, healthcare information, financial data, authentication material, and strategic business plans.
Therefore, the risk can begin before a cryptographically relevant quantum computer exists. Organisations should compare the required confidentiality lifetime of their data with the expected duration of their migration.
Why Migration Must Begin Early
Cryptographic technology is deeply embedded in software, hardware, protocols, certificates, and supply chains. Consequently, replacing it across a large organisation may require years of discovery, procurement, development, testing, rollout, and retirement.
In addition, some equipment remains operational for a decade or longer. Industrial systems, vehicles, medical devices, network appliances, satellites, and embedded products may not support simple software upgrades.
Organisations also depend on vendors, certificate authorities, cloud providers, standards bodies, operating systems, and business partners. Therefore, one company cannot complete the transition independently when an important product or protocol lacks suitable support.
By starting early, teams can identify those dependencies before deadlines or emergency security events create unnecessary pressure.
What Is a Cryptographically Relevant Quantum Computer?
A cryptographically relevant quantum computer is a quantum system capable of performing the calculations required to threaten deployed cryptographic algorithms.
Experimental quantum computers already exist. Nevertheless, a system capable of breaking widely used public-key cryptography would require substantial scale, reliability, error correction, and sustained operation.
No reliable timeline predicts exactly when that capability will arrive. Therefore, organisations should focus on data lifetimes, equipment replacement cycles, vendor readiness, and migration complexity rather than depending on one forecasted date.
Post-Quantum Cryptography Is Not Quantum Cryptography
Post-Quantum Cryptography and quantum cryptography are different concepts.
PQC uses mathematical algorithms that run on conventional computing systems. Its purpose is to protect information against attackers using either classical or quantum computers.
Quantum cryptography, meanwhile, uses quantum-mechanical properties for communication or key-distribution systems. As a result, it may require specialised optical equipment, communication channels, and operating environments.
For most organisations, standards-based PQC provides a more practical starting point because it can be introduced into familiar digital infrastructure.
How Post-Quantum Cryptography Works
PQC algorithms rely on mathematical problems that researchers believe remain difficult for both classical and quantum computers.
Different algorithm families use different mathematical foundations. Consequently, this diversity may provide additional resilience if researchers later discover weaknesses in one approach.
Two important PQC functions are:
- Key establishment: Allows two parties to create shared secret material for secure communication.
- Digital signatures: Allow a recipient to verify who signed information and whether it was modified.
A key-establishment algorithm does not normally encrypt every application message directly. Instead, it establishes secret material that an efficient symmetric algorithm can use to protect the main communication.
Similarly, a digital-signature algorithm does not hide the content. Rather, it allows recipients to verify authenticity and integrity.
What Is a Key-Encapsulation Mechanism?
A key-encapsulation mechanism, commonly called a KEM, allows two parties to establish a shared secret through a public communication channel.
A simplified process works as follows:
- One party creates a public key and private key.
- The public key is shared with another party.
- The second party uses the public key to create a ciphertext and shared secret.
- The first party uses the private key to recover the same shared secret.
- Both parties derive symmetric encryption keys from that secret.
Afterwards, the application can use those symmetric keys with an authenticated encryption algorithm.
What Is a Post-Quantum Digital Signature?
A post-quantum digital signature allows a signer to create a signature designed to resist forgery by an attacker with a powerful quantum computer.
The signer uses a private key to sign a message, certificate, software package, transaction, or document. Subsequently, a recipient uses the corresponding public key to verify the signature.
Digital signatures can protect software updates, firmware, documents, certificates, identities, transactions, messages, and audit records.
However, post-quantum public keys and signatures may be larger than familiar classical alternatives. Therefore, migration can affect certificates, protocols, storage, bandwidth, hardware tokens, and constrained devices.
NIST Post-Quantum Cryptography Standards
In August 2024, the United States National Institute of Standards and Technology published its first three final Post-Quantum Cryptography standards.
| Standard | Algorithm | Main Purpose |
|---|---|---|
| FIPS 203 | ML-KEM | Establishing shared secret keys |
| FIPS 204 | ML-DSA | General-purpose digital signatures |
| FIPS 205 | SLH-DSA | Hash-based digital signatures |
These standards provide approved specifications that security libraries, protocol developers, product vendors, and organisations can begin adopting.
What Is ML-KEM?
ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism. It is the standardised form of the algorithm previously known as CRYSTALS-Kyber.
ML-KEM establishes shared secret material through a public channel. Applications can then use that secret with symmetric cryptography to protect data.
FIPS 203 defines three parameter sets:
ML-KEM-512ML-KEM-768ML-KEM-1024
Each parameter set provides different security and performance characteristics. Therefore, implementers should follow applicable standards, protocol profiles, platform guidance, and regulatory requirements.
What Is ML-DSA?
ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. It is the standardised form of the algorithm previously known as CRYSTALS-Dilithium.
The algorithm is designed for general-purpose digital signatures. For example, it can help protect certificates, software, firmware, messages, documents, and transactions.
Several parameter sets provide different key sizes, signature sizes, performance characteristics, and security levels. Consequently, applications should use maintained libraries and approved profiles rather than selecting parameters without technical guidance.
What Is SLH-DSA?
SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. It is based on the SPHINCS+ algorithm family.
Unlike ML-DSA, SLH-DSA relies primarily on the security properties of hash functions. Therefore, it provides mathematical diversity among the standardised signature options.
Its signatures can be substantially larger than those created by some alternatives. Nevertheless, its different security foundation can be valuable when long-term confidence and algorithm diversity are priorities.
Current and Future PQC Standards
The first three final standards do not mark the end of the standardisation process. NIST continues developing additional algorithms and implementation guidance.
For example, FN-DSA, based on Falcon, is being developed as an additional digital-signature standard. Meanwhile, NIST selected HQC as another key-encapsulation mechanism for future standardisation.
Therefore, organisations should distinguish between final standards, draft standards, selected candidates, experimental implementations, and vendor-specific products.
Post-Quantum Cryptography Standards Comparison
| Algorithm | Function | Foundation | Status |
|---|---|---|---|
| ML-KEM | Key encapsulation | Module lattices | Final NIST standard |
| ML-DSA | Digital signatures | Module lattices | Final NIST standard |
| SLH-DSA | Digital signatures | Hash-based cryptography | Final NIST standard |
| HQC | Key encapsulation | Code-based cryptography | Selected for future standardisation |
| FN-DSA | Digital signatures | NTRU lattice-based cryptography | Standard under development |
Finally, production decisions should follow current standards and implementation guidance. Teams should not assume that every algorithm mentioned in research or marketing material is ready for operational use.
Post-Quantum Migration Is a System Change
A post-quantum migration is not a simple search-and-replace operation. Instead, cryptography affects protocols, certificates, identities, message sizes, software packages, hardware modules, network equipment, compliance, and external integrations.
An algorithm may work correctly in a test application but fail inside a certificate chain, smart card, network packet, constrained device, or legacy protocol. Therefore, teams must evaluate the complete operating environment.
In addition, migration requires cooperation between security teams, developers, infrastructure engineers, network administrators, architects, procurement specialists, risk managers, legal teams, and product vendors.
Each group controls a different part of the cryptographic dependency chain. Consequently, no single team can complete the transition alone.
Step 1: Build a Cryptographic Inventory
A cryptographic inventory records where and how an organisation uses cryptography. It should include algorithms, keys, certificates, protocols, libraries, products, owners, data types, dependencies, and replacement limitations.
Importantly, teams should look beyond application source code. Cryptography may exist inside:
- Web servers and load balancers.
- API gateways and service meshes.
- VPN appliances and remote-access tools.
- Operating systems and mobile platforms.
- Databases and backup systems.
- Cloud services and managed platforms.
- Certificate authorities and identity providers.
- Hardware security modules.
- Smart cards and security tokens.
- Software-signing and release pipelines.
- Network switches, routers, and firewalls.
- Industrial controllers and embedded devices.
- Third-party applications and software libraries.
- Partner integrations and data-exchange systems.
Without a complete inventory, hidden vulnerable systems may remain active after the organisation believes that migration is finished.
What to Record in a Cryptographic Inventory
| Inventory Field | Example Information |
|---|---|
| System or asset | Website, payment API, VPN gateway, or signing server |
| Business owner | Team responsible for the service |
| Technical owner | Team able to update the implementation |
| Algorithm | RSA, ECDSA, ECDH, ML-KEM, or ML-DSA |
| Cryptographic function | Key establishment, encryption, signing, or verification |
| Protocol or format | TLS, SSH, VPN, certificate, or signed package |
| Library or product | Security library, appliance, operating system, or cloud service |
| Key location | HSM, key vault, secure element, file, or device storage |
| Data sensitivity | Public, internal, confidential, regulated, or long-lived secret |
| Required confidentiality period | Months, years, or decades |
| Replacement method | Configuration, software update, firmware update, or hardware replacement |
| Vendor readiness | Supported, planned, unknown, or unsupported |
Automated Cryptographic Discovery
Manual surveys can identify important systems. However, they may miss cryptography hidden inside binaries, libraries, containers, certificates, managed services, and network traffic.
Automated discovery tools can analyse source code, application packages, file systems, certificates, configurations, and observed connections.
Nevertheless, one tool is unlikely to find every cryptographic dependency. Proprietary products may expose limited details, while dynamic behaviour may not appear during a short scan.
Therefore, organisations should combine automated discovery with architecture reviews, code analysis, certificate records, network observations, vendor questionnaires, and interviews with system owners.
Step 2: Identify Quantum-Vulnerable Algorithms
After creating the inventory, teams should classify systems that depend on quantum-vulnerable public-key cryptography.
Priority areas commonly include:
- RSA key establishment and digital signatures.
- Finite-field Diffie-Hellman key exchange.
- Elliptic-curve Diffie-Hellman key exchange.
- DSA digital signatures.
- ECDSA digital signatures.
- Public-key certificates using vulnerable signatures.
- Long-lived signed software and firmware.
- Encrypted data that must remain confidential for many years.
At the same time, the inventory should record symmetric algorithms, hash functions, protocol versions, key lengths, and random-number generation. A migration may reveal weaknesses unrelated to quantum computing.
Step 3: Prioritise Systems by Risk
Not every system needs to migrate at the same time. For example, a public marketing page and a platform protecting long-lived confidential information do not carry the same risk.
Useful prioritisation factors include:
- The confidentiality lifetime of protected information.
- The importance of signed software or records.
- The expected lifetime of the system.
- The time required to replace or update it.
- The likelihood that an attacker can collect encrypted traffic.
- The impact of a forged signature or certificate.
- The availability of supported upgrades.
- Regulatory and contractual requirements.
- Exposure to the internet or untrusted networks.
- The availability of temporary compensating controls.
Consequently, systems protecting long-lived secrets or software authenticity may need attention before short-term, low-impact services.
Cryptographic Lifespan Planning
A practical planning model compares three periods:
- Data lifetime: How long must the information remain confidential or trustworthy?
- Migration time: How long will discovery, procurement, testing, and deployment take?
- Threat arrival: When might a cryptographically relevant quantum computer become available?
The threat-arrival date remains uncertain. However, organisations can estimate their data lifetime and migration duration.
For instance, if data must remain confidential for fifteen years and migration may take five years, waiting for a visible quantum breakthrough could leave too little time.
Step 4: Create a Vendor Readiness Plan
Most organisations depend on vendor products for cryptographic functions. Therefore, they should request specific technical information instead of accepting broad statements that a product is “quantum ready.”
Useful questions include:
- Which final PQC standards does the product support?
- Which software or firmware version provides that support?
- Does the implementation use a maintained or validated cryptographic library?
- Which protocols and deployment modes use PQC?
- Does the product support an approved hybrid approach?
- Can administrators disable experimental algorithms?
- How are keys generated, stored, rotated, and destroyed?
- What are the key, signature, ciphertext, and certificate size limits?
- Will existing hardware receive updates?
- Which product models require replacement?
- How will interoperability testing be performed?
- What is the long-term maintenance timeline?
Furthermore, procurement teams should record vendor commitments in contracts and product-lifecycle systems.
Step 5: Improve Crypto Agility
Crypto agility is the ability to replace or adapt cryptographic algorithms, protocols, keys, and parameters without redesigning the complete system or causing an extended interruption.
A crypto-agile application separates business logic from cryptographic implementation. As a result, teams can change approved algorithms through controlled policies instead of rewriting code throughout the application.
Crypto agility may include:
- Central cryptographic policy management.
- Versioned protocols and message formats.
- Secure algorithm negotiation.
- Replaceable cryptographic libraries.
- Key and certificate rotation procedures.
- Automated inventory and compliance reporting.
- Backward-compatible migration paths.
- Feature flags for controlled deployment.
- Rapid rollback when an implementation fails.
- Testing against several approved algorithms.
However, agility does not mean accepting any algorithm selected by another system. Negotiation must remain restricted to approved and correctly configured choices.
Avoid Hard-Coded Cryptographic Assumptions
Applications become difficult to migrate when algorithm names, key lengths, signature sizes, and certificate formats are assumed throughout the codebase.
For example, a database field created for a small classical signature may not store a larger post-quantum signature. Similarly, a fixed network buffer may reject a larger key or certificate chain.
Therefore, developers should avoid unnecessary assumptions about:
- Public-key length.
- Private-key length.
- Signature length.
- Ciphertext length.
- Certificate-chain size.
- Handshake-message size.
- Algorithm identifiers.
- Security-provider names.
Instead, systems should use explicit lengths, versioning, standards-based encodings, and carefully designed validation limits.
Step 6: Test PQC Implementations
Testing should cover more than whether two endpoints complete a cryptographic operation successfully.
In addition, teams should evaluate:
- Key-generation performance.
- Encapsulation and decapsulation time.
- Signing and verification time.
- Memory consumption.
- Processor utilisation.
- Network handshake size.
- Certificate-chain size.
- Storage requirements.
- Hardware-token and HSM support.
- Mobile and embedded-device performance.
- Behaviour under high request volume.
- Interoperability between vendors.
- Failure handling and rollback.
An algorithm may perform well on a server but create unacceptable latency, memory use, or packet fragmentation on a constrained device. Consequently, realistic environment testing is essential.
Key and Signature Size Challenges
Many post-quantum algorithms use larger public keys, ciphertexts, or signatures than familiar elliptic-curve algorithms.
As a result, larger cryptographic objects can affect:
- TLS and VPN handshakes.
- Certificate authorities and certificate chains.
- DNS-based security protocols.
- Smart cards and hardware tokens.
- Embedded and Internet of Things devices.
- Software packages and firmware images.
- Network packet fragmentation.
- Database fields and message queues.
- QR codes and offline transfer formats.
- Bandwidth-limited networks.
Therefore, teams should test complete protocols and deployment environments rather than comparing isolated algorithm benchmarks.
Protocol Compatibility
A cryptographic algorithm cannot protect a connection unless the surrounding protocol defines how to identify, negotiate, encode, transmit, and validate it.
Protocols and applications may require support for:
- New algorithm identifiers.
- Larger handshake messages.
- Hybrid key-establishment values.
- Post-quantum certificate signatures.
- Updated certificate extensions.
- Revised security policies.
- New fallback and error behaviour.
For this reason, teams should use maintained protocol implementations instead of inventing custom production formats.
What Is Hybrid Cryptography?
A hybrid approach combines a classical algorithm with a post-quantum algorithm during a transition period.
For key establishment, the system may combine secret material from both methods. Therefore, the resulting session can retain protection when at least one properly combined component remains secure.
Hybrid deployments can support gradual adoption while organisations gain operational experience. However, they also increase message size, complexity, testing requirements, and the number of possible failure cases.
Consequently, hybrid designs should follow recognised protocol specifications and platform guidance.
Hybrid Does Not Mean Permanent
A hybrid mode can provide a useful transition path. Nevertheless, organisations still need a plan for future algorithm changes.
The classical component may eventually be removed after standards, interoperability, product support, and policy allow a complete post-quantum deployment.
Likewise, a selected PQC algorithm may need replacement if researchers discover weaknesses or if operational problems emerge. Therefore, crypto agility remains necessary after the first migration.
Public-Key Infrastructure Migration
Public-key infrastructure manages certificates, trust anchors, certificate authorities, enrolment, identity verification, and revocation.
A post-quantum PKI migration may affect:
- Root and intermediate certificate authorities.
- Public website certificates.
- Private enterprise certificates.
- Code-signing certificates.
- Device and machine identities.
- Smart-card certificates.
- Certificate enrolment protocols.
- Revocation lists and status services.
- Certificate monitoring.
- Trust stores in operating systems and applications.
Because larger public keys and signatures can increase certificate-chain sizes, every client, server, appliance, and validation service must be tested.
Software and Firmware Signing
Digital signatures protect the integrity and origin of applications, drivers, firmware, containers, mobile packages, and software updates.
A future attacker capable of forging a vulnerable signature might create a malicious update that appears authentic. Therefore, long-lived devices and update ecosystems require early migration planning.
Teams should review:
- Build and release pipelines.
- Code-signing keys and HSMs.
- Bootloaders and secure-boot systems.
- Firmware-verification code.
- Offline recovery images.
- Update servers and distribution platforms.
- Long-term signature validation.
- Key-rotation and emergency-revocation procedures.
In particular, a device cannot accept a new signature algorithm when its immutable verification code does not support it. Hardware replacement may therefore become necessary.
Post-Quantum Cryptography for TLS
TLS protects website and API connections by combining authentication, key establishment, symmetric encryption, and integrity protection.
A post-quantum transition can update the key-establishment portion, certificate signatures, or both. However, these changes may occur on different timelines because they involve different standards and compatibility requirements.
During early deployment, a recognised hybrid key-establishment method can combine classical and post-quantum secrets.
Administrators should rely on supported browsers, servers, operating systems, libraries, load balancers, and cloud platforms rather than creating custom TLS modifications.
Post-Quantum Cryptography for VPNs
VPN technologies use public-key operations to authenticate endpoints and establish symmetric session keys.
Migration may therefore require changes to VPN clients, concentrators, gateways, certificates, configuration profiles, authentication servers, and management tools.
Because remote-access environments contain many devices and operating systems, staged compatibility testing is essential.
In addition, organisations should determine whether older network appliances can receive suitable firmware or require replacement.
Post-Quantum Cryptography for Cloud Services
Cloud environments contain many cryptographic layers, including external TLS, internal service connections, identity tokens, databases, backups, managed keys, and signing systems.
Therefore, customers should ask providers which layers support final PQC standards. Support at one public endpoint does not necessarily mean that every internal service uses post-quantum protection.
Moreover, organisations remain responsible for understanding how their own applications, data, certificates, and integrations use cryptography.
Post-Quantum Cryptography for IoT and Embedded Devices
Connected devices may have limited storage, memory, processor capacity, bandwidth, and power. At the same time, they may remain deployed for many years.
These constraints create several challenges:
- Large keys or signatures may exceed available storage.
- Firmware-verification code may be difficult to update.
- Low-power processors may verify signatures slowly.
- Network packets may exceed transport limits.
- Devices may lack secure update mechanisms.
- Vendor support may end before migration finishes.
Consequently, new device designs should include algorithm agility, secure updates, sufficient storage, and a realistic long-term support plan.
Post-Quantum Cryptography for Operational Technology
Operational technology includes manufacturing equipment, energy systems, building controls, industrial processes, and other systems connected to physical operations.
These environments often prioritise availability, safety, and predictable behaviour. Therefore, an untested cryptographic change can create serious operational risk.
Migration planning should include asset discovery, vendor support, maintenance windows, safety reviews, protocol testing, rollback procedures, and temporary compensating controls.
Post-Quantum Cryptography for Long-Term Archives
Archived information may need confidentiality, integrity, and signature validity for decades.
Encryption protects confidentiality, whereas digital signatures protect authenticity and integrity. Consequently, archives may require separate migration strategies for each function.
Organisations may need to re-encrypt stored information, re-wrap data-encryption keys, renew certificates, apply trusted timestamps, or re-sign important records.
Furthermore, archive systems should preserve algorithm identifiers, certificate chains, revocation information, timestamps, and validation evidence.
Post-Quantum Cryptography and Passwords
PQC does not directly replace passwords. Password security still depends on password hashing, rate limiting, multi-factor authentication, recovery controls, and credential protection.
However, public-key cryptography may protect the connection used to submit a password or support passkeys, certificates, tokens, and identity-provider communication.
Therefore, quantum-safe migration can affect the infrastructure surrounding authentication even when the user continues entering the same password.
Post-Quantum Cryptography and Blockchain
Many blockchain systems use public-key signatures to authorise transactions and prove control of digital assets.
If the signature algorithm becomes vulnerable, an attacker could potentially forge transactions or impersonate an account under certain conditions.
However, migration can be difficult because distributed systems require agreement across wallets, validators, software, governance processes, and historical data formats.
Therefore, every blockchain project must assess its exact signature algorithms, public-key exposure, upgrade rules, and migration options.
How to Build a Post-Quantum Readiness Roadmap
A Post-Quantum Cryptography roadmap should convert broad security concerns into measurable, prioritised, and assigned work.
First, the roadmap should identify current cryptographic dependencies and the systems requiring migration. Next, it should define responsible teams, vendor milestones, testing requirements, procurement decisions, and deployment phases.
A practical roadmap can include:
- Assign executive and technical ownership.
- Create or improve the cryptographic inventory.
- Identify vulnerable public-key algorithms.
- Classify data and signature lifetimes.
- Prioritise critical and long-lived systems.
- Collect vendor readiness information.
- Improve crypto agility in applications and infrastructure.
- Build laboratory and interoperability tests.
- Pilot approved PQC implementations.
- Deploy changes through controlled phases.
- Monitor performance, failures, and security events.
- Retire vulnerable algorithms when policy and compatibility allow.
Assign Clear Ownership
Post-quantum migration can fail when every department assumes that another team owns the problem.
Therefore, organisations should assign responsibility for:
- Cryptographic inventory management.
- Application remediation.
- Infrastructure and network migration.
- Certificate and identity systems.
- Vendor engagement and procurement.
- Data classification and retention.
- Testing and security validation.
- Risk acceptance and exception management.
- Compliance and audit evidence.
- Communication with executives and customers.
A central programme can coordinate standards, priorities, and reporting. Meanwhile, individual system owners should remain responsible for implementing changes in their environments.
Start with a Controlled Pilot
A pilot allows teams to learn about algorithm support, message sizes, performance, monitoring, and operational procedures before a broad deployment.
Ideally, the chosen system should be important enough to produce useful findings but controlled enough to limit business risk.
Possible pilots include:
- An internal test API.
- A development VPN environment.
- A laboratory certificate authority.
- A non-production signing pipeline.
- An isolated service-to-service connection.
- A test fleet of managed devices.
However, a successful demonstration does not prove that every production environment will behave identically. Broader testing will still be required.
Use Maintained Cryptographic Libraries
Implementing cryptography correctly involves more than translating a mathematical specification into code.
Production implementations must address:
- Secure randomness.
- Constant-time operations where required.
- Input validation.
- Memory safety.
- Key protection.
- Error handling.
- Side-channel resistance.
- Parameter validation.
- Protocol integration.
- Testing against official vectors.
Therefore, teams should use maintained libraries, supported platforms, validated modules where required, and recognised standards.
Unless an organisation has specialised cryptographic expertise and a legitimate research requirement, it should not create a custom PQC implementation.
Implementation Security Still Matters
An algorithm may be mathematically secure while its implementation remains vulnerable.
For example, attackers may exploit timing differences, power consumption, electromagnetic leakage, memory errors, invalid inputs, weak randomness, or fault injection.
Consequently, security reviews should examine the complete implementation, including the library, compiler, hardware, protocol, configuration, key lifecycle, and application logic.
A post-quantum label does not protect a product from ordinary software vulnerabilities.
Protect Post-Quantum Private Keys
PQC private keys require the same disciplined protection as other high-value cryptographic keys.
Controls may include:
- Hardware security modules or secure elements.
- Restricted administrative access.
- Multi-person approval for critical operations.
- Key backup and recovery procedures.
- Rotation and revocation policies.
- Audit logging.
- Secure key destruction.
- Separation between development and production keys.
- Protection from logs and crash reports.
- Incident-response procedures for suspected compromise.
Before selecting an algorithm, teams should also verify that their key-management products support its key size, operations, performance, and security policies.
Update Procurement Requirements
New products purchased today may remain operational throughout the post-quantum transition. Therefore, procurement teams should include crypto-agility and PQC requirements in product evaluations.
Possible requirements include:
- Support for final NIST PQC standards.
- Documented upgrade and replacement paths.
- Configurable algorithms and protocols.
- Secure software and firmware updates.
- Cryptographic inventory export.
- Key and certificate lifecycle support.
- Defined vendor maintenance timelines.
- Interoperability test evidence.
- Support for approved hybrid modes when required.
- Disclosure of unsupported hardware limitations.
In particular, a product should not be considered future-ready merely because its marketing materials mention quantum security.
Include PQC in Architecture Reviews
New applications should avoid design choices that make later cryptographic changes difficult.
Architecture reviews should examine:
- Where algorithms are selected.
- Whether cryptographic operations use maintained abstractions.
- Whether message formats support larger values.
- How certificates and keys are rotated.
- Whether clients can negotiate approved new protocols.
- How unsupported devices are identified.
- How algorithms can be disabled quickly.
- Whether test environments support alternative providers.
Building agility into a new system is generally easier than adding it after cryptographic assumptions have spread throughout the codebase.
Prepare for Interoperability Problems
Migration will not occur everywhere at the same time. For instance, one client may support PQC while another supports only classical cryptography.
Organisations therefore need policies for:
- Classical-only connections.
- Hybrid connections.
- Post-quantum-only connections.
- Unsupported clients.
- Expired or incompatible certificates.
- Protocol downgrade attempts.
- Emergency rollback.
Compatibility fallbacks must not silently downgrade a connection to an unacceptable option without monitoring and policy control.
Prevent Downgrade Attacks
A downgrade attack attempts to force two compatible systems to use a weaker algorithm or protocol.
During migration, systems may support several classical, hybrid, and post-quantum choices. Consequently, ambiguous negotiation and weak fallback behaviour can create new risks.
Protocols should authenticate negotiated parameters where required and restrict choices through approved policy.
Moreover, monitoring should identify unexpected classical-only connections in environments where stronger protection is expected.
Update Monitoring and Logging
Security and operations teams need visibility into which cryptographic algorithms are actually used after deployment.
Useful monitoring can include:
- Negotiated key-establishment algorithms.
- Certificate signature algorithms.
- Failed handshakes.
- Unsupported clients.
- Unexpected protocol downgrades.
- Key-generation and signing errors.
- Certificate-chain size failures.
- Performance changes.
- Systems still using vulnerable algorithms.
- Vendor, firmware, and library versions.
However, logs should never record private keys, shared secrets, plaintext data, or complete sensitive messages.
Plan for Safe Rollback
A new cryptographic deployment may cause performance, compatibility, or stability problems. Therefore, teams need a rollback plan that restores service safely.
Rollback should not return every system to an outdated algorithm indefinitely.
Instead, a controlled procedure should define:
- Who can approve rollback.
- Which temporary algorithms remain acceptable.
- How the exception will be monitored.
- How affected users will be identified.
- When the migration will be attempted again.
- Which controls reduce temporary risk.
Most importantly, teams should test rollback procedures before the production deployment.
Train Technical and Business Teams
Developers and infrastructure engineers need to understand algorithm roles, protocol integration, implementation risks, and testing requirements.
Meanwhile, procurement and management teams need to understand vendor dependencies, equipment lifecycles, costs, and migration timelines.
Useful training topics include:
- The difference between key establishment and signatures.
- The harvest-now-decrypt-later threat.
- Cryptographic inventory methods.
- Crypto agility.
- Current final PQC standards.
- Hybrid migration approaches.
- Implementation and side-channel risks.
- Vendor readiness assessment.
- Data-retention and system-lifecycle planning.
Post-Quantum Readiness Checklist
- Assign an executive sponsor and technical programme owner.
- Create a central cryptographic inventory.
- Identify RSA, Diffie-Hellman, ECDH, DSA, and ECDSA dependencies.
- Record data-confidentiality and signature-validity periods.
- Prioritise systems with long-lived sensitive information.
- Request detailed PQC roadmaps from vendors.
- Add crypto-agility requirements to architecture and procurement.
- Use final standards and maintained implementations.
- Test key, ciphertext, signature, and certificate sizes.
- Measure latency, memory, bandwidth, and processor impact.
- Review HSM, smart-card, and secure-element support.
- Plan PKI, code-signing, and firmware-signing migration.
- Use hybrid modes only through recognised constructions.
- Monitor negotiated algorithms and downgrade behaviour.
- Prepare rollback, incident-response, and key-revocation procedures.
- Retire vulnerable algorithms through controlled policy.
- Continue monitoring standards and cryptanalytic research.
Common Post-Quantum Cryptography Mistakes
- Waiting for a confirmed quantum breakthrough before planning.
- Assuming that one new security library completes the migration.
- Creating an inventory that covers only public websites.
- Ignoring vendor products and embedded cryptography.
- Using experimental algorithms in production without approval.
- Writing a custom cryptographic implementation.
- Assuming every product labelled quantum-safe follows final standards.
- Ignoring certificate, key, ciphertext, and signature sizes.
- Failing to test constrained or older devices.
- Hard-coding algorithm names and buffer lengths.
- Using hybrid cryptography without a recognised construction.
- Allowing silent downgrade to classical-only security.
- Replacing algorithms without updating key-management processes.
- Assuming mathematical security prevents implementation attacks.
- Treating the first migration as the final cryptographic change.
Is Post-Quantum Cryptography Available Now?
Yes. NIST published the first three final PQC standards in 2024, and products, protocols, libraries, and platforms are gradually integrating them.
However, availability varies by operating system, service, protocol, device, vendor, and regulatory environment. Therefore, organisations should verify exactly which final standards and deployment modes a product supports.
Do You Need a Quantum Computer to Use PQC?
No. Post-Quantum Cryptography runs on classical computers and conventional digital infrastructure.
Its name refers to the threat it is intended to resist rather than the hardware required to execute it.
Will Quantum Computers Break All Encryption?
No. The greatest concern applies to several widely used public-key algorithms.
Symmetric encryption and hashing are affected differently and do not automatically become useless. Therefore, security teams should evaluate each cryptographic function separately.
Is AES Post-Quantum Secure?
Quantum search techniques can reduce the effective strength of symmetric cryptography. However, the effect is less dramatic than the threat to vulnerable public-key algorithms.
Organisations should therefore follow current standards for approved symmetric algorithms and key sizes.
Does PQC Replace TLS?
No. TLS is a security protocol that combines key establishment, authentication, symmetric encryption, and integrity protection.
Post-quantum algorithms can become components within updated TLS deployments. However, they do not replace the complete protocol.
Does PQC Replace Digital Certificates?
No. Certificates can continue binding identities to public keys.
Nevertheless, their signature algorithms, public keys, formats, size limits, and validation systems may require updates.
Are Current PQC Algorithms Guaranteed to Remain Secure?
No cryptographic algorithm can receive an absolute guarantee of permanent security.
New mathematical attacks, software flaws, hardware changes, or operational weaknesses may appear. Consequently, organisations still need monitoring, secure updates, algorithm diversity, and crypto agility.
Should Small Businesses Prepare for PQC?
Yes, although preparation should match the organisation’s size and risk.
Small businesses often depend on hosting companies, cloud services, payment platforms, operating systems, and software vendors. Therefore, they can begin by identifying critical providers, reviewing data-retention requirements, and asking vendors about supported upgrade paths.
Should Individuals Change Anything Today?
Most individuals will receive PQC support through operating systems, browsers, messaging services, cloud platforms, applications, and devices.
Meanwhile, users should keep software updated, replace unsupported equipment, enable strong authentication, and avoid unmaintained applications.
They should also avoid installing unknown “quantum encryption” products based only on marketing claims.
How Long Will Migration Take?
The timeline depends on system size, hardware lifespan, data sensitivity, vendor support, protocol readiness, and regulatory requirements.
Large organisations may need several years to discover dependencies, update software, procure hardware, test interoperability, and retire vulnerable systems.
Therefore, standards bodies encourage organisations to begin preparing before a cryptographically relevant quantum computer exists.
Is Hybrid Cryptography More Secure?
A correctly designed hybrid approach can preserve protection when at least one combined component remains secure.
However, the construction, key derivation, negotiation, validation, and implementation must all be correct. In addition, hybrid modes can increase complexity and introduce new downgrade or interoperability risks.
What Is the First Step in PQC Migration?
The first practical step is creating a cryptographic inventory.
Once teams understand where vulnerable algorithms appear, they can prioritise systems according to data lifetime, business impact, equipment lifespan, and replacement difficulty.
Final Verdict: Post-Quantum Cryptography
Post-Quantum Cryptography is becoming a practical security requirement rather than a distant research topic. NIST has published final standards for ML-KEM, ML-DSA, and SLH-DSA, which now provide a foundation for implementation and migration.
However, the most urgent concern is not limited to what a future quantum computer might decrypt on the day it becomes available. Attackers may already collect encrypted information that could remain valuable for many years.
Therefore, organisations should begin with cryptographic discovery, data-lifetime assessment, system prioritisation, vendor coordination, crypto agility, and controlled testing. They should also use maintained implementations based on final standards instead of custom or experimental cryptography.
Finally, migration should be treated as an ongoing capability. Algorithms, protocols, products, and security requirements will continue to change. A cryptographically agile organisation will be better prepared not only for quantum threats but also for future weaknesses in any security technology.
