Use contextual MFA instead of a single blanket rule. Require phishing-resistant methods for routine access, add step-up verification for risky devices or sensitive actions, and keep recovery flows auditable. That approach preserves user experience while still meeting the regulation’s expectation that authentication be consistent, documented, and defensible.
Why contextual MFA is the right fit for NYDFS
For insurers, the core problem is not whether MFA exists, but whether it is applied in a way that matches the risk of the action. NYDFS expects authentication controls that are documented, repeatable, and defensible, so a single blanket prompt can be weaker than a policy that considers user context, device trust, and transaction sensitivity. The goal is to reduce unnecessary prompts without weakening assurance.
Contextual MFA works because it separates ordinary sign-in from higher-risk activity. Routine access can use a phishing-resistant factor, while sensitive changes, unusual geolocation, new devices, or privilege changes can trigger step-up verification. That is better aligned to insurer workflows than forcing the same challenge on every session, which often drives workarounds and support load.
One practical advantage is that contextual MFA gives security teams a clearer policy narrative. Instead of trying to justify friction everywhere, they can explain why certain actions require stronger proof, especially when an account is reaching policy data, claims systems, or administrator functions. That makes the control easier to audit and easier for users to accept.
How to keep MFA strong without making users fight it
Design the authentication journey around the normal path first, then add exceptions for elevated risk. Workforce Identity Security Guide is useful here because it ties phishing-resistant MFA, passkeys, and step-up authentication to real rollout choices, not just policy language. If the default path is simple and reliable, users are less likely to resist the stronger checks that matter most.
Recovery and enrollment deserve the same attention as primary login. A control that is secure in steady-state but weak during password reset or device recovery creates a bypass path that is still visible to auditors, and often more attractive to attackers. Make those flows measurable, reviewed, and logged so the organization can defend how identities are restored after an exception.
At insurer scale, friction usually comes from too many prompts, inconsistent device recognition, and vague escalation rules. Current guidance suggests that the best user experience comes from predictable policy logic: authenticate once, step up only when risk changes, and avoid silent exemptions that cannot be explained later. Users tolerate stronger controls when the reason is clear and the pattern is consistent.
Where insurers usually get MFA wrong
The most common mistake is treating MFA as a checkbox rather than a layered control. That shows up as SMS-only authentication, overbroad trusted-device settings, or one-off exceptions that are never revisited. Another recurring failure is not distinguishing login assurance from session assurance, which can leave a stolen session token or weak recovery flow outside the intended control boundary.
For insurers, the other weak point is privileged and third-party access. Admin users, claims processors, and vendor support paths should not inherit the same tolerance for low-assurance factors that a low-risk employee portal might use. A control can still be user-friendly, but it has to be stricter where the blast radius is larger and the audit expectation is higher.
Risk and Threat Considerations
Friction reduction becomes a security problem when it pushes teams toward weaker factors, broader exemptions, or unlogged recovery shortcuts. For a regulated insurer, those shortcuts can undermine both the control itself and the ability to prove that access decisions were consistent and defensible.
Failure mechanism: Attackers and abusive insiders often target the easiest path in, such as fatigue-based approvals, weak recovery, or a reused session after MFA has already been satisfied. If the policy is too blunt, teams may also create exceptions that are hard to detect and even harder to audit.
Impact: The result can be account takeover, unauthorized claims or policy access, privileged misuse, and a weaker compliance position under NYDFS because the authentication program no longer demonstrates reliable control over risk-based access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authenticator assurance and phishing-resistant authentication for risk-based MFA design. |
| Recommendation — Adopt phishing-resistant authenticators and step-up checks where assurance must increase. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Applies to employee and administrator authentication controls in insurer access paths. |
| IA-5 — Authenticator Management | Supports lifecycle control over MFA factors, enrollment, recovery, and revocation. | |
| IA-2(1) — Network Access to Privileged Accounts | Relevant to step-up and stronger authentication for higher-risk privileged access. | |
| Recommendation — Enforce strong organizational-user authentication for routine and privileged access. Manage authenticators through controlled enrollment, rotation, and revocation. Require stronger authentication for privileged network access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly supports policy-based access decisions and MFA governance. |
| Recommendation — Define and apply access control rules that match user and action risk. | ||
Practitioner Guidance
What to prioritise: Put phishing-resistant MFA on the standard path first, then reserve step-up authentication for risky devices, sensitive transactions, and admin actions. That gives you most of the security benefit without forcing every low-risk login through the highest-friction path.
What to verify: Check that recovery, enrollment, and exception handling are as well logged and reviewed as the login flow itself. If a user can regain access or elevate trust more easily than they can authenticate normally, the control is not really consistent.
Common mistake: Do not define “low friction” as “fewest prompts.” The better test is whether the policy produces predictable decisions that users can follow and auditors can explain, while still making abuse paths materially harder.
Practitioner takeaway: The best NYDFS MFA design for insurers is not the most aggressive one, it is the one that concentrates friction where risk changes and keeps every exception provable.
Related resources from NHI Mgmt Group
- How should organisations implement PSD2 controls without adding too much checkout friction?
- How should security teams implement zero trust authentication without adding too much user friction?
- How should small businesses implement MFA without creating too much user friction?
- How should fintech teams build compliance into growth without adding too much friction?