SQP QuantumEdge: adaptive post-quantum proxy

Quantum-safe today. Without touching your applications.

Put SQP QuantumEdge in front of the servers you can't rewrite. Quantum-ready clients get hybrid post-quantum TLS automatically, everyone else keeps working, and your applications stay exactly as they are.

Start a pilotSee how it works
X25519MLKEM768FIPS 140-3 validated corePingora, written in RustNo code changes
Now
65%+ of human traffic to Cloudflare already uses post-quantum key exchange (Apr 2026)
2029
Google and Cloudflare aim to be fully post-quantum
2030
US EO 14409: post-quantum key establishment for federal high-value systems. NIST deprecates RSA and ECC
2033
NSA CNSA 2.0: quantum-resistant only for national security systems
2035
NIST disallows quantum-vulnerable algorithms
The threat

Data you encrypt today can be read tomorrow

Attackers record encrypted traffic now and unlock it later with a quantum computer. It's called harvest now, decrypt later, and it is already happening.

Health records, payments, government and defense data, trade secrets: anything that must stay secret for years is at risk the moment it crosses the internet.

today years later 1. Record todayAttackers copy encrypted trafficas it crosses the internet.2. Store for yearsStorage is cheap. Recordings waiton disk until the tools catch up.3. Unlock on Q-DayA large quantum computer breakstoday's key exchange. At risk: anything that must stay secret for years
The real problem

You can't upgrade everything at once

The client side has already moved: modern browsers speak post-quantum. The question is whether your servers answer. Rewriting every system takes years, and the recording is happening now.

Legacy applications

Old code, no source, or no budget to rewrite.

Vendor software

You don't control how it encrypts.

Devices and IoT

Too small to run the new algorithms themselves.

Thousands of clients

Partners and customers upgrade on their own schedule.

Our approach

Don't rewrite the app. Put a quantum-safe proxy in front of it.

SQP QuantumEdge terminates TLS for every client, chooses hybrid post-quantum or classical per client, and load-balances across your back ends. The internet-facing link is quantum-safe the moment the proxy is live.

Classical encryption is used only on the short hop between the gateway and your server, inside the same rack or network segment.

Clients, anywhere Modern browser or appQuantum-ready: hybrid ML-KEM Partner or mobile clientQuantum-ready: hybrid ML-KEM Older clientNot yet quantum-ready Untrusted network: the internet or a shared WAN Hybrid TLS 1.3X25519 + ML-KEM-768 Classical fallback, until policy says PQC-only Traffic captured todaystays unreadable later Your data center: same rack, trusted Legacy server or applicationUnchanged: RSA / ECC as today Classical, local only SQP QuantumEdgeGateway in front of the legacyserver; terminates hybrid TLS Proxy manager: one policy, every gatewayChange algorithms by configuration, not code.Move one route at a time. Staged rolloutClassicalHybridPQC-only

No code changes

Your applications, their code and their certificates stay exactly as they are. No SDK, no recompilation.

Every client keeps working

Quantum-ready clients get hybrid ML-KEM. Others get classical TLS, with no error and no forced upgrade.

Protected from day one

Each service is quantum-safe on the internet side as soon as it sits behind the proxy.

Scales out

Load-balances across your back ends; API servers scale out behind the proxy.

Adaptive by design

How the proxy adapts to each client

In plain words: the door checks which key each visitor carries, and opens the strongest lock you both can use.

Client says hello Its first message (ClientHello) lists the key exchanges it supports Hybrid group X25519MLKEM768 offered? Yes No Hybrid post-quantum TLS 1.3 X25519 + ML-KEM-768, both secrets in one key schedule. Recorded traffic stays safe against quantum attacks. Classical TLS (X25519 or P-256) Still secure today. No error, no forced upgrade. Under a PQC-only policy, the connection is refused instead, so nothing falls back silently.
Hybrid key exchange

Two locks on every quantum-ready connection

A classical and a post-quantum algorithm run side by side in one TLS 1.3 handshake. The session stays safe if either X25519 or ML-KEM-768 holds.

Client Browser, app or agent Server side Gateway or PQC server Generates X25519 key share ML-KEM-768 public key Responds with X25519 key share ML-KEM ciphertext 1 ClientHello: both key shares in one message 2 ServerHello: both answers in one message Secret A: classical From X25519 Secret B: post-quantum From ML-KEM-768 (FIPS 203) Session keys = TLS 1.3 key schedule (A + B) An attacker has to break both algorithms, not just one
FunctionQuantum-ready clientsLegacy clients
Key exchangeX25519MLKEM768 (X25519 + ML-KEM-768, FIPS 203)ECDHE (X25519, P-256)
TransportTLS 1.3, both secrets in one key scheduleStandard TLS
CertificatesYour existing X.509 certificatesYour existing X.509 certificates
SignaturesML-DSA-65 (FIPS 204): private PKI first; public-facing certificates as a future phaseECDSA / RSA
The engine

