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.
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.