Discover → Plan → Remediate → Validate

Use this workflow for a representative supported Linux workload and a concrete migration task. The security or PQC migration lead defines the requirements with the application or infrastructure owner.

  1. Discover: capture active cryptography and connect it to available application, library, process, and network evidence.
  2. Plan: compare acceptable options using dependencies, blast-radius analysis, measurements, simulation, and catalog-backed controlled experiments where applicable.
  3. Remediate: choose a customer-executed native upgrade, supported proxy protection, or supported OpenSSL implementation redirection.
  4. Validate: compare before-and-after cryptographic behavior or negotiation and measured costs for the evaluated environment and path.

Current comparisons are operator-assisted. Automated workload-specific recommendations are planned. Your team reviews the evidence and chooses the action.

What you will see in the Console

Raw Evidence

Raw Evidence shows cryptography and network activity captured during a scan, together with process and implementation details when available.

Findings and Inventory

Findings highlight concerns to review. Inventory shows workloads, libraries, and endpoints found in the scan. These help prioritize investigation; they do not establish complete coverage.

Execution Match

Trace the relationship between a concern, target, process, network signature, implementation, and crypto activity. Inspect the underlying evidence before relying on a relationship. Dependency and blast-radius analysis identify impacts to review; they do not guarantee every affected component has been found.

Performance Lab and option evaluation

Performance Lab shows measured samples and related operations from the workload. Security requirements constrain acceptable options before comparing their performance.

Keep observed workload measurements, simulated estimates, and controlled-experiment results distinct. Record the operation, implementation, test conditions, workload, and measured path. A simulated alternative does not establish that a native application upgrade was performed or that it will have the same cost in deployment.

Supported remediation

A native application, library, or configuration upgrade is executed by your team. A supported proxy path can protect a configured connection segment to a compatible destination. Supported OpenSSL implementation redirection preserves expected output and application behavior without changing source code.

Implementation substitution is different from algorithm substitution. OpenSSL redirection is not a demonstrated native post-quantum algorithm upgrade. Transparent algorithm substitution remains future research. See the remediation scope guide for prerequisites and boundaries.

Policy Protection

Review the selected target, current and proposed protection, status, and policy hits. Active policies apply to new matching connections only. Status alone does not prove full-path protection.

Read results in the context of the scan

A runtime snapshot describes activity captured during a specific collection window and workload. Check scan status, exercised paths, coverage, and missing observations before interpreting absence.

For validation, compare relevant before-and-after observations and measured costs under documented conditions. Distinguish original application behavior, proxy results, and simulation. Use the migration review guide to record the decision and its limits.