Common warning signs include reliance on SMS, OTP, or push approvals for remote workers, partners, contractors, and privileged accounts. If authentication can be completed with secrets that can be copied, relayed, or socially engineered, the control is not truly phishing resistant. Another signal is when the same login experience is used for high-risk users and ordinary users without stronger assurance steps.
Why Insurers Get Phished Even When the Login Looks “Modern”
Insurers often assume the problem is the credential itself, but the real issue is whether the authentication method can survive social engineering, replay, or approval abuse. A system is too easy to phish when a user can be tricked into handing over something reusable, or into approving a login they did not initiate. In insurance environments, that weakness matters because agents, brokers, adjusters, and claims teams routinely handle sensitive customer data and high-value workflows.
Insurers also tend to have mixed populations: staff, contractors, third parties, and privileged administrators often share the same access patterns unless assurance is explicitly stepped up. That makes it easy for an attacker to start with one phishable account and move toward data exposure, claims manipulation, or deeper administrative compromise. The NHI Management Group notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which illustrates how quickly weak authentication and credential handling become business-impacting.
In practice, many insurers discover the weakness only after an attacker has already used a copied code, intercepted session, or coerced approval to get in.
How to Judge the Authentication Path in Practice
The clearest test is simple: if an attacker can persuade a user to reveal, relay, or approve the factor, the control is not phishing resistant. SMS codes, one-time passwords, and push prompts are all stronger than passwords alone, but they still depend on a secret or decision that can be socially engineered. True resistance comes from factors bound to the device, the origin, and the user gesture in a way that cannot be copied into a phishing page.
For insurers, that means looking beyond the login screen and asking how the control behaves for remote staff, partners, and privileged users. High-risk roles should not rely on the same assurance level as routine portal access. Session protection, device binding, and step-up checks for sensitive actions matter because phishing often succeeds after the first login, not before it. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties authentication strength to access control, while the NHI Management Group guide to non-human identities is a useful reminder that copied secrets and reusable credentials create the same kind of trust failure across machine and human access paths.
- If a login can be completed from a phishing page, treat it as copyable, not phishing resistant.
- If a help desk can reset or bypass the factor too easily, the weakness is procedural as well as technical.
- If privileged users receive the same prompt as ordinary users, the insurer is under-assuring the highest-value accounts.
These controls tend to break down in legacy insurer portals, outsourced contact-centre flows, and any environment where authentication was added on top of older federation or VPN patterns without rethinking the trust boundary.
Common Variations That Mislead Security Teams
Tighter authentication usually adds friction, so insurers must balance user convenience against the reality that phishing tends to target the least resistant path. A push approval with number matching is better than a plain push, but current guidance suggests it still does not equal cryptographic, phishing-resistant authentication. Similarly, OTP over an authenticator app reduces risk compared with SMS, yet it remains vulnerable to real-time relay and user coercion.
One common mistake is treating “MFA enabled” as the end state. Another is assuming that phishing resistance is only needed for employees, when brokers, claims partners, and administrators often present the most attractive attack surface. The real distinction is whether the factor is bound enough to make relay, replay, and approval abuse impractical. If it is not, the insurer still has a phishing problem even if the system technically has more than one factor.
Organisations should also be careful not to judge the login method in isolation. If the session remains valid for too long, or if sensitive transactions do not require re-verification, an attacker who gets past the first screen may still achieve meaningful access. Best practice is evolving toward stronger device-bound authentication and tighter step-up rules, but there is no universal standard for every insurance workflow yet.
In practice, insurers most often misread convenience as resilience, and they only see the gap after a real user has approved an attacker’s prompt or handed over a code.
Risk and Threat Considerations
Phishable authentication creates direct exposure to account takeover, session hijacking, and unauthorised access to claims, policyholder, and financial systems. In insurance, that can translate into data disclosure, fraudulent policy changes, payment diversion, or privileged access abuse.
Failure mechanism: Attackers use social engineering, adversary-in-the-middle phishing, code relay, or push fatigue to turn a legitimate authentication event into an attacker-controlled session. If the insurer relies on copyable secrets or approval-based factors, the control can be bypassed without needing to break the underlying system.
Impact: The result is often trusted access that looks legitimate in logs, delayed detection, and a wider blast radius because the attacker enters through an approved identity rather than a noisy exploit.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Phishable auth indicates weak access enforcement for sensitive insurer accounts. |
| Recommendation — Tighten authentication requirements for privileged and high-risk access paths. | ||
| NIST CSF 2.0 | PR.AC-7 — Users, devices, and systems are authenticated commensurate with risk | The question is about whether authentication strength matches phishing risk. |
| PR.AC-1 — Identities and credentials are issued, managed, verified, revoked, and audited | Phishable methods often fail because credentials and factor handling are weak. | |
| Recommendation — Align authentication assurance with the sensitivity and risk of each access path. Harden credential lifecycle and review how users are issued and verified. | ||
| MITRE ATT&CK | T1566 — Phishing | The subject is whether the login approach can be defeated by phishing. |
| Recommendation — Map observed login abuse to phishing techniques and test the likely attack path. | ||
| NIST SP 800-63 | AAL2 — Authenticator Assurance Level 2 | Insurer logins often rely on factors that stop passwords but not sophisticated phishing. |
| Recommendation — Raise assurance toward phishing-resistant authentication for sensitive users. | ||
Practitioner Guidance
What to prioritise: Start with privileged users, high-risk third parties, and workflows that can alter policy, payments, or customer records. Those are the places where phishable authentication becomes material fastest.
What to verify: Confirm whether the factor can be relayed, replayed, or approved remotely, and test the help-desk recovery path as well. If recovery is weaker than login, the insurer has only moved the weak point.
Decision rule: If a phish can capture it or a call can coerce it, treat the method as insufficient for sensitive access. If the control survives phishing only for low-risk portals, do not extend that assurance to administrative or partner access.
Practitioner takeaway: The key question is not whether the insurer uses MFA, but whether the chosen factor actually breaks the attacker’s ability to reuse, relay, or socially engineer the login.
Related resources from NHI Mgmt Group
- What are the signs that an authentication model is failing in a financial services environment?
- What are the signs that API authentication is failing to keep pace with attacker behaviour?
- Why is it crucial to adopt new authentication methods in MCP usage?
- What are the signs that an authentication setup is too fragile for enterprise use?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
