Migration Plan
Turn the inventory into an ordered list of changes. Connections that are exposed now come first, and the rest are ordered by how much at-risk traffic each change fixes.
- Where
- Discover › Migration plan
- Who
- Auditors and above
Before You Begin
You need the auditor role or higher. The guardian builds the plan from the PQC Inventory, so your nodes must be observing traffic. The plan uses the same realm scope, policy and window as the inventory.
How Steps Are Ordered
The plan starts from every service pair at critical or high risk, and groups the pairs into the changes that fix them. There is one change for each server that must change, and one for each application that must change. The changes are then split into two phases:
- Exposed now holds the changes that fix pairs at critical risk. These connections can be broken without a quantum computer, so make these changes first.
- Harvest now, decrypt later holds the changes that fix pairs at high risk, which use classical key exchange.
Within each phase, the changes that fix the most at-risk flows come first. The plan covers every pair in scope.
Each step is one of four kinds of change:
| Change | Used when |
|---|---|
| Upgrade to TLS 1.3 with hybrid key exchange | The server must change, and it runs a TLS version older than 1.3 or uses RSA key transport. |
| Enable hybrid key exchange on the server | The server must change, but it does not need a new protocol version. |
| Update <application> on N nodes | The client offered no post-quantum key exchange. |
| Identify the side blocking post-quantum | The handshake does not show which side must change. |
A client step marked Server ready needs only a client update, because its server already negotiates post-quantum key exchange with other clients.
Working Through the Plan
Open Discover › Migration plan. The tiles at the top show the number of Steps, the changes needed on servers under Server, and the application updates needed under Client.
Discover › Migration plan
- After a change, its pairs appear under Became quantum-safe in Progress as soon as a quantum-safe handshake is seen. A pair keeps its at-risk rating until its older handshakes leave the window, so choose a shorter window, such as 24 h, to see the step clear sooner.
Progress and Policy
Progress shows the quantum-safe share by day, and how many points it has moved over the window. The latest changes are listed below the chart. A pair that has regressed shows the plan step it now belongs to.
The policy card compares your plan with the other policy. With NIST selected, the Under CNSA 2.0 card counts, by group, the extra pairs that would need a change if you required ML-KEM-1024. With CNSA 2.0 selected, the Under NIST / OMB card counts the pairs you would no longer need to change. To switch policy, select Switch to CNSA 2.0 or Switch to NIST / OMB.
Deadlines lists the US federal deadlines for TLS 1.3 and for post-quantum key establishment.
To share the inventory behind the plan, select Export. See Reports and CBOM.