industries · insurance

Agents, adjusters and policyholders each get the access they need and no more.

Insurers manage more outside identities than most industries. Independent agents, MGAs, TPAs, adjusters and policyholders each come in through a different portal. We build the identity layer for those audiences and govern the data behind underwriting and claims. We also keep the records state regulators ask for.

industry / insurance 4 rules in scope
01 · USERS 02 · IDENTITY 03 · INSURANCE SYSTEMS 04 · DATA AND MODELS Agents and brokers: independent agencies · MGAs Agents andbrokers independentagencies · MGAs Policyholders: web · mobile Policyholders web · mobile TPAs and adjusters: claims vendors TPAs andadjusters claims vendors Employees: underwriting · claims · service Employees underwriting ·claims ·service Customer and partner identity: Auth0 · delegated admin Customer and partneridentity Auth0 · delegatedadmin Workforce identity: Entra ID · Okta · MFA Workforce identity Entra ID · Okta · MFA Agent and service CRM: Salesforce · Dynamics 365 Agent and serviceCRM Salesforce · Dynamics365 Policy admin and billing: quote · bind · endorse Policy admin andbilling quote · bind · endorse Claims system: FNOL · reserves · payments Claims system FNOL · reserves ·payments Governed data platform: lineage · access policies Governed dataplatform lineage · accesspolicies Pricing and claims models: AI program documentation Pricing and claimsmodels AI programdocumentation
Auth0OktaSailPointSalesforce
in short·20-second read

Insurers juggle access for employees, independent agents, third-party administrators and policyholders, and they answer to state insurance data security laws and NYDFS Part 500 while doing it.

Cohash builds customer and partner identity for the agent and policyholder portals. We put governance on policy and claims systems. And we set up governed data platforms for underwriting and AI models, with the lineage and documentation the NAIC AI bulletin expects.

you probably need this if
  • Agents who left an agency months ago can still log in to quote.
  • Independent adjusters share one claims system account per firm.
  • Policyholder account recovery is a security question set up a decade ago.
Ask an engineer facts checked 2026-10-20 · 6 sources
how it runs
  1. 01Map each rule to its systems
  2. 02Measure who can reach regulated data
  3. 03Fix and automate the controls
  4. 04Produce evidence auditors can sample
rules
State insurance data security lawsNYDFS Cybersecurity RegulationNAIC Model Bulletin on the Use of AI Systems by InsurersNYDFS Insurance Circular Letter No. 7
from rule to evidence

How a regulation turns into proof.

For insurance, each rule below lands as a control, the control runs on a platform, and the platform leaves a record an auditor can read.

  1. 01

    Rules you answer to

  2. 02

    Controls we build

    Agent and broker identityPolicyholder sign-inGovernance for policy and claims systemsGoverned data for underwriting and AIAgent and service CRM
  3. 03

    Platforms that enforce them

  4. 04

    Evidence your auditors read

    Access review records Joiner, mover and leaver logs Privileged session records Change and approval history Control-to-rule mapping
the story · insurance access program

From the first call to a setup your own team can run.

Here's what usually prompts a call about your insurance access program, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • Agents who left an agency months ago can still log in to quote.
    • Independent adjusters share one claims system account per firm.
    • Policyholder account recovery is a security question set up a decade ago.
  2. chapter 02 · what we change

    How we solve it

    • Agent and broker identity
    • Policyholder sign-in
    • Governance for policy and claims systems
    • Governed data for underwriting and AI
    • Agent and service CRM
  3. chapter 03 · how it runs

    Our approach

    • Map each rule to the systems it touches
    • Measure who can reach regulated data today
    • Fix access and automate the controls
    • Produce evidence auditors can sample
  4. chapter 04 · where you end up

    What changes

    • End the appointment in the licensing system and the portal login dies with it.
    • Next time a regulator asks what fed the rating model, the pricing team pulls up the lineage instead of searching notebooks and email.
challenges and answers

Where it usually goes wrong, and what we do about it

