Insurance Sector Identity Security Guide: Brokers, Claims Systems and Regulator Expectations

Insurers hand access to their most sensitive systems to people they do not employ: independent agents, brokers, third-party administrators, claims adjusters and repair networks. Policy administration and claims platforms hold health, financial and identity data on millions of policyholders, and the identity perimeter around them runs through thousands of small intermediary firms. Regulators have responded with specific identity requirements: NYDFS Part 500 has required MFA for any individual accessing a covered entity's information systems since 1 November 2025, the NAIC Insurance Data Security Model Law sets a programme baseline across US states, and DORA brings prescriptive access control rules to EU insurers. This guide covers the identity populations peculiar to insurance, how to secure broker and TPA access, claims and policy admin systems, regulator expectations and how to produce evidence for both regulators and cyber underwriters. It is for insurer IAM, security and compliance teams, MGAs and the TPAs and brokers that connect to them.

Key takeaways

• Intermediaries are the largest identity population. Agents, brokers, MGAs and TPAs often outnumber employees, sit outside your HR feed and use your portals from devices you do not manage.
• NYDFS made MFA universal. From 1 November 2025, section 500.12 requires MFA for any individual accessing any information system of a covered entity, with written CISO approval needed for any compensating control.
• The NAIC model is a programme, not a checklist. It requires authenticated, limited access and oversight of third-party service providers, but lists MFA as a control the programme "may include", so state requirements vary.
• DORA is prescriptive about accounts. RTS 2024/1774 requires one unique account per staff member, including ICT third-party staff, reviews at least every six months for systems supporting critical or important functions, and strong authentication for remote and privileged access.
• One evidence pack serves several audiences. The access reviews, MFA coverage reports and third-party access logs a regulator examines are the same evidence a cyber underwriter or reinsurer will ask for.

Identity populations in an insurer

The cross-sector controls for workforce and privileged access in financial services are covered in the Financial Services Identity Security Guide; this guide concentrates on what is specific to insurance.

Securing agent and broker access

Agent and broker portals are where insurance identity programmes most often fall short. Many agencies are small firms with a handful of staff, no IT function and a habit of sharing one portal login. The carrier usually cannot see when an agency employee leaves.

• One person, one account: require a named account for each agency employee. DORA's RTS 2024/1774 Article 20 asks for a unique account for each staff member, including staff of ICT third-party service providers, and its recital 14 allows generic or shared accounts only exceptionally, with accountability maintained. The same principle is the only way to answer "who did this" in any jurisdiction.
• Delegated administration: give each agency a principal or administrator who creates and removes accounts for their own staff, and make that person attest to the list on a schedule. Delegation scales; carrier help desks cannot track agency turnover.
• Licence and appointment as attributes: tie portal entitlements to the agent's licence status and carrier appointment. When an appointment is terminated, access should end through the same workflow.
• MFA everywhere: NYDFS section 500.12 covers "any individual" accessing a covered entity's information systems, which includes agents and brokers using carrier portals. Offer authenticator apps or passkeys rather than SMS where possible. See the MFA Guide.
• Inactivity disablement: suspend portal accounts unused for a defined period, a common source of orphaned access when agencies merge or close.
• Federation for large brokers: large brokers may prefer to federate their own identity provider. This removes password sprawl but makes you depend on the broker's leaver process, so require leaver timeliness and MFA in contract and keep a right to audit.
• Bulk data controls: brokers and MGAs exchange bordereaux and policy data in bulk. Restrict export functions to named roles and monitor large or unusual downloads.

Third-party administrators and claims ecosystems

TPAs run claims, policy servicing or benefits administration on the insurer's behalf, often with direct access to claims and payment systems. Repairers, loss adjusters and medical reviewers add a long tail of small partners. The Scania insurance portal breach shows the pattern: an IT partner's login, stolen by infostealer malware, exposed insurance claim documents.

• Contract for identity controls: NYDFS section 500.11(b) requires third-party service provider policies to address access controls including MFA as required by section 500.12, encryption, notice of cybersecurity events directly affecting the covered entity, and representations and warranties. The NAIC model (Section 4F) requires due diligence in selecting providers and requires them to implement appropriate administrative, technical and physical measures.
• Scope access per contract and line of business: a TPA handling motor claims for one region should not see all claims. Use attribute-based rules on line of business, territory and claim assignment.
• Separate payment authority: the ability to approve and release claim payments should need a second identity, and TPA staff should not be able to change payee bank details and approve payment in the same session.
• Privileged TPA access through your controls: TPA administrators who manage users or configuration in your systems should work through your PAM broker with session recording. See the Privileged Access Management Guide.
• Short-lived access for the long tail: give repairers and adjusters access scoped to the claims assigned to them, expiring when the claim closes, instead of standing portal accounts.
• Know your machine connections: TPA and partner integrations often use API keys or service accounts. Give each partner its own credential with an owner, and include them in third-party offboarding.

