A policyholder file has to stay private for a lifetime.
Encrypt nonpublic information in transit with post-quantum TLS across carrier, agency and field systems, inventory the ciphers and certificates in use, and show the state regulator a program rather than a promise.
Q-day is uncertain. The requirements for insurance are not.
Nobody knows when a cryptographically relevant quantum computer will arrive (Q-day), but your cryptography requirements do not depend on that date. Four reasons to start now:
AI is already finding weaknesses in algorithms
Anthropic’s Claude Mythos preview found serious weaknesses in candidate algorithms without a quantum computer. Cryptography can fail before Q-day arrives.
Adversaries are harvesting encrypted data now
They are collecting policyholder and health records which stay sensitive for decades, to decrypt when Q-day arrives: harvest now, decrypt later.
Regulators already require PQC migration
For an insurer that means the encryption of nonpublic information, the asset inventory and the accountable CISO NYDFS Part 500 requires, and the risk-based program NAIC Model Law 668 and the state laws built on it expect.
Estimates for Q-day keep shrinking
Google has set 2029 as the target for its own migration. If yours is not finished in time, the foundation of policy, claims and payment systems is at risk.
Google’s 2029 target and resource estimates: QuSecure, April 2026. NIST IR 8547, initial public draft, November 2024. Anthropic, Claude Mythos preview, 2026.
Why use QuProtect?
Cryptography belongs in a layer you control and configure, not in application code.
No rewrite, no rip-and-replace
QuProtect moves critical and legacy systems to PQC in a fraction of the time and cost.
Discovery and remediation in one platform
Many PQC solutions stop at discovery and leave the fix to you.
Built for large, complex organizations with highly sensitive traffic
Developed with the U.S. Army and U.S. Air Force.
Nothing is re-coded
An insurer cannot take policy and claims systems down to re-code them, so QuProtect does not ask for it.
The next migration is a configuration change
It is made from an Orchestrator you control, not run as another program.
Proven in production
Banco Sabadell validated post-quantum TLS in four months.
Use case in action
Your network, from the cryptography it runs today to the policy change that keeps it current. Move through the five steps, or click a number on the drawing.
-
Field and agencies
- Telematics and UBI devices cannot be upgraded
- Adjuster mobile capture
- Agency portals cannot be upgraded
-
Carrier core
- Policy administration cannot be upgraded
- Claims platform
- Data warehouse
-
Partners (not yours to change)
- Third-party administrators
- Reinsurers
- Regulator filings
Legacy cryptography, and what Q-day does to it
Telematics units and agency portals reach the carrier on TLS 1.0, and policy administration, claims and the data warehouse reach third-party administrators, reinsurers and the regulator on TLS 1.2 with RSA key exchange. Traffic recorded today can be stored until a quantum computer running Shor’s algorithm recovers those keys, and a policyholder file stays sensitive for a lifetime.
Sensors find the legacy negotiations and rank the violations
Reconnaissance sensors read what is on the wire and record the cipher suites, protocols, certificates and keys in use, without touching a system. Each policy violation is ranked by severity: TLS 1.0 on the field and agency hops first, RSA key exchange on the partner links next.
Encryptors remediate at the network layer
A gateway in front of the field devices and the agency portals and sidecars beside policy administration, claims and the data warehouse carry each hop over TLS 1.3 with NIST post-quantum key exchange, X25519MLKEM768. No code changes, and nothing in the field is replaced.
Data in transit is secured, and the CBOM proves it
Nonpublic information recorded in transit from now on is not readable by a future quantum computer. The CBOM lists each connection’s protocol, algorithm and certificate with no open violations, in the form NYDFS Part 500 and the state examiner ask to see.
Crypto-agility: the next algorithm is a policy change
When a standard moves, the Orchestrator pushes the new policy to each encryptor and the connections renegotiate, here from ML-KEM-768 to ML-KEM-1024, while traffic keeps flowing. The program does not start again.
Other use cases
Cryptographic inventory for NYDFS Part 500 and NAIC 668
A live CBOM of the ciphers, certificates and keys in use across carrier, agency and field systems, ready for the risk assessment.
Post-quantum key exchange to TPAs and reinsurers
Partner links carry post-quantum TLS to the carrier’s edge, and end to end where the partner negotiates ML-KEM, so policyholder data recorded in transit today is not readable later.
Certificates at 47-day lifetimes
Automated provisioning and rotation from the Orchestrator across carrier and agency systems.
Evidence for the state examiner
Logged handshakes and rotations plus a CBOM with owner and risk context, filed as the program the regulator asks for.
TLS 1.3 uplift on policy and claims platforms
Systems on TLS versions nobody wants to touch are carried over TLS 1.3 at the network layer, with no application change.
Field devices protected in place
Telematics units, adjuster capture and property IoT sit behind gateway encryptors rather than being replaced.
Mutual TLS identity per application
Agency portals, claims and policy systems pair over post-quantum mTLS with their own identities.
Algorithm change by policy
The next standard is a policy push from the Orchestrator, not another migration.