where it goes wrong
  1. 01

    Independent agents who change agencies

    Agents move from agency to agency and hold appointments with lots of carriers. In small offices they share a login. None of that changes what the carrier needs to know, which is the person who quoted the policy, and when to cut access because the appointment ended.

  2. 02

    TPA and claims vendor access

    Third-party administrators, independent adjusters and repair networks need claims system access. Model 668 makes their security your problem, yet their accounts rarely follow your HR-driven processes.

  3. 03

    Policyholder account takeover

    Policyholder portals hold payment details and claim payouts, so they attract fraud. Reused passwords and weak recovery flows let it in. Bolt on friction and the service center phones start ringing.

  4. 04

    Underwriting data without lineage

    Pricing and claims models pull from policy, claims and third-party data. A regulator asks which data fed one decision. Right now the answer lives in the head of whoever built the model.

  5. 05

    Policy systems from several eras

    Mainframe policy admin, a newer platform for one line and acquired books on something else. Each has its own roles, so access reviews run per system and rarely line up.

how we help
  1. 01

    Agent and broker identity

    Customer and partner identity on Auth0 or Okta. Each agency gets delegated admin, and the bigger ones federate their own identity. Access hangs off appointment status. When the appointment ends, so does the login.

  2. 02

    Policyholder sign-in

    Passkeys, risk-based MFA and safer account recovery for policyholder portals and apps. We design it with the service center, so a sign-in change doesn't turn into a spike in calls.

  3. 03

    Governance for policy and claims systems

    Role design, certifications and separation of duties across policy admin, billing and claims. TPA and vendor accounts get reviewed in the same campaign as staff.

  4. 04

    Governed data for underwriting and AI

    Lineage, access policies and documentation on Databricks or Snowflake for the data your pricing and claims models use. When the NAIC bulletin asks for an AI program, these are the records it runs on.

  5. 05

    Agent and service CRM

    Salesforce or Dynamics 365 for agent management, policy servicing and claims intake. Hook it to the identity layer and each agent sees their own book and nobody else's.

typical situations

Situations we walk into

We pieced these together from insurance situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

Agents who changed agencies and kept their quoting logins

composite · not a client story
  1. Beforethe situation

    A regional property and casualty carrier gives independent agents accounts in its agent portal. Appointment terminations reach the licensing system weeks before anyone touches the portal, and several small agencies share one login per office.

  2. What we dothe work

    We move agents into a customer and partner identity platform with agency-level delegated administration, and tie each account to appointment status from the licensing system. Agency principals manage their own staff. At renewal, shared logins get replaced with named accounts.

  3. Afterwhere you end up

    End the appointment in the licensing system and the portal login dies with it. Every quote now has a named agent on it. When an agency hires someone, the principal sets them up without calling the carrier.

case file 02

A regulator asks which data fed a rating model

composite · not a client story
  1. Beforethe situation

    A regulator asked which external data sources fed a personal auto rating model. The pricing team had to rebuild the answer from notebooks and email. NYDFS Circular Letter No. 7 applies to the carrier's New York business.

  2. What we dothe work

    We put every pricing data source and feature in the data platform catalog, with lineage running from source to model. Third-party data vendors get recorded, along with how each was vetted. Access policies keep production features in the model team's hands only.

  3. Afterwhere you end up

    Next time a regulator asks what fed the rating model, the pricing team pulls up the lineage instead of searching notebooks and email. The same records serve the AI program under the NAIC bulletin.

architecture

How agents, policyholders and staff reach insurance systems and data

Agents, policyholders and TPAs come in through customer and partner identity. Employees use the workforce identity provider. Policy and claims systems feed a governed data platform, and that's where pricing and claims models get documented data.