See the Third-Party Access Guide and the Third-Party Risk Management Guide for the wider programme.

Claims and policy administration systems

Core insurance platforms are frequently decades old, run on mainframes or heavily customised packages, and carry entitlement models that pre-date central identity. Common problems and fixes:

NYDFS section 500.7 requires covered entities to limit user and privileged access to what each job requires, use privileged accounts only when needed, review access at least annually, and promptly terminate access following departures. Class A companies must also monitor privileged access activity, implement a privileged access management solution and automatically block commonly used passwords. See the Service Account Security Guide for batch and integration accounts.

Regulator expectations

NYDFS 23 NYCRR Part 500

Insurers licensed in New York are covered entities. The second amendment took effect on 1 November 2023, and section 500.22(d)(4) gave two years to comply with the expanded MFA requirement in section 500.12 and the asset inventory requirement in section 500.13(a), which is why 1 November 2025 is the key date. Section 500.12 now requires MFA for any individual accessing any information system. Entities that qualify for the limited exemption in section 500.19(a) must still use MFA for remote access to their systems, remote access to third-party applications (including cloud applications) from which nonpublic information is accessible, and all privileged accounts other than service accounts that prohibit interactive login. A CISO may approve reasonably equivalent or more secure compensating controls in writing, reviewed at least annually. See the NYDFS Part 500 Guide.

