up:: Doing the Work MOC
PQC for Insurance Carriers
A carrier sits on both sides of the post-quantum transition, and that is what makes its position different from every other financial institution’s. On one side it is an obligated party: a life or health insurer holds records whose sensitivity is measured against a human lifetime, which is the longest retention horizon in financial services and the textbook case for harvest now, decrypt later. On the other side it is the party writing requirements for everybody else, because the cyber insurance application has quietly become the closest thing the market has to a mandatory controls baseline, and the line on that application asking whether data is encrypted is the door quantum risk walks through.
This note is general education about regulation and market practice, not legal or actuarial advice. Whether any particular control satisfies a particular regulator, and how any particular policy responds, are determinations a carrier makes with its own counsel.
The short version:
- A carrier’s own exposure is a retention problem before it is a cryptography problem. Life, annuity, and health records outlive the cryptography protecting them by decades, which is what makes them the highest-value harvest target in finance.
- If the carrier is licensed in New York, encryption of nonpublic information in transit is already unconditional under 23 NYCRR 500.15, and the standard it points at is “industry standards,” which moves when the industry does.
- If the carrier is a health plan, encryption is currently only “addressable” under the HIPAA Security Rule, and a proposed rule would make it required. The weakest current obligation is attached to the longest-lived data.
- The underwriting questionnaire is the lever nobody has pulled yet. Carriers already move the whole market’s control baseline through it, and no standard application asks a cryptographic-agility question.
- Nothing here requires a carrier to underwrite quantum risk. It requires knowing which of its own records will still matter when the cryptography protecting them stops working.
Why does a carrier hold the hardest version of this problem?
Because of how long its records stay live. Most of the harvest-now-decrypt-later argument is a fight about whether data recorded today will still be sensitive when a cryptographically relevant quantum computer exists, and for most industries that is a genuine argument with a defensible answer on both sides. A life insurer does not get to have that argument. A policy written on a 30-year-old today can pay a claim in 2080, and the underwriting file behind it contains medical history, family history, financial disclosures, and identity documents that were sensitive when they were collected and will be sensitive when the claim is paid. The same is true of annuity files, long-term-care files, and disability files.
That is what the vulnerability test is asking. The question is never how strong the encryption is today, it is how long the plaintext underneath it stays valuable, and a carrier’s answer is longer than a bank’s, longer than a retailer’s, and longer than most of its own reinsurers’. Applying Mosca’s theorem to a life book is uncomfortable in a specific way: the shelf life term dominates the equation so completely that the other two terms barely move the result.
The second structural feature is that a carrier’s data is unusually concentrated. Claims, underwriting, actuarial, and policy administration all touch the same records, and those systems are frequently older than the security program wrapped around them. Policy administration in particular runs on platforms with multi-decade service lives, which is exactly the profile crypto-agility exists to describe and exactly the profile that lacks it.
What actually obligates a carrier today?
Three regimes, and they disagree with each other in a way worth knowing precisely, because a carrier is frequently subject to more than one at the same time.
| Regime | Who it reaches | What it says about encryption | Status |
|---|---|---|---|
| 23 NYCRR Part 500 | Anyone licensed under the New York Insurance Law, Banking Law, or Financial Services Law | Written policy requiring encryption “that meets industry standards” for nonpublic information in transit over external networks and at rest | In force. Section 500.15 compliance ran 1 year from the 1 November 2023 effective date |
| HIPAA Security Rule, 45 CFR 164.312 | Health plans, as covered entities | Encryption at rest is “Addressable”; encryption in transit is “Addressable” and qualified “whenever deemed appropriate” | In force, and the weakest of the three |
| HIPAA Security Rule NPRM | The same health plans | Would remove the required-versus-addressable distinction and require encryption of ePHI at rest and in transit, with limited exceptions | Proposed only. Published 6 January 2025, not final |
| NAIC Insurance Data Security Model Law (#668) | Licensees in adopting states | A written information security program with safeguards selected against an annual risk assessment | Adopted state by state; the NAIC’s own tracking map carries a status date of 1 April 2026 |
Source: NYDFS text and dates, Second Amendment to 23 NYCRR 500, section 500.15 and the transitional periods in section 500.22(d)(2); HIPAA implementation specifications quoted from 45 CFR 164.312(a)(2)(iv) and (e)(2)(ii); NPRM status and content, 90 FR 898, 6 January 2025; model-law status date, NAIC Model 668 state page.
Two details in that table carry more weight than the rest.
New York deleted its own escape hatch for data in transit. The original Part 500 let a covered entity that found in-transit encryption infeasible use compensating controls approved by its CISO. The Second Amendment struck that provision and kept the equivalent only for data at rest, where a CISO may approve alternative compensating controls and must review that decision at least annually. So for a New York licensed carrier, encrypting nonpublic information in transit is now an unqualified obligation, and the only standard named is “industry standards.” That phrase is what will move when ML-KEM becomes the ordinary way to establish a key, and a carrier that reads its own obligation as static is reading a moving reference as a fixed one.
The health-plan side has the weakest wording attached to the longest-lived data. Under the current Security Rule, encryption in transit is addressable and qualified with “whenever deemed appropriate,” which is a documented judgment call rather than a control. The proposed rule would close that, and it is worth tracking precisely because it is not yet law, since a plan that waits for the final rule inherits the migration and the compliance deadline in the same year.
Where does a carrier’s cryptography actually live?
Mostly in systems it did not write, which is why the answer to this question is usually an inventory exercise rather than an engineering one. Sorting an estate with the three zones tends to produce a distinctive shape at a carrier:
| Surface | Typical zone | Why it lands there |
|---|---|---|
| Policy administration platform | Zone 2 or 3 | Long-lived vendor platform, cryptography selected by the vendor |
| Claims systems and imaging archives | Zone 2 | Vendor-controlled, holding the longest-retention documents |
| Agent and broker portals | Zone 1 or 2 | Public-facing TLS the carrier usually controls |
| Reinsurance and bordereaux exchange | Zone 2 | File transfer and signing under a counterparty’s terms |
| Actuarial modeling and data warehouses | Zone 1 | Internal, and frequently the least inventoried |
| Third-party administrators and clearinghouses | Zone 3 | Records handled on the carrier’s behalf, inside somebody else’s estate |
The last row is the one that surprises people, and New York already anticipated it. Section 500.11(b)(2) of Part 500 requires a covered entity’s third-party service provider policy to address that provider’s use of “encryption as required by section 500.15 of this Part to protect nonpublic information in transit and at rest.” The obligation follows the data into the vendor’s environment as a contractual requirement, which means a carrier’s post-quantum exposure includes its administrators, its imaging vendors, and its clearinghouses, and the instrument for reaching them is the contract rather than an engineering project. Vendor-controlled surfaces covers the general form of that problem, and procurement language covers what to actually write.
What can a carrier do that nobody else in the market can?
Move the baseline. This is the part of a carrier’s position that has no equivalent anywhere else in the transition, and it is currently unused.
The cyber insurance application has already done this once. Multi-factor authentication went from a recommended control to a near-universal precondition for coverage in about 3 years, and it did so through underwriting rather than through any regulation, because carriers put it on the application and priced against the answer. The controls that carriers ask about became the market’s floor by being asked, and an insured that could not answer paid for it in premium or in declination.
Nothing equivalent exists yet for cryptography. A standard cyber application asks whether data is encrypted at rest and in transit. It does not ask which algorithms, whether the answer is inventoried or asserted, whether the applicant could change algorithms without re-architecting, or whether the applicant’s own vendors have committed to dated support. Those are the questions that separate an insured who will survive the transition from one who will discover it during a claim, and they are answerable in a sentence each by an applicant that has done the work.
A carrier that adds a cryptographic-agility question to its application gets three things at once: better risk selection on a peril the market has not priced, a defensible position if quantum-enabled decryption ever becomes a coverage dispute, and the industry-standard-setting role that the same carriers already hold on authentication.
Will quantum risk show up in underwriting or in claims first?
In underwriting, and probably in a silent-exposure review before that. The claims path requires a decryption event that is attributable and provable, which is a high bar and a slow one. The underwriting path requires only that an actuary ask what a policy written today would owe if data harvested during its term were decrypted during the tail, and that is an ordinary reserving question rather than a speculative one.
The precedent worth reading is the war-exclusion work that followed the 2017 NotPetya litigation, which is covered in the cyber insurance note. That sequence ran from an event, to a coverage dispute, to a market-wide wording change, and it took years. A carrier that would rather set the wording than inherit it has time to do so now, while the exposure is theoretical and the language is cheap to write.
Common misconceptions
“Our data is encrypted, so this is handled.” Encryption is the thing that stops working. The question a carrier has to answer is which algorithm, which key sizes, and how long the plaintext stays sensitive after it is captured, which is what discovery produces.
“This is an IT project for 2030.” The retention horizon runs backward, so records written today are already inside the exposure window. A file collected in 2026 on a life policy is captured under whatever cryptography protects it in 2026.
“We’re not in New York, so Part 500 doesn’t apply.” Many carriers are licensed in New York without thinking of themselves as New York companies, and the definition of covered entity reaches anyone required to operate under a license under the Insurance Law. Licensing footprint decides it.
“HIPAA already requires us to encrypt.” It does not. The implementation specifications at 45 CFR 164.312 mark encryption as addressable in both places it appears, and the transit specification is further qualified with “whenever deemed appropriate.” A proposed rule would change that, and it is still a proposed rule.
“Our reinsurers will ask us when it matters.” That is the same argument an insured makes about its carrier, and carriers do not accept it.
Questions people ask
Which records should a carrier inventory first? The ones with the longest tail: life, annuity, long-term care, and disability underwriting files, then claims imaging archives. Retention horizon is the ranking criterion, and it produces a different order than data volume or system criticality would.
Is this different for a property and casualty carrier? Yes, and it is easier. A P&C book’s records generally stop being sensitive far sooner, so the harvest exposure is smaller and the pressure comes from the regulatory side and from the carrier’s role as an underwriter rather than from its own data.
Does a health plan have to wait for the final rule? No, and the NPRM is useful before it is final because it names what the regulator considers reasonable. A plan that encrypts ePHI at rest and in transit now is compliant under the current rule and ready for the proposed one.
What does “industry standards” mean in section 500.15? The regulation does not define it, which is the point. It is a moving reference, and it will move as the standardized algorithms in the new standards become ordinary. A carrier that documents which standard it is meeting, and when it last checked, is in a much better position than one that documented a control in 2024 and stopped.
How does this interact with a carrier’s own cyber insurance? A carrier buying cover is an applicant like anyone else, and the questions it should be asking its insureds are the questions its own broker will eventually ask it.
Who owns this inside a carrier? The CISO owns the control and the chief actuary owns the exposure, and those two roles rarely have a shared document. The inventory is the artifact that makes the conversation possible, because it converts a cryptographic question into a retention-horizon question the actuary already knows how to price.
Is a CBOM useful for an insurer? Yes, and more so than for most sectors, because so much of a carrier’s cryptography sits inside vendor platforms. A CBOM requested from a policy-administration vendor answers a question the carrier cannot answer from inside its own estate.
Should a carrier underwrite quantum risk as a named peril? That is a product decision well beyond the scope of this note. The prior step, knowing which of the carrier’s own records will still matter when today’s cryptography stops working, is the one that has to happen either way.
Everything here is the map, given freely. When a carrier needs its own retention horizons mapped against its cryptographic estate, and its underwriting questions written to match, that’s the work I do.
Last verified 2026-09-06 · Updated 2026-09-06 · Maintained by Addie LaMarr, LaMarr Labs.