Why PQC Matters
Quantum risk starts before quantum computers arrive.
The public-key cryptography protecting the vast majority of today's secure networks is now understood to be vulnerable to quantum attack, however strong it remains against classical computers. A sufficiently capable quantum computer could break the RSA and elliptic-curve algorithms underpinning TLS, mTLS, SSH, VPNs, certificates and digital trust.
While this is often seen as a future problem, sensitive data is already at risk. Attackers can capture encrypted traffic today and retain it until quantum capability arrives. This is harvest now, decrypt later (HNDL).
That makes PQC an evidence problem now. Before migration can begin, you need to know what cryptography is live, what it protects, what depends on it and where protection cannot yet be verified.
The changing foundation
The security model underneath the internet is changing.
Secure network protocols use asymmetric cryptography to establish encrypted sessions and authenticate identities. RSA and elliptic-curve cryptography remain secure against today's classical computers. A cryptographically relevant quantum computer would change that assumption.
Authenticates services and establishes encrypted application sessions.
Protects remote administration and establishes host identity.
Builds VPN trust and negotiates protection for network traffic.
Connects certificates, signatures, trust stores and issuing authorities.
Present-tense exposure
Harvest now, decrypt later makes the risk current.
An attacker does not need a quantum computer today. They can capture encrypted traffic, retain it and attempt to decrypt it when sufficiently capable quantum hardware becomes available.
The highest-priority exposure occurs where a live service uses classical-only key establishment, carries data that must remain confidential for years, and crosses public, shared or third-party infrastructure.
A defensible HNDL finding needs context.
Live negotiation evidence, data sensitivity and lifetime, dependencies, ownership and observation coverage must be brought together.
HNDL risk identified
Classical-only protection is observed on a service carrying long-lived sensitive data.
Cryptographic exposure observed
Classical-only protection is observed, but the data sensitivity or confidentiality lifetime is incomplete.
PQC confidentiality protected
Hybrid or post-quantum key establishment is observed on the tested service path.
Could not verify
Negotiation, data context or dependency coverage is missing. Unknown is not treated as protected or failed.
From standards to operations
Standards define the destination. They do not migrate the estate.
NIST standardised ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures in FIPS 203, 204 and 205. The IETF has also published a framework for combining classical and post-quantum key exchange in TLS 1.3.
Infrastructure teams, application owners, PKI operators and suppliers will carry out different parts of the transition. They all need a shared, evidence-backed answer to the same question.
What is actually running, and can we prove that it has changed?
Discovery and assessment
Understand the estate and create an initial migration plan.
Priority migration
Complete the highest-priority transitions and refine the plan.
Complete migration
Finish the transition across systems, services and products.
Evidence-backed posture
PQC readiness is not a single checkbox.
A service can support PQC without using it. It can offer hybrid key exchange without successfully negotiating it. Each state must describe what the evidence actually proves.
-
Classical only
Live key establishment relies entirely on quantum-vulnerable cryptography.
-
PQC capable
The technology supports PQC, but use has not been observed.
-
Hybrid offered
Classical and post-quantum key establishment appears in the offer.
-
Hybrid negotiated
A live observation proves hybrid protection was selected.
-
PQC Safe
Observed service meets a scoped, versioned PQC policy.
-
Classical only
Live key establishment relies entirely on quantum-vulnerable cryptography.
-
PQC capable
The technology supports PQC, but use has not been observed.
-
Hybrid offered
Classical and post-quantum key establishment appears in the offer.
-
Hybrid negotiated
A live observation proves hybrid protection was selected.
-
PQC Safe
The observed service meets a scoped, versioned PQC policy.
State: Could not verify. A coverage state, not another maturity stage. Missing evidence is never treated as either failure or protection.
The first operational problem
PQC migration starts with discovery.
Cryptography is distributed across cloud platforms, CDNs, load balancers, Kubernetes, service meshes, VPNs, firewalls, appliances, SSH fleets, internal PKI, applications, managed services and supplier environments. Migration starts by turning that fragmentation into a usable dependency picture.
Identify cryptographic assets
Services, certificates, keys, algorithms, protocols, endpoints and trust anchors.
Map dependencies
Applications, workloads, devices, owners and business services that rely on each cryptographic path.
Catalogue third-party cryptography
Infrastructure controlled by cloud, SaaS, network and managed-service suppliers.
Identify legacy constraints
Technology with limited PQC support, uncertain upgrade paths or long replacement cycles.
Expose evidence gaps
Unknown ownership, missing vantages, stale observations and paths that cannot yet be verified.
Evidence gap detected
Internal SSH / bastion-07
The endpoint still resolves, but no fresh key exchange has been observed from an internal vantage. The negotiated cryptography cannot currently be proven.
This is not evidence of classical fallback. It is an explicit boundary in the available evidence.
- Ownership
- Unknown
- Vantage
- Observer offline
- Last observation
- 18h ago / stale
- Path status
- Unverified
Assign an owner, restore the internal observer and capture a fresh handshake before assessing PQC posture.
Illustrative future operator view. It does not represent a currently released screen.
Where Cyphrs fits
The evidence and control layer for PQC migration.
[cyphrs] Scout starts with the certificate and TLS estate: what is issued, what is live, what is served, what is trusted, what changed and what needs action. The Cyphrs PQC direction extends that evidence discipline across cryptographic services and migration states.
Find and map
Identify services, identities, trust relationships, dependencies, third parties and legacy constraints.
Establish what is used
Separate capability from what is offered and what real connections actually negotiate.
Prioritise with evidence
Apply versioned policy, surface HNDL exposure, show coverage gaps and identify migration blockers.
Monitor the transition
Retain change history, prove migration outcomes and detect fallback, regression or new exposure.
Engineering teams, infrastructure providers and suppliers carry out the required technology changes. Cyphrs provides the shared evidence needed to prioritise those changes, coordinate the programme and verify the resulting protection.
Start with the evidence
Know your cryptographic estate before the deadline arrives.
PQC migration will be a multi-year programme. Start by seeing what is really out there, what is live and what still needs action.
Run [cyphrs] Scout