Built on Pingora, in Rust

Pingora is the Rust proxy framework Cloudflare built to replace its NGINX-based service. SQP QuantumEdge adds hybrid post-quantum TLS, per-client adaptation and policy control on top.

Rust is memory-safe: it rules out whole classes of bugs, such as buffer overflows and use-after-free, that have caused some of the worst TLS breaches.

1T+

requests a day served by Pingora at Cloudflare

70%

less CPU than the NGINX-based service it replaced

67%

less memory under the same traffic load

Figures are Cloudflare's own production results (Cloudflare blog, 2022).

Validated cryptography, not just claimed

Cryptography comes from AWS-LC through aws-lc-rs, a FIPS 140-3 validated module with ML-KEM inside the validation. Hybrid X25519 + ML-KEM-768 runs in FIPS-approved mode, which regulated buyers under FedRAMP and FISMA need.

Central control

One place to run every proxy

See every proxy, wherever it runs. Check its configuration and health. Push updates and policy changes from one place.

That is crypto agility in practice: change your crypto policy once, and it applies everywhere.

Proxy manager See every proxy, check config and health, push updates. Change crypto policy once. Crypto agility in practice New standard or weakened algorithm? Publish policy v14; every gateway follows. Evidence for auditors Which gateways run which policy, and a CBOM of the algorithms that are live. SQP QuantumEdgeData centerIn front of legacy appspolicy v13healthySQP QuantumEdgeCloud regionIn front of API serverspolicy v13healthySQP QuantumEdgePartner edgeB2B and open-banking linkspolicy v13healthySQP QuantumEdgeBranch or plantLocal servicespolicy v13healthy
Deployment modes

Two modes, one policy

Stated plainly: GPU work runs outside the FIPS boundary, so regulated deployments stay in FIPS mode.

Default: CPU

FIPS mode

  • Every operation runs inside the FIPS 140-3 validated module.
  • Hybrid X25519 + ML-KEM-768 in FIPS-approved mode.
  • For FedRAMP, FISMA and other mandates.
Optional: GPU

Performance mode

  • ML-KEM and ML-DSA batched on NVIDIA GPUs (cuPQC).
  • Keys seeded by a quantum random number generator; pairs naturally with SQP Sovereign Entropy.
  • For high volume where FIPS is not required.
Security engineering

Hardened at every layer

Memory safety

Rust proxy and server: no buffer overflows or use-after-free.

Constant-time crypto

Resists timing attacks on the proxy and the server.

Keys wiped after use

Secret material is zeroized from memory when done.

Supply-chain assurance

Signed SBOM, audited dependencies and reproducible builds.

Plus a CBOM: a cryptography bill of materials that shows which algorithms are live.

What changes for you, and what doesn't

Your applicationsNo code changes: the proxy sits in front.
Your clientsNo SDK, no forced upgrade: post-quantum is automatic for clients that support it.
Your certificatesStandard TLS 1.3 with your existing X.509 certificates.
Your complianceFIPS 140-3 validated cryptography for FedRAMP and FISMA.
Your next changeChange algorithms through policy, from one manager.
Who needs it

Anyone whose data must stay secret for years

Government and public sector

CNSA 2.0 and the 2030 federal key-establishment deadline.

Defense and aerospace

CMMC and ITAR obligations, and long-lived classified data.

Financial services and payments

PCI DSS, open banking and partner APIs.

Healthcare and genomics

HIPAA, and data that stays sensitive for a lifetime.

Energy and critical infrastructure

NERC CIP, and systems with decades-long service lives.

Telecommunications

Carrier-scale subscriber data.

How we start

Four steps, protection from step two

Each step protects you on its own. No big-bang migration.

1

Assess

Find the services that carry long-life data. SQP Assess maps your exposure.

2

Pilot

Put the proxy in front of one application. It is protected from that moment.

3

Roll out

Expand, and run every proxy from the manager.

4

Tighten

Raise the policy over time, toward PQC-only, and move identity to ML-DSA.

Four reasons to choose SQP QuantumEdge

A proven pattern

Protect what you can't change, with an adaptive proxy in front.

A proven engine

Pingora, the Rust proxy framework built by Cloudflare.

Validated crypto

FIPS 140-3 validated library, with ML-KEM inside.

Central control

One manager for every proxy and every policy.

Is the legacy system on the client side instead?

When the server is quantum-ready but the client can't change, use SQP QuantumBridge. If both ends are legacy, use the two together.

Let's make your systems quantum-safe

Start with a pilot in front of one application. No code changes, no client upgrades.

Start a pilotsales@superqubit.ai