Vista resources / Operational guides
How to plan a post-quantum cryptography migration
Start a post-quantum cryptography migration with one service. Inventory where it uses public-key cryptography, identify who controls each dependency, then pilot the change with representative clients. Capture a baseline and repeat the tests after rollout.
Choose a service for your first migration pilot
Use the cryptographic inventory template to capture the baseline and the migration priority worksheet to select a pilot. After testing, generate a scoped CBOM to preserve the observed state.
Choose the playbook that matches your service and turn its steps into owned work items. These are architecture-level planning guides; actual commands and configuration depend on your product version, protocol, and requirements. Confirm supplier guidance before making changes.
For every pilot, define success criteria, a rollback owner, a test environment, and the evidence you will retain. Vista helps inventory and govern the work; it does not perform every migration or generate PQC keys.
Websites and APIs
- Scope
- Public TLS endpoint, CDN-to-origin path, internal API hops and clients.
- Discover
- Record each termination point and obtain provider configuration evidence.
- Evaluate and test
- Test intended browsers and API clients, negotiated groups, certificate validation, handshake sizes and latency. Use PQC Toolbox to check whether a public website negotiates hybrid key exchange.
- Act and preserve proof
- Roll out to a limited hostname or traffic segment; document rollback and capture fresh observations.
Remote access and site-to-site VPNs
- Scope
- Gateway firmware, client versions, tunnels, identity, hardware acceleration and partner appliances.
- Discover
- Ask suppliers which exact protocols and configurations support PQC; separate key establishment from authentication.
- Evaluate and test
- Test reconnects, roaming, MTU/fragmentation, failover, load and mixed-version interoperability.
- Act and preserve proof
- Pilot a noncritical tunnel with recovery access; preserve configuration and operational evidence.
PKI and certificates
- Scope
- Issuing CAs, trust stores, enrollment, relying parties, signing services and certificate lifetimes.
- Discover
- Map who validates each certificate and which formats/algorithms each party can accept.
- Evaluate and test
- Test chain validation, enrollment, revocation, storage and dependent clients in an isolated environment.
- Act and preserve proof
- Use staged trust distribution and explicit rollback; a new certificate algorithm can require changes across relying parties.
Code and firmware signing
- Scope
- Build systems, signing keys, HSMs, update services, bootloaders and deployed verifiers.
- Discover
- Inventory verification capability and the support lifetime of already deployed devices.
- Evaluate and test
- Test signature formats, package sizes, verification time, recovery images and old/new verifier combinations.
- Act and preserve proof
- Define how trust and verifiers update before changing signatures; preserve reproducible build and verification evidence.
Applications and cryptographic libraries
- Scope
- Language runtime, library version, protocol bindings, SDKs and partner interfaces.
- Discover
- Distinguish a library primitive from an interoperable application protocol.
- Evaluate and test
- Run integration, error-path, performance and downgrade-policy tests for the complete workflow.
- Act and preserve proof
- Deploy a bounded pilot with version pinning, monitoring, rollback and an updated inventory.
Stored data and key management
- Scope
- Data encryption, key wrapping, backups, KMS/HSM boundaries, access paths and retention.
- Discover
- Separate symmetric data encryption from public-key transport and wrapping dependencies.
- Evaluate and test
- Test recovery, restore, key rotation, access controls and long-lived data workflows.
- Act and preserve proof
- Plan rewrapping or other changes only where the design requires them; validate recovery before expanding scope.
Pilot exit checklist
- The intended clients and dependencies interoperate.
- Fallback and failure behavior meet the agreed policy.
- Performance and capacity meet service expectations.
- Recovery and rollback have been exercised.
- The owner has reviewed fresh configuration and observation evidence.
- Remaining exclusions have named owners and review dates.
Use the inventory kit to record the boundary and the supplier tracker for dependencies.
Sources and further reading
Continue in Vista
Make the playbook an owned plan
Define the affected assets and a Scope in Vista. Review the relevant findings, then group the work under Remediation → Plans with tickets, assignees and due dates. Your teams carry out the change and rollback tests. Collect new evidence and generate another CBOM for the same scope.
Core provides inventory, findings, tickets, plans and CycloneDX snapshots. Enterprise adds built-in artifact comparison, signing and compliance attestation. Changes to production systems still require your operational process.