NAIC Insurance Data Security Model Law (#668)

Adopted by many US states, sometimes in modified form, so check the version enacted in each state of domicile. The model requires a written information security programme based on a risk assessment. Section 4D(2) lists controls including authenticated access limited to authorised individuals and states that the programme may include MFA procedures for any individual accessing nonpublic information. Section 4E requires board oversight with at least annual written reporting, Section 4F third-party service provider oversight, and Section 4I an annual certification of compliance to the commissioner by 15 February, with supporting records kept for five years. Section 6 requires notification to the commissioner no later than 72 hours after determining that a cybersecurity event has occurred, and Section 9 exempts licensees with fewer than ten employees, including independent contractors, from Section 4.

DORA for EU insurers

Insurance and reinsurance undertakings are in scope of Regulation (EU) 2022/2554, which has applied since 17 January 2025; recital 39 explains that insurance, reinsurance and ancillary insurance intermediaries that are micro, small or medium-sized enterprises are not. The identity rules sit in Delegated Regulation (EU) 2024/1774. Article 20 requires unique identification and authentication of natural persons and systems, one unique account per staff member including ICT third-party staff, lifecycle management and retained records. Article 21 requires generic and shared accounts to be minimised, privileged, emergency and administrator access to be assigned on a need-to-use or ad-hoc basis, withdrawal without undue delay on termination, review at least yearly and at least every six months for systems supporting critical or important functions, and strong authentication for remote access, privileged access, critical or important assets and publicly accessible assets. See the DORA Guide.

Insurers operating across several jurisdictions can use the Identity Security Regulatory Map to see where these overlap with other regimes.

Insurer-ready evidence: regulators and cyber underwriting

Insurers sit on both sides of cyber risk: they are regulated entities, and many write cyber cover whose underwriting questions focus on MFA, privileged accounts and backups. The Cyber Insurance Guide covers what underwriters ask buyers. For an insurer's own programme, build one evidence pack that answers the regulator, internal audit, reinsurers and any cyber cover the insurer buys itself:

• MFA coverage report: every human account by population (employee, agent, broker, TPA, vendor), with MFA method, and a register of CISO-approved exceptions with review dates.
• Privileged account inventory: number of persistent admin accounts, how many are vaulted, and service accounts with interactive login disabled.
• Access review records: completion rates and revocations, with six-monthly reviews for critical or important functions where DORA applies.
• Third-party access register: every intermediary and TPA with system access, its account counts, MFA status and last attestation.
• Leaver timeliness: time from HR or agency termination to account disablement.
• Annual certification trail: the material that supports the NYDFS and state NAIC-model certifications.

When an insurer's own underwriters assess cyber applicants, the same structure helps: asking applicants for MFA coverage by population and a privileged account count, rather than a yes or no, produces answers that can be verified at claim time.

Implementation approach

1. Baseline: inventory identity populations, the systems each reaches and how each authenticates. Map which regulations apply by legal entity and state of domicile.
2. Close MFA gaps for privileged and remote access first: these are required under every regime. Then extend to agent and broker portals and internal systems to meet section 500.12 in full. Pilot with a group of agencies, provide enrolment support and keep a documented exception path approved by the CISO.
3. Clean up shared agency accounts: introduce delegated administration, give agencies a deadline to move to named accounts and disable shared logins in waves, with a rollback window if an agency cannot transact.
4. Bring TPAs and partners under contract and control: update contracts to section 500.11 and NAIC Section 4F expectations, route privileged TPA access through PAM and issue per-partner API credentials.
5. Harden core platforms: front legacy policy and claims systems with SSO or PAM, enforce segregation of duties on payments and restrict bulk export.
6. Automate reviews and evidence: run IGA certifications on the regulatory cadence and generate the evidence pack each quarter.

Decision guidance

• Federation versus carrier-issued accounts for brokers: federate large brokers with mature identity programmes and contract for MFA and leaver timeliness; issue carrier accounts with delegated administration to small agencies.
• Compensating controls versus full MFA: under section 500.12 a CISO can approve equivalent controls in writing, reviewed annually. Use this for specific legacy systems with a retirement date, not as a population-wide exemption.
• Small insurers and MGAs: check whether you qualify for the section 500.19(a) limited exemption or the NAIC Section 9 small-licensee exemption, but note that the NYDFS exemption still requires MFA for remote and privileged access.
• Multi-jurisdiction groups: design to the strictest common baseline (MFA for all individuals, six-monthly reviews for critical functions) rather than maintaining separate rules per entity.

Detection and measurement

Log portal sign-ins for agents, brokers and TPAs with the agency or firm identifier, MFA events, privileged sessions, bulk exports, payee changes and payment approvals. Watch for one agency account signing in from many locations, logins from infostealer-exposed credentials, and claims payments where the same user changed the payee and approved the payment.

Common failure patterns

• Shared agency logins: one password for an entire agency, never changed when staff leave, with no way to attribute policy changes.
• Partner credentials without MFA: small adjusters, IT partners and repairers sign in with passwords alone, so infostealer logs become access, as in the Scania insurance portal breach.
• Remote access without MFA to a claims clearing partner: the Change Healthcare breach began with a remote access login without MFA and disrupted claims processing across the US healthcare system.
• Help desk resets for intermediaries: agents locked out of a portal are reset by phone with weak identity checks. See the Account Recovery and Help Desk Security Guide.
• TPA access outliving the contract: accounts and API keys remain after a TPA relationship ends because offboarding covers only the contract, not the identities.
• Compensating controls that never expire: CISO approvals granted during an MFA rollout become permanent and are not reviewed annually.

Framework mapping

Practitioner checklist

• Inventory every identity population, including agency staff, broker users, TPA staff and partner integrations.
• Map NYDFS, state NAIC-model laws and DORA obligations to each legal entity.
• Enforce MFA for every individual, starting with privileged and remote access, and keep a dated register of CISO-approved exceptions.
• Replace shared agency logins with named accounts and delegated agency administration.
• Tie agent access to licence and appointment status so terminations remove access.
• Contract for MFA, event notice and leaver timeliness with TPAs and brokers, and route their privileged access through PAM.
• Enforce segregation of duties between payee changes and payment approval in claims systems.
• Run access reviews yearly, and every six months for critical or important functions where DORA applies.
• Produce a quarterly evidence pack usable for regulators, auditors and underwriters.

Standards and references

• Cornell LII: 23 NYCRR 500.12, Multi-factor authentication
• Cornell LII: 23 NYCRR 500.7, Access privileges and management
• Cornell LII: 23 NYCRR 500.11, Third party service provider security policy
• Cornell LII: 23 NYCRR 500.22, Transitional periods
• NAIC: Insurance Data Security Model Law (#668)
• EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 on ICT risk management
• EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Financial Services Identity Security Guide · NYDFS Part 500 Guide · DORA Guide · Cyber Insurance Guide · PAM Maturity Model. This guide summarises NYDFS Part 500, the NAIC Insurance Data Security Model Law and DORA identity requirements and is not legal advice.