Investigate
Evidence is missing or ownership is unclear. Assign an owner and collect the minimum evidence needed for the next decision.
Migration
Turn post-quantum uncertainty into a practical migration plan.
Map your cryptographic dependencies, prioritize what matters, evaluate supported options, and validate changes before planning a staged rollout.
Migration involves systems, protocols, vendors, and operations—not simply replacing an algorithm.
This page describes a general migration approach. Evolext currently focuses on research, assessment, and controlled laboratory prototypes. Production changes require separately agreed engineering and validation.
Establish the starting point.
- System boundary
- Choose the systems, connections, environments, and exclusions to investigate.
- Business objective
- Name the decision to support, the business impact, and the acceptable disruption.
- Owners
- Identify system owners, decision authority, and operational responsibilities.
- Data lifetime
- Establish how long confidentiality or authenticity must be preserved.
- Operational constraints
- Record change windows, legacy clients, availability needs, vendor dependencies, and recovery requirements.
Five steps. Evidence before progression.
- 01
Inventory
Identify cryptographic use, owners, dependencies, and evidence gaps.
- Inputs
- Agreed scope, architecture, approved dependency evidence, and system owners.
- Activities
- Identify cryptographic roles, libraries, protocols, certificates, identity, and external dependencies; record evidence provenance.
- Concrete output
- A dependency register with owners, evidence sources, and coverage gaps.
- Before proceeding
- Confirm the agreed boundary and record unresolved dependencies.
- 02
Prioritize
Review data lifetime, business impact, exposure, and vendor constraints.
- Inputs
- Inventory, data lifetimes, business impact, exposure, and vendor constraints.
- Activities
- Review urgency, feasibility, dependencies, and uncertainty with business and technical owners.
- Concrete output
- Ordered actions with reasons for investigating, progressing, or deferring each item.
- Before proceeding
- Have decision owners review priorities and assumptions.
- 03
Evaluate
Check standards, protocol support, and implementation maturity for the selected use case.
- Inputs
- A selected use case, protocol requirements, vendor evidence, and implementation constraints.
- Activities
- Compare supported approaches, alternatives, parameter choices, integration maturity, and operational effects.
- Concrete output
- A decision record comparing options, constraints, and unresolved support questions.
- Before proceeding
- Confirm relevant protocol, platform, and vendor support; stop or defer unsupported paths.
- 04
Validate
Test interoperability and operational behavior in an isolated environment.
- Inputs
- A candidate design, representative test environment, test matrix, and agreed acceptance criteria.
- Activities
- Test interoperability, performance, resource use, failure behavior, and fallback; record untested cases.
- Concrete output
- Reproducible results and a limitations summary against the agreed criteria.
- Before proceeding
- Review results with owners; revise or stop when acceptance criteria are not met.
- 05
Plan staged deployment
Define monitoring, acceptance criteria, rollback conditions, and remaining risks.
- Inputs
- Reviewed test evidence, operational owners, change approval, and recovery constraints.
- Activities
- Plan deployment stages, monitoring, stop conditions, key and certificate changes, and recovery exercises.
- Concrete output
- A deployment sequence, monitoring responsibilities, and recovery plan.
- Before proceeding
- Confirm operational ownership, change approval, and rollback limitations before production work.
Progress can mean investigating, revising, deferring—or stopping.
Revise
Compatibility, performance, or failure tests miss the agreed criteria. Change the candidate and repeat the relevant tests.
Defer
A required vendor or protocol path is not supported. Record dependencies, interim controls, and a review trigger.
Stop
No acceptable recovery path, authorization, or supported design is available. Record the reason rather than presenting the path as ready.
Coordinate what you control and what you depend on.
- Within the organization’s control
- Application code, configuration, dependency versions, ownership records, and deployment procedures—subject to actual access and change authority.
- Shared or vendor-controlled
- Managed services, identity providers, certificate authorities, hardware, protocol ecosystems, and supplier roadmaps. Verify published support and contractual constraints.
- Legacy and indirect dependencies
- Older clients, transitive libraries, appliances, and archived or signed data may constrain the order of change. Track unknowns rather than assuming compatibility.
Make responsibility explicit.
- System owners
- Confirm the system boundary, purpose, dependencies, and evidence access.
- Engineering
- Evaluate supported designs, build the test environment, and document technical results.
- Operations
- Review monitoring, change windows, incident handling, and recovery procedures.
- Security and risk stakeholders
- Review threat assumptions, evidence limitations, acceptance criteria, and residual risk.
- Vendors and suppliers
- Provide verifiable implementation support information and integration constraints.
These are responsibilities to assign within an engagement; they do not imply that Evolext supplies every role or approves production changes.
Validate behavior, then plan operations.
- Interoperability
- Test representative clients, servers, versions, message formats, certificates, and negotiation paths.
- Performance and resources
- Measure relevant latency, throughput, CPU, memory, message sizes, and platform limits against a recorded baseline.
- Failure and fallback
- Test unsupported peers, timeouts, malformed inputs, and downgrade or fallback behavior within the authorized environment.
- Monitoring and acceptance
- Define observable signals, thresholds, owners, and stop conditions before considering a rollout.
- Recovery constraints
- Review keys, certificates, stored data, and trust relationships. Restoring an older software version may not undo these changes.
Fictional example · no measured results or client evidence
Follow one illustrative connection.
Assume two services communicate in an isolated test environment, with named owners and approved test data. Actual protocol and vendor support remain to be verified.
- 01
Inventory
List both endpoints, client libraries, trust dependencies, and evidence gaps.
- 02
Prioritize
Review data lifetime and business impact before placing this connection on the investigation list.
- 03
Evaluate
Compare staying with the current configuration, a supported hybrid option, and a supported post-quantum option; do not select an unsupported combination.
- 04
Validate
Prepare a test matrix; measure compatibility and operational effects rather than assuming success.
- 05
Plan staged deployment
Draft rollout and recovery gates only if the reviewed evidence supports moving forward.
Sources, evidence, and review
Use primary guidance and the applicable protocol and implementation documentation. Algorithm standardization, vendor support, and observed test behavior are separate evidence levels. Check publication updates and errata before making implementation decisions.
NCCoE guidance informs discovery and migration planning. FIPS 203, 204, and 205 define ML-KEM, ML-DSA, and SLH-DSA algorithm standards respectively; they do not establish protocol, vendor, or system readiness. Applicable references and implementation limits must be recorded for each engagement. References are not certification.
Last reviewed:
Evolext work is research-, assessment-, and prototype-stage. Guidance and source findings do not establish production readiness, compliance, or universal security.
Questions along the migration path.
Do we need to replace everything at once?
No. Plan bounded increments around dependencies, data lifetime, and operational constraints. The sequence should follow reviewed evidence, not a universal schedule.
Can we begin before every vendor supports PQC?
Yes. Inventory, prioritization, and vendor questions can begin first. Do not treat an unavailable implementation path as deployable; record when to revisit it.
When might a hybrid approach be appropriate?
When a defined protocol and supported implementation combine classical and post-quantum mechanisms in a way suitable for the use case. Evaluate its actual specification, interoperability, security review, and operational costs; do not invent a custom combination.
What happens if testing fails?
Record the failure and unmet criteria. Investigate, revise, defer, or stop, then repeat relevant tests if the candidate changes. A negative result is useful evidence.
Can every cryptographic change be rolled back?
No. Keys, certificates, persisted data, and trust relationships may require explicit recovery or transition measures beyond a software rollback. Establish those constraints before deployment planning.
How do tested behavior and production readiness differ?
A laboratory result demonstrates only the tested conditions. Production decisions also require supported integrations, operational controls, authorized change, recovery planning, and appropriate independent review.
Prepare a starting point, not a confidential upload.
- A high-level system outline and the decision you need to make
- Known owners, data lifetimes, dependencies, and vendor constraints
- Available non-sensitive evidence and access restrictions
Tell us which system or migration decision you want to explore. Keep the first inquiry high-level; do not submit credentials, private keys, secrets, or confidential reports.
Submitted contact details are stored in Supabase, and notifications may be sent through LINE.