Your clients can't wait for a rewrite. Neither can your data.
SQP QuantumBridge runs beside the client software you can't change and upgrades its outbound connections to hybrid post-quantum TLS. No code changes, no recompilation, no new protocol, and classical encryption never leaves the machine.
Servers get upgraded. Clients get left behind.
Post-quantum plans usually start with servers. But every connection has two ends, and the client end is often the one you can't touch. If it still uses classical key exchange, its traffic can be recorded today and decrypted later.
Vendor software
Desktop and back-office applications whose encryption you don't control.
Integrations and scripts
Batch jobs and connectors calling partner or cloud APIs, built years ago.
Builds nobody can recompile
Lost source, retired toolchains or certified binaries that must not change.
Branch and plant systems
Remote sites that report to central, quantum-ready services.
An agent beside the client, quantum-safe on the wire
The legacy client keeps its normal protocol and connects to the agent on the same host. From there, the connection across the untrusted network is hybrid post-quantum TLS 1.3 to quantum-ready servers.
Move one route at a time: a single partner API, a single cloud service, then the next.
No change to the client
The application keeps its normal protocol and settings. No code changes, no recompilation.
Same-host trust boundary
Classical encryption never leaves the client machine. Only quantum-safe traffic crosses the network.
Refuse downgrades
Once your servers are ready, require PQC so no connection can quietly fall back to classical encryption.
Visible in your monitoring
Negotiation telemetry shows which connections are hybrid, classical or PQC-only, as migration evidence.
What happens on the client machine
The agent is a single static binary that runs on or beside the legacy client. It takes over the network-facing part of the connection, so the application never has to learn new cryptography.
Algorithms sit behind a policy layer, not in application call sites, so they can change by configuration as standards evolve.
Compatible while you migrate. Strict when you're ready.
One setting decides what happens when a server can't speak post-quantum yet.
During migration
Nothing breaks while servers catch up, and every fallback is visible, so you know exactly which routes still need work.
Once servers are ready
No attacker or misconfiguration can push a connection back to classical encryption. Quantum-safe becomes guaranteed, not best effort.
See every connection, prove every migration
Negotiation telemetry is exported over OpenTelemetry (OTLP) to the monitoring tools you already use.
- Which routes are hybrid, classical or PQC-only.
- Which servers still force a fallback.
- Evidence for auditors and migration reporting.
| Route | Key exchange | Result |
|---|---|---|
| payments-api.partner.example | X25519 + ML-KEM-768 | Hybrid |
| reports.cloud.example | P-384 + ML-KEM-1024 | Hybrid |
| hq-gateway.internal.example | ML-KEM-1024 | PQC-only |
| legacy-ftp.vendor.example | X25519 fallback | Classical |
| old-crm.vendor.example | None offered | Refused |
Illustrative example of negotiation telemetry; route names are fictional.
One rule set, every agent
Central policy, enforced at every endpoint. Move from classical to hybrid to PQC-only by configuration, one route at a time.
Classical
Baseline. Measure what connects and how.
Hybrid
Classical plus ML-KEM. Quantum-safe, fully compatible.
PQC-only
Require post-quantum and refuse downgrades.
kem = "x25519_mlkem768" # hybrid key exchange fallback = "x25519" # for servers not yet ready rollout = "hybrid" # classical | hybrid | pqc-only require_pqc = false # true refuses downgrade fips_mode = true # FIPS-approved mode metrics = "otlp" # telemetry export
Algorithms, assurance and roadmap
| Capability | Detail | Status |
|---|---|---|
| Key establishment | Hybrid X25519 + ML-KEM-768 (default); P-384 + ML-KEM-1024 for higher assurance; ML-KEM-768 / ML-KEM-1024 (FIPS 203) | Available |
| Protocol | TLS 1.3 (RFC 8446) on the network hop | Available |
| Cryptographic core | AWS-LC via aws-lc-rs: FIPS 140-3 validated, with ML-KEM inside the validation boundary; hybrid runs in FIPS-approved mode | Available |
| Telemetry | Negotiation metrics exported over OTLP | Available |
| Signatures | ML-DSA, SLH-DSA; LMS / XMSS for firmware (FIPS 204, FIPS 205, SP 800-208) | Roadmap |
| More protocols | SSH, IKEv2 / IPsec | Roadmap |
| Agility reserve | HQC backup key-encapsulation mechanism (selected by NIST in 2025) | Roadmap |
| Keys and PKI | PKCS#11 / HSM-backed key storage; hybrid and dual-certificate issuance | Roadmap |
Extra bytes on the wire per hybrid handshake
Extra compute for the ML-KEM operations
Lines of client code to change
Memory-safe implementation of the whole crypto path
Trust model
The agent sits next to the endpoint that is still classical, so the classical hop stays on the same host. The network hop stays confidential as long as either the classical or the post-quantum algorithm holds.
Scope
SQP QuantumBridge secures the data path. It is not a discovery scanner, a governance dashboard or a certificate authority. Pair it with SQP Assess for inventory and reporting.
Mapped to the rules you answer to
Client connections count too. Mandates cover key establishment wherever it happens, not just on your servers.
| Framework | What it requires |
|---|---|
| US EO 14409 (June 2026) | Post-quantum key establishment for high-value systems by Dec 31, 2030; signatures by Dec 31, 2031 |
| NSA CNSA 2.0 | ML-KEM-1024 and ML-DSA-87, phased transition 2027 to 2035 |
| NIST IR 8547 (draft) | RSA and ECC deprecated after 2030, disallowed after 2035 |
| FIPS 140-3 | Validated cryptographic core, as FIPS 140-2 modules move to historical |
| Canada ITSM.40.001 | High-priority systems by end of 2031, remaining systems by 2035 |
| EU PQC roadmap (2025) | 2026, 2030 and 2035 milestones, high-risk use cases first |
From one route to every client
Find
Identify legacy clients and the routes they use. SQP Assess maps your exposure.
Pilot one route
Deploy the agent beside one client and one quantum-ready server. Watch the telemetry.
Expand
Add routes and clients under one central policy.
Require PQC
Switch routes to PQC-only as servers become ready, and refuse downgrades.
Works with the rest of the SQP portfolio
SQP QuantumEdge
Is the server legacy too? Put SQP QuantumEdge in front of it, and only quantum-safe traffic crosses the network.
SQP Assess
Find the legacy clients and routes that carry long-lived data, and report progress to your board.
SQP Sovereign Entropy
Strengthen the keys behind every connection with client-owned, quantum-sourced randomness.
Protect one legacy client this month
Pilot SQP QuantumBridge on one route and see the telemetry for yourself.