PQC rollbacks need a cryptographic floor

Migration plans often describe how to enable a new algorithm and say little about how to recover when a client, HSM, proxy or certificate path fails. That gap creates a predictable incident response: someone restores the previous configuration, traffic recovers, and the post-quantum requirement quietly disappears. The PQC migration roadmap should therefore carry two plans at once: a forward sequence and a bounded recovery sequence.

This is a crypto-agility problem. NIST CSWP 39 treats agility as the ability to replace and adapt cryptographic mechanisms without interrupting system flow. Recovery is part of that capability. A design that can move forward only when every dependency behaves perfectly is not agile, while a design that can restore service only by returning indefinitely to vulnerable cryptography is not controlled.

Start with a floor, not a preferred configuration

The preferred state is what the service should use during normal operation. The cryptographic floor is the weakest state policy will tolerate during recovery. They are deliberately different. A TLS service might prefer a hybrid key exchange, permit a short classical fallback for a named legacy population, and forbid any fallback for long-lived confidential traffic. The floor belongs to the data and threat model, not to whatever configuration happened to work last week.

A floor can vary by system. NIST IR 8547 uses transition states and dates for federal use of algorithms, while the NCSC migration guidance asks organizations to build discovery, planning and execution around their own estate. Those references do not supply one fallback rule for every application. They supply constraints that a local rule must respect.

Write five fields before deployment

• Trigger: the observable condition that permits rollback, such as a measured handshake failure rate or an HSM import error. Avoid vague triggers such as instability.
• Scope: the exact endpoints, clients, data classes or regions affected. A global switch is not the default response to a local failure.
• Owner: one person or role authorized to activate the path and one role responsible for restoring the target state.
• Evidence: negotiation traces, configuration hashes, deployment identifiers, timestamps and the measured symptom that justified the change.
• Expiry: a time after which the exception closes automatically or requires fresh approval with new evidence.

These fields turn rollback from an improvised command into a testable control. Keep them beside the cryptographic inventory, because the inventory already records where algorithms, keys, certificates and providers sit. The crypto-agility implementation guide then connects each dependency to a change mechanism and an acceptance test.

Make the rollback observable

A configuration change is not enough evidence. The system must report what it actually used. For TLS, that means the selected group from ServerHello, the endpoint that terminated the connection, whether resumption occurred and the separate authentication algorithm. The end-to-end hybrid TLS method shows why client support or a server version cannot substitute for a captured negotiation result.

The same principle applies outside TLS. Record the algorithm identifier and verification result at the relying party for signatures. Record the encapsulation and decapsulation implementation, key identifier and failure path for KEM-based protocols. When several components form a hybrid construction, RFC 9794 provides terminology that helps the evidence state which component failed rather than hiding everything behind the word hybrid.

Test rollback as a negative control

A positive migration test proves the target can work. A rollback test must also prove that forbidden states do not work. In a staging environment, remove the post-quantum capability from one dependency, activate the permitted compatibility state, and confirm that only the intended population uses it. Then attempt to cross the floor and require a clear failure, alert or exception workflow.

• Confirm the trigger is based on measured behavior and cannot be activated by a label or version string alone.
• Confirm the rollback changes only the scoped route, client population or service.
• Confirm telemetry distinguishes the target, compatibility and below-floor attempts.
• Confirm the expiry restores the target state or blocks traffic rather than silently extending itself.
• Confirm a normal deployment cannot lower the floor without a reviewed policy change.
• Repeat the exercise after changing a proxy, HSM, certificate authority, runtime or key-management provider.

Put the mechanical parts in CI where possible. The guide to enforcing PQC mandates in CI can reject forbidden algorithms in code, configuration and manifests. Runtime evidence still needs production-path testing. Use an implementation audit when a provider, parser or protocol boundary can accept malformed or ambiguous inputs, and conformance testing when the question is whether an algorithm implementation follows its specification.

Rollback has to end

An exception that depends on someone remembering to remove it will become permanent. Prefer controls that expire in the system: a dated policy object, a feature flag with a hard stop, a short-lived certificate profile, or a deployment rule that rejects an old configuration after the approved window. Keep a dashboard for compatibility use so the remaining dependency is visible and shrinking.

A post-quantum migration succeeds when the organization can change cryptography without guessing, prove what each connection or signature used, recover from implementation failures, and still keep a minimum security promise. The rollback drill is where that promise becomes operational. Run it before the first production incident, preserve the evidence, and leave the system with no unowned path below the floor.

References

• NIST CSWP 39: Considerations for Achieving Crypto Agility. Design and operational considerations for replacing and adapting cryptographic mechanisms.
• NIST IR 8547 initial public draft. Transition states and proposed timelines for deprecating quantum-vulnerable algorithms.
• UK NCSC: Post-quantum cryptography guidance. Migration timelines and organizational planning guidance.
• IETF RFC 9794. Terminology for post-quantum traditional hybrid schemes.
• IETF RFC 10024. Standardized hybrid ML-KEM key-agreement mechanisms for TLS 1.3.
• IETF RFC 8446. TLS 1.3 negotiation, HelloRetryRequest and resumption behavior.