For an engineering or security team, the actionable starting point is not a readiness percentage. It is a maintained record of observed cryptography, affected systems, owners, data lifetime, dependencies, suppliers, intended targets, deadlines, evidence and migration status.
What the G7 call to action asks organizations to do
The joint call highlights risks to current public-key cryptography while acknowledging that the timing of cryptographically relevant quantum computers remains uncertain. It recommends a coordinated transition and treats post-quantum preparation as work that should begin now.
Its practical organizational actions include taking inventory of cryptographic assets, identifying critical systems, mapping dependencies and developing transition plans. The earlier G7 migration statement also emphasizes leadership accountability, supplier engagement, testing and documentation.
Build a post-quantum cryptographic inventory
A useful post-quantum cryptographic inventory needs more than algorithm names. Each record should connect observed cryptography to its source and location, evidence, confidence, application or service, owner, criticality, protected-data lifetime, dependencies and supplier constraints.
Coverage must remain explicit. Public TLS, repositories, dependency trees, cloud services and endpoints expose different evidence. A public-domain scan is a valid first layer, but it is not a complete cryptographic inventory and cannot establish that internal or organization-wide cryptography has been inventoried.
| Migration register field | Why it matters |
|---|---|
| Current crypto and evidence | Establishes the observed starting point and makes the record reproducible |
| Owner and criticality | Connects technical change to accountability and business impact |
| Data lifetime | Provides context for long-lived confidentiality exposure without inventing a universal score |
| Dependencies and supplier | Exposes interoperability, product-roadmap and supply-chain constraints |
| Target and deadline | Records the intended outcome and planning date as manual assertions |
| Status and verification | Separates planned, configured and deployed work from what a newer scan actually observed |
Turn inventory into a PQC migration plan
- 1. Discover
Collect deterministic observations from explicitly approved sources and retain their coverage limits.
- 2. Normalize
Create stable asset identities while preserving source-specific evidence and confidence.
- 3. Assign
Record owners, criticality, data lifetime, dependencies and supplier responsibility.
- 4. Plan
Document the intended successor, interoperability work and a governed deadline.
- 5. Test and deploy
Validate product support, performance, compatibility and rollback before changing production.
- 6. Verify
Run newer deterministic discovery and compare expected with observed cryptographic properties.
- 7. Monitor
Retain history and detect certificate changes, deprecated cryptography returning and other scoped drift.
Standards are inputs, not proof of deployment
NIST states that migration requires understanding quantum-vulnerable public-key algorithms in hardware, software and services and developing roadmaps for standardized post-quantum algorithms. Its migration project treats cryptographic discovery and interoperability as separate but connected workstreams.
Using a standard algorithm name in a target field does not prove that a protocol, product or deployment is correct. Verification needs implementation testing and new evidence from the intended environment. National timelines and requirements should be taken from the relevant national authority rather than inferred from this guide.
Frequently asked questions
Does the G7 call create one universal legal deadline?
No. The G7 material recommends action and directs organizations to relevant national guidance. Applicable regulatory or contractual requirements and dates must be assessed for each organization and jurisdiction.
Is a public TLS scan a complete post-quantum cryptographic inventory?
No. It shows cryptography observable at the submitted public endpoint. Repositories, dependencies, internal services, cloud resources and endpoints require separate authorized discovery sources.
Should a PQC migration register contain a readiness score?
It does not need one. Evidence, confidence, coverage, ownership, criticality, data lifetime, dependencies, target, deadline and verified status provide more actionable and reproducible information than an unexplained percentage.
Can planned or deployed be marked complete manually?
A team can record manual lifecycle stages, but completion should be distinguished from verification. Cipher Discovery requires a newer comparable public observation before it labels a supported public certificate migration externally verified.