How agents, policyholders and staff reach insurance systems and data Agents, policyholders and TPAs come in through customer and partner identity. Employees use the workforce identity provider. Policy and claims systems feed a governed data platform, and that's where pricing and claims models get documented data. 01 · USERS 02 · IDENTITY 03 · INSURANCE SYSTEMS 04 · DATA AND MODELS OIDC sign-in passkey or MFA federation SSO agency roles quote and service role access CDC claims history governed features Agents and brokers independent agencies ·MGAs Policyholders web · mobile TPAs and adjusters claims vendors Employees underwriting · claims ·service Customer andpartner identity Auth0 · delegatedadmin Ex Workforce identity Entra ID · Okta ·MFA Sf Agent and serviceCRM Salesforce ·Dynamics 365 Policy admin andbilling quote · bind · endorse Claims system FNOL · reserves · payments Governed dataplatform lineage · accesspolicies Pricing and claimsmodels AI program documentation
Read the diagram as text
  1. Agents and brokers → Customer and partner identity: OIDC sign-in
  2. Policyholders → Customer and partner identity: passkey or MFA
  3. TPAs and adjusters → Customer and partner identity: federation
  4. Employees → Workforce identity: SSO
  5. Customer and partner identity → Agent and service CRM: agency roles
  6. Customer and partner identity → Policy admin and billing: quote and service
  7. Workforce identity → Claims system: role access
  8. Policy admin and billing → Governed data platform: CDC
  9. Claims system → Governed data platform: claims history
  10. Governed data platform → Pricing and claims models: governed features
case studies

Work on the platforms insurance runs on

All case studies
upgrade Identity and access

Auth0 Rules and Hooks to Actions before end of life

Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.

read the case study
implementation Industry platforms

TriZetto Facets upgrades and CMS-0057-F interoperability APIs

Keeping TriZetto Facets current while we build the Provider Access, Payer-to-Payer and Prior Authorization APIs that CMS-0057-F requires by January 2027.

read the case study
implementation Identity and access

Homegrown customer login to Auth0 or Okta Customer Identity

We swap homegrown customer login and its user table for Auth0, move users without forcing password resets, and keep the CRM records in sync.

read the case study
migration Identity and access

On-premises Active Directory to cloud-first Microsoft Entra ID

We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.

read the case study
implementation Industry platforms

Epic integrations, FHIR APIs and TEFCA connectivity

Building and governing the HL7 and FHIR integrations, SMART on FHIR apps and TEFCA exchange around Epic, with an interface catalog and scope reviews.

read the case study
migration Identity and access

ForgeRock AM/IDM to PingOne Advanced Identity Cloud

Moving self-managed ForgeRock AM and IDM, now called PingAM and PingIDM, to PingOne Advanced Identity Cloud without breaking sign-in or provisioning.

read the case study
talent and delivery · insurance

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
01Does Model 668 apply if our home state hasn't adopted it?

It only binds you in states that have enacted it. The duties follow your licenses, though, so your domicile isn't the whole story. Some non-adopting states have their own rules, New York's Part 500 for one. We map controls to every state you're licensed in and build one program to the strictest.

02Can independent agents sign in with their agency's own login?

Often they can. A big agency with its own identity provider federates through SAML or OIDC. Small agencies usually get accounts in your customer identity platform. Then a principal at each agency manages its own people, and your service desk stays out of it.

03What does the NAIC AI bulletin mean for our data team?

Adopting states expect a written AI program. Your data team has to be able to say which data feeds each model, who's allowed to change it, and how third-party data and models were vetted. Lineage, access controls and documentation on the data platform give you most of that.

04Do you also implement the CRM for agents and service teams?

Yes. We implement Salesforce and Dynamics 365 for agent management, servicing and claims intake. They hang off the same identity layer, so an agent loses access when the appointment goes.

05Can you help us answer a regulator's data request about a model?

Our part is the data platform. We help pull together sources, lineage, access history and documentation. Writing the response, and any legal interpretation, stays with your compliance team and counsel.

sources 6 sources linked last checked 2026-10-20 content fingerprint 9ec5afbb
  1. 01NAIC: Implementation of Model #668 adoption map (status as of 8 Oct 2026)content.naic.org ↗
  2. 02NAIC: Insurance Data Security Model Law (Model 668) textcontent.naic.org ↗
  3. 03NAIC: Implementation of the AI Model Bulletin (status as of 8 Oct 2026)content.naic.org ↗
  4. 04Cornell LII: 23 NYCRR 500.7 Access privileges and managementlaw.cornell.edu ↗
  5. 05NYDFS: Multi-factor authentication requirements under Part 500dfs.ny.gov ↗
  6. 06NYDFS: Insurance Circular Letter No. 7 (2024)dfs.ny.gov ↗
Reviewed by the Cohash team Product names are trademarks of their owners. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it