SQP QuantumBridge: post-quantum agent for legacy clients

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.

Hybrid X25519 + ML-KEM-768P-384 + ML-KEM-1024FIPS 140-3 validated coreSingle static binary
2026
FIPS 140-2 modules moved to historical (September). New buys need FIPS 140-3
2030
US EO 14409: post-quantum key establishment for federal high-value systems by Dec 31
2031
US: post-quantum signatures. Canada: high-priority systems quantum-safe
2033
NSA CNSA 2.0: national security systems on quantum-resistant algorithms
2035
NIST disallows quantum-vulnerable algorithms. Canada: remaining systems
The forgotten half

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.

How it works

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.

Legacy client site: same host, trusted Legacy client applicationUnchanged: RSA / ECC as today Classical, local only SQP QuantumBridge agentSidecar beside the legacy client;upgrades the outbound hop Untrusted network: the internet or a shared WAN Hybrid TLS 1.3X25519 + ML-KEM-768 Traffic captured todaystays unreadable later Quantum-ready servers Your upgraded serversQuantum-ready servicesCloud and SaaS servicesHybrid ML-KEM supportedPartner APIsQuantum-ready endpoints Central policy: one rule set, every agentRequire PQC and refuse downgrades when ready.Export negotiation telemetry to your monitoring. Staged rolloutClassicalHybridPQC-only

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.

Inside the agent

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.

One client machine: the trusted boundary Legacy application Vendor software, an old build or an integration script. Unchanged: RSA / ECC as today local only SQP QuantumBridge agent Single static binary, on or beside the client Terminates the local connectionApplies your policy: classical, hybrid or PQC-onlyOpens hybrid TLS 1.3 to the serverFIPS 140-3 validated cryptographic coreExports negotiation telemetry (OTLP) Untrusted network Hybrid TLS 1.3 Quantum- ready server
Downgrade protection

Compatible while you migrate. Strict when you're ready.

One setting decides what happens when a server can't speak post-quantum yet.

require_pqc = false

During migration

Legacy clienttoQuantumBridgetoserver not ready
Falls back to X25519andrecords it in telemetry

Nothing breaks while servers catch up, and every fallback is visible, so you know exactly which routes still need work.

require_pqc = true

Once servers are ready

Legacy clienttoQuantumBridgetoserver not ready
Connection refusedno silent downgrade

No attacker or misconfiguration can push a connection back to classical encryption. Quantum-safe becomes guaranteed, not best effort.

Visibility

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.
RouteKey exchangeResult
payments-api.partner.exampleX25519 + ML-KEM-768Hybrid
reports.cloud.exampleP-384 + ML-KEM-1024Hybrid
hq-gateway.internal.exampleML-KEM-1024PQC-only
legacy-ftp.vendor.exampleX25519 fallbackClassical
old-crm.vendor.exampleNone offeredRefused

Illustrative example of negotiation telemetry; route names are fictional.

Policy, not code

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.

policy.toml (example)
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
Specifications

Algorithms, assurance and roadmap

CapabilityDetailStatus
Key establishmentHybrid X25519 + ML-KEM-768 (default); P-384 + ML-KEM-1024 for higher assurance; ML-KEM-768 / ML-KEM-1024 (FIPS 203)Available
ProtocolTLS 1.3 (RFC 8446) on the network hopAvailable
Cryptographic coreAWS-LC via aws-lc-rs: FIPS 140-3 validated, with ML-KEM inside the validation boundary; hybrid runs in FIPS-approved modeAvailable
TelemetryNegotiation metrics exported over OTLPAvailable
SignaturesML-DSA, SLH-DSA; LMS / XMSS for firmware (FIPS 204, FIPS 205, SP 800-208)Roadmap
More protocolsSSH, IKEv2 / IPsecRoadmap
Agility reserveHQC backup key-encapsulation mechanism (selected by NIST in 2025)Roadmap
Keys and PKIPKCS#11 / HSM-backed key storage; hybrid and dual-certificate issuanceRoadmap
~1,600 B

Extra bytes on the wire per hybrid handshake

AWS-LC reference measurement
80–150 µs

Extra compute for the ML-KEM operations

AWS-LC reference measurement, not a SuperQubit benchmark
0

Lines of client code to change

Rust

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.

Mandates

Mapped to the rules you answer to

Client connections count too. Mandates cover key establishment wherever it happens, not just on your servers.

FrameworkWhat 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.0ML-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-3Validated cryptographic core, as FIPS 140-2 modules move to historical
Canada ITSM.40.001High-priority systems by end of 2031, remaining systems by 2035
EU PQC roadmap (2025)2026, 2030 and 2035 milestones, high-risk use cases first
How we start

From one route to every client

1

Find

Identify legacy clients and the routes they use. SQP Assess maps your exposure.

2

Pilot one route

Deploy the agent beside one client and one quantum-ready server. Watch the telemetry.

3

Expand

Add routes and clients under one central policy.

4

Require PQC

Switch routes to PQC-only as servers become ready, and refuse downgrades.

Works with the rest of the SQP portfolio

Protect one legacy client this month

Pilot SQP QuantumBridge on one route and see the telemetry for yourself.