The work begins before algorithm replacement. Teams need measured discovery coverage, a normalized cryptographic inventory, ownership, risk context and a way to verify that legacy dependencies have actually been removed.
The seven-stage roadmap
- 1. Discover
Collect evidence from public services, source, dependencies, cloud and endpoints in approved stages.
- 2. Inventory
Normalize certificates, keys, algorithms, protocols, libraries and relationships.
- 3. Assess
Identify affected public-key cryptography and document uncertainty, data lifetime and interoperability.
- 4. Prioritize
Order work by exposure, business criticality, dependency depth, data sensitivity and owner readiness.
- 5. Migrate
Deploy supported standards or approved hybrid profiles with rollback and compatibility testing.
- 6. Verify
Repeat deterministic discovery and confirm old cryptography is no longer observed in the intended scope.
- 7. Monitor
Detect inventory drift, new dependencies and configuration regression over time.
Why migration takes time
- Protocols and platforms adopt standards on different schedules.
- Certificates, identity, signing and key exchange have different replacement workflows.
- Transitive dependencies may hide cryptographic choices from application owners.
- Partners, devices and long-lived products create interoperability constraints.
- Archived or long-lived sensitive data may require earlier prioritization than short-lived sessions.
Evidence-based prioritization
Avoid a single unexplained quantum-readiness percentage. Prioritization should link a cryptographic observation to its evidence, confidence, standards-based treatment, system role, owner and next action.
A public TLS certificate using RSA, for example, is a direct migration candidate. It is not proof that every RSA dependency in the organization has been found, and it does not establish a universal migration deadline.
Example: one evidence-backed Migration Register record
This synthetic record keeps direct observation separate from human planning context. The public TLS certificate and its evidence are observed; ownership, criticality, data lifetime, supplier constraints, target and deadline are manual assertions that require accountable review.
| Field | Example value | Basis |
|---|---|---|
| Current cryptography | RSA-2048 leaf certificate at tls.example.com:443 | Observed by deterministic X.509 parsing |
| Evidence | TLS certificate / tls.peerCertificates[0] / high confidence | Observed |
| Owner | Payments Platform Team | Manual assertion |
| Criticality | High | Manual assertion |
| Data lifetime | More than 7 years | Manual assertion |
| Dependency | External API consumers must accept the replacement profile | Manual assertion |
| Supplier | Managed certificate provider | Manual assertion |
| Target | Approved replacement public-certificate profile | Manual assertion |
| Deadline | 2027-06-30 | Manual assertion |
| Migration status | Planned | Manual lifecycle state; not proof of deployment |
Verify expected cryptography against observed cryptography
A migration can move through planned, configured and deployed states without becoming externally verified. Verification needs a newer comparable observation from the same intended scope.
In this synthetic mismatch, the expected state is an approved replacement public-certificate profile, while a newer public TLS scan still observes the baseline RSA-2048 leaf certificate. The deterministic result is MIGRATION NOT VERIFIED. That result is scoped to the public endpoint; it does not assess internal deployment.
| Verification field | Value |
|---|---|
| Expected | Approved replacement public-certificate profile |
| Observed | RSA-2048 leaf certificate |
| Evidence | Newer TLS certificate observation at tls.example.com:443 |
| Result | MIGRATION NOT VERIFIED |
Program outputs
| Output | Purpose |
|---|---|
| Coverage map | Shows scanned, unknown, excluded and not-scanned sources |
| Cryptographic inventory | Provides normalized assets, evidence, owners and relationships |
| Migration backlog | Connects affected dependencies to accountable replacement work |
| Verification evidence | Shows whether intended legacy cryptography is still observed |
| Monitoring policy | Detects drift and newly introduced cryptographic dependencies |
Frequently asked questions
When should an organization start PQC migration?
Start discovery and inventory work early because those activities are useful regardless of a speculative quantum-computer date. Actual replacement sequencing depends on data lifetime, standards support, dependencies and risk.
Should everything migrate at once?
Usually not. A staged plan prioritizes high-impact and long-lived dependencies, validates interoperability, and uses repeated discovery to track progress.
How do you know migration is complete?
Only relative to explicit coverage. Verification should repeat the relevant discovery methods and document what was tested, what changed and what remains unknown or not scanned.