External baseline
Scan public websites, APIs and login hosts for TLS 1.3 support, security headers, downgrade exposure and visible hybrid key exchange evidence.
Run the free post-quantum security scanImplementation guide
Post-Quantum Cryptography Implementation in 4 Steps
A practical guide for moving from awareness to implementation: cryptographic inventory, risk prioritisation, hybrid TLS pilots, API and VPN migration, digital signatures, supplier evidence and governance.
Updated: 5 September 2026|16 min read
Step 2
Post-Quantum Cryptography Step 2: Build Evidence
After the basic risk is understood, the next useful action is not a broad algorithm replacement. Step 2 is an evidence sprint: measure the public attack surface, document where quantum-vulnerable cryptography is used, then choose one pilot that can be tested without locking the organisation into an immature migration path.
Cryptographic inventory
Record certificates, key exchange, signing keys, libraries, protocols, owners, suppliers and data-lifetime requirements before choosing replacements.
Build the cryptographic inventoryFirst reversible pilot
Choose one TLS, API or VPN path where a hybrid ML-KEM pilot can be tested with compatibility checks and a documented rollback route.
Map the pilot into the roadmapDiscover
Cryptographic inventory, data-lifetime map and externally visible readiness report.
- -Scan public websites, APIs, VPN portals and customer-facing endpoints.
- -List certificates, signing keys, TLS libraries, key stores, identity providers and supplier dependencies.
- -Classify data by confidentiality lifetime and exposure to harvest-now-decrypt-later risk.
Prioritise
Ranked migration backlog with quick wins, blockers and accountable owners.
- -Separate transport key exchange, digital signatures, stored data encryption and embedded systems.
- -Identify systems where provider or library support already makes a hybrid pilot practical.
- -Document systems where client compatibility, hardware, firmware or procurement will slow migration.
Pilot
Measured compatibility and performance evidence for selected hybrid deployments.
- -Enable or test hybrid ML-KEM key exchange where the CDN, gateway or TLS stack supports it.
- -Validate client, monitoring, WAF, API gateway and certificate-management behaviour.
- -Test signature workflows separately with ML-DSA or SLH-DSA where libraries and verifiers are mature.
Scale
Roadmap for production rollout, supplier requirements and crypto-agility controls.
- -Move high-lifetime data paths first, then broaden to lower-risk services.
- -Update procurement and architecture review so new systems are crypto-agile by default.
- -Track algorithm, vendor and certificate changes through change management.
Implementation Starts With Inventory, Not Algorithms
Post-quantum cryptography implementation fails when it starts with a single library upgrade. The real task is to find every place where long-term security depends on quantum-vulnerable public-key cryptography, then decide which systems should move first.
A useful inventory includes public TLS endpoints, API gateways, VPNs, SSH, mTLS, certificate authorities, code-signing keys, document-signing workflows, identity tokens, embedded devices, backups, archives and suppliers. For each item, record the algorithm, owner, vendor, data lifetime and replacement path.
This inventory is also the bridge between SEO-visible website readiness and real business risk. A public website scan can show TLS posture, but a full implementation plan must include internal systems and third-party services that are not externally visible.
Where to Implement PQC First
Web TLS and CDNs
Start with TLS 1.3, canonical hosts, legacy protocol removal and hybrid key exchange support at the edge.
APIs and mTLS
Map public APIs, partner callbacks, webhook signatures, service certificates and API gateway policies.
VPN and remote access
Review vendor PQC roadmaps, firmware support, authentication methods and fallback behaviour.
Code and document signing
Plan ML-DSA or SLH-DSA testing around release pipelines, archives and long-term verification.
Identity and tokens
Check JWT, SAML, OIDC, certificate chains, device identity and key rotation assumptions.
Suppliers and SaaS
Ask providers for NIST-standard support, migration dates, evidence and contract language.
NIST Standards to Map Into the Roadmap
The first production roadmap should map each use case to the relevant NIST standard. Use ML-KEM from FIPS 203 for key establishment and transport pilots, ML-DSA from FIPS 204 for many signature workflows, and SLH-DSA from FIPS 205 where a conservative hash-based signature option is appropriate.
Do not treat the standards as interchangeable. Key establishment, authentication, document signing, firmware signing and archive validation each have different compatibility and verification requirements.
Implementation Order for a Typical Organisation
- 1. Scan external endpoints. Start with public websites, API hosts and VPN portals so you have immediate evidence of TLS, header and downgrade posture.
- 2. Build the crypto inventory. Record algorithms, keys, certificates, libraries, data lifetime, owner and supplier for each system.
- 3. Rank systems by data lifetime. Prioritise healthcare, legal, financial, government, intellectual-property and regulated data that remains sensitive for years.
- 4. Run hybrid transport pilots. Test TLS, CDN, API gateway, VPN and service-mesh support for ML-KEM hybrid key exchange where the provider stack is ready.
- 5. Treat signatures separately. Build a distinct workstream for ML-DSA, SLH-DSA, code signing, document signing, device identity and long-term validation.
- 6. Update governance. Add PQC and crypto-agility requirements to architecture review, procurement, supplier questionnaires and change management.
A 90-Day Post-Quantum Cryptography Implementation Plan
The first 90 days should create evidence and reduce uncertainty, not attempt a risky organisation-wide replacement. Use this sequence to move from discovery to a governed migration decision with clear owners and measurable exit criteria.
| Period | Focus | Actions | Evidence to retain |
|---|---|---|---|
| Days 1 to 30 | Discover and assign ownership | Scan external endpoints, build the cryptographic inventory, map sensitive-data lifetimes and identify accountable system owners. | Inventory register, external scan baseline, data-lifetime map and named owners. |
| Days 31 to 60 | Prioritise and design pilots | Rank systems by exposure and migration difficulty, confirm supplier support, then select reversible hybrid TLS or API pilots. | Risk-ranked backlog, supplier responses, pilot architecture and documented rollback criteria. |
| Days 61 to 90 | Test and govern the migration | Measure compatibility and performance, resolve failures, record decisions and turn successful pilots into a funded rollout plan. | Test results, exception log, approved roadmap, budget assumptions and reporting cadence. |
Start with the detailed cryptographic inventory guide and use the PQC migration checklist for CTOs to turn the evidence into accountable actions.
Common Implementation Mistakes
The most common mistake is assuming that a single TLS change makes the organisation quantum-safe. Transport security matters, but it does not cover stored data, identity tokens, signatures, backups, archives, embedded devices or partner integrations.
The second mistake is waiting for every vendor to be ready before doing any work. Inventory, data classification, supplier questioning and low-risk pilots can start before every production dependency supports final PQC deployment.
The third mistake is ignoring measurement. Every pilot should record compatibility, latency, certificate behaviour, client breakage, rollback steps and ownership. Without those records, a pilot does not become a migration programme.
Start With Evidence
Run the free external scan first, then use the result to decide whether your next step is a TLS pilot, an API inventory, a signature workstream or supplier review.
Implementation FAQ
What is the first step in post-quantum cryptography implementation?
The first practical step is a cryptographic inventory: list the systems, endpoints, certificates, keys, signing workflows and suppliers that depend on RSA, ECDH, ECDSA or other quantum-vulnerable public-key cryptography.
What is post-quantum cryptography step 2?
Step 2 is to turn awareness into evidence. Scan exposed endpoints, build the cryptographic inventory, rank systems by data lifetime and choose one reversible hybrid pilot before wider migration.
Should we replace all cryptography with PQC immediately?
No. Most organisations should start with risk-based pilots and hybrid deployments. Transport security, APIs and VPNs are often easier first pilots than long-lived signature workflows.
Which NIST standards matter for implementation?
FIPS 203 defines ML-KEM for key establishment. FIPS 204 defines ML-DSA for digital signatures. FIPS 205 defines SLH-DSA, a hash-based digital signature option.
Is TLS 1.3 enough for post-quantum cryptography?
TLS 1.3 is a prerequisite for many modern deployments, but it is not the same as active post-quantum protection. You still need a post-quantum or hybrid key exchange such as ML-KEM in the negotiated path.
Related Implementation Resources
Complete PQC Guide
Understand the threat, standards, algorithms and migration context.
NIST FIPS 203/204/205
Map ML-KEM, ML-DSA and SLH-DSA to implementation use cases.
PQC for APIs
Plan implementation around public APIs, mTLS, tokens and webhooks.
UK PQC Implementation
Align implementation planning with UK NCSC milestones and regulated data.
Free readiness account
Keep This Guide Connected to a Real Website Scan
A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.
No cardStart the free evidence path without a paid plan.
Saved scanKeep the public endpoint result after the browser session.
Rescan laterRerun after TLS, header or provider changes.
Prefer to scan first? Open the free quantum security scanner.