Fix the cryptography without touching the application
Encryptors carry each connection over post-quantum mTLS at the network layer. An administrator sets policy in the Orchestrator; every encryptor in scope follows, with no code changes and no appliances.
Each links to its definition, with the source it came from.
All termsSecure the connection
- A client and a critical system negotiate on legacy cryptography, RSA key exchange on an aging TLS version.
- Encryptors drop in beside each end as software sidecars. Nothing is installed on either machine.
- The connection renegotiates to ML-KEM key exchange over post-quantum TLS 1.3, and traffic keeps flowing.
Then change by policy
- An administrator sets a policy in the Orchestrator: which algorithm, and where it applies.
- The Orchestrator distributes that policy to every encryptor in scope.
- Encryptors renegotiate connections on the new algorithm while traffic keeps flowing.
What remediation covers
Each finding class Reconnaissance surfaces has a remediation path on the same platform.
- Finding
- TLS below 1.3 on applications that cannot be upgraded
- Remediated
- Carried over post-quantum TLS 1.3 at the network layer, no application change
- Finding
- Out-of-policy algorithms, from RSA-1024 to deprecated ciphers
- Remediated
- Changed by policy from the Orchestrator across every encryptor in scope
- Finding
- Expiring and unmanaged certificates, ahead of CA/Browser Forum lifetimes shortening to 47 days by 2029
- Remediated
- Automated certificate provisioning and rotation, with your CA keys staying yours
- Finding
- Harvest-now-decrypt-later exposure on long-lived data in motion
- Remediated
- Hybrid post-quantum key exchange on the connection today, whatever the endpoint supports
Findings arrive from the live inventory. See Reconnaissance (Discovery)
The system nobody will touch
This is the design case. A critical system on an operating system old enough that its cryptographic libraries cannot negotiate a post-quantum key exchange, owned by a team with no appetite for a platform migration, carrying traffic that cannot stop.
- What does not change
- The application is not modified. The operating system is not modified. No cryptographic library is recompiled, no platform is migrated, and the vendor relationship behind the application stays as it is.
- What does change
- An encryptor sits beside each end of the connection as a software sidecar, or as a gateway where a sidecar is not possible, and negotiates on the system's behalf. The connection carries ML-KEM key exchange over post-quantum TLS 1.3. From the application's point of view, its own cryptography did not change.
- What the application team is asked to accept
- A software encryptor deployed beside the workload, a routing change to send traffic through it, and a rollback path that is the same change in reverse. No code review, no release cycle, and no library audit.
- Systems already behind a load balancer
- The encryptor deploys as a gateway in front of the pool rather than beside each instance, so one deployment covers the set.
- Where the boundary is
- The encryptor has to run somewhere on the path. Where nothing can be deployed beside a workload and no gateway can sit in front of it, this is not the right answer, and we will say so on the call rather than at the end of a pilot.
Ten systems or ten thousand, one platform. Cloud, hybrid, on-premises and air-gapped, without re-architecting. One policy reaches every encryptor in scope, whether that is four systems or four thousand.
Frequently asked questions
-
Will QuProtect Resilience work with a mainframe or a 15-year-old application that cannot be updated?
Yes, and that is the design case. Encryptors sit at the network layer and carry the connection over post-quantum TLS 1.3, so the application, its code, its libraries and its vendor relationship stay exactly as they are.
-
What if nothing can be deployed beside the workload?
Then the encryptor deploys as a gateway in front of it instead, which is the case NIST CSWP 39-upd1 section 4.6 addresses. Where neither a sidecar nor a gateway can sit on the path, QuProtect is not the answer for that system, and we will say so during scoping.
-
Does this require new hardware?
No. QuProtect R3 is software only. It deploys on infrastructure you already run, cloud, on-premises or air-gapped, with no appliances to procure or maintain.
-
How fast does a policy change take effect?
A policy change takes effect as soon as the Orchestrator publishes it, and every encryptor in scope renegotiates its connections on the new cryptography from that point. No per-system projects, and no maintenance windows for the applications themselves.
-
Who operates the platform?
Your team does. QuProtect R3 is self-managed: it runs in your environment under your control, and your keys stay yours. QuSecure operates nothing on your behalf.
Terms on this page
-
AES Advanced Encryption Standard
A symmetric block cipher approved by the U.S. government for protecting electronic data, using one key to both encrypt and decrypt. Because a symmetric cipher does not rest on the mathematics Shor’s algorithm attacks, AES is affected differently by quantum computing than public-key algorithms such as RSA.
Source: NIST , CNSSI 4009-2022, adapted from FIPS 197 (csrc.nist.gov)
-
Cryptographic agility
The capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware and infrastructures while preserving security and ongoing operations. It is the property that makes a migration a configuration change rather than a rebuild.
Source: NIST , NIST CSWP 39-upd1 (csrc.nist.gov)
-
ECC Elliptic-curve cryptography
Public-key cryptography built on elliptic curves, which NIST specifies for U.S. government use in SP 800-186 under discrete-logarithm-based cryptography. The discrete logarithm is the second of the two problems a cryptographically relevant quantum computer would solve, so ECC is replaced in a post-quantum migration alongside RSA.
Source: NIST , NIST SP 800-186: Recommendations for Discrete Logarithm-Based Cryptography (csrc.nist.gov)
-
IPsec Internet Protocol Security
A set of services providing interoperable, cryptographically based security for IPv4 and IPv6: access control, connectionless integrity, data origin authentication, rejection of replayed packets, and confidentiality through encryption. IPsec secures traffic below the application, so it protects systems that cannot be changed themselves.
Source: NIST , CNSSI 4009-2022 (csrc.nist.gov)
-
Key establishment
A procedure that results in secret keying material shared among different parties. It is the step a quantum computer threatens first, and the step ML-KEM replaces.
Source: NIST , NIST SP 800-56A Rev. 3 (csrc.nist.gov)
-
ML-KEM Module-Lattice-Based Key-Encapsulation Mechanism
NIST’s standardized post-quantum key-encapsulation mechanism, published as FIPS 203. It is the algorithm that replaces the key exchange in protocols like TLS, and its security rests on lattice problems rather than on the factoring and discrete-logarithm problems a quantum computer can solve.
Source: NIST , FIPS 203 (csrc.nist.gov)
-
RSA
A public-key algorithm used for key establishment and for generating and verifying digital signatures. Its security rests on the difficulty of factoring large numbers, which is one of the two problems a cryptographically relevant quantum computer would solve, so RSA is among the algorithms a post-quantum migration has to replace.
Source: NIST , NIST SP 800-175B Rev. 1 (csrc.nist.gov)
-
TLS Transport Layer Security
A security protocol providing privacy and data integrity between two communicating applications, composed of the TLS Record Protocol and the TLS Handshake Protocol. TLS carries most of the encrypted traffic on a typical network, so it is usually where a post-quantum migration starts.
Source: NIST , CNSSI 4009-2022 (csrc.nist.gov)
Bring the system nobody will touch.
A technical session against your own architecture.