Notifications
Clear all
Topic starter
11/06/2026 11:12 pm
TL;DR: NYDFS fined eight insurance companies $14.2 million after breaches exposed data on more than 825,000 people, while upcoming Part 500 changes will require MFA for any individual accessing any information system and a maintained asset inventory, according to Push Security. Policy-based MFA alone is no longer enough; organisations must prove account-level coverage across every login path.
NHIMG editorial — based on content published by Push Security: NYDFS MFA enforcement and the tightening of Part 500 requirements
By the numbers:
- According to Push data, 2 in 5 accounts are missing MFA.
Questions worth separating out
Q: How should security teams prove MFA compliance across all applications?
A: They should verify MFA at the account and login-method level for every in-scope application, not just at the identity provider.
Q: When does MFA policy fail in practice?
A: MFA policy fails when it exists only on paper or at the central login layer while apps still allow password-based access, duplicate logins, or unmanaged tenant settings.
Q: What do teams get wrong about shadow SaaS and authentication?
A: They often assume unknown apps are low risk until they find a business process attached to them.
Practitioner guidance
- Audit authentication at the account level Verify every active account, login method, and alternate path for each in-scope application instead of relying on IdP-wide MFA status.
- Remove ghost logins during app reviews Disable local passwords, legacy auth routes, and duplicate credentials wherever SSO has been introduced.
- Tie asset inventory to MFA evidence Maintain a continuously updated list of information systems and link each asset to its authentication method, owner, and exception status.
What's in the full analysis
Push Security's full article covers the operational detail this post intentionally leaves for the source:
- How the NYDFS enforcement actions map to specific MFA and asset management failings across insurance providers
- The practical differences between central IdP MFA, app-level enforcement, and account-level validation
- Why ghost logins and shadow SaaS create hidden compliance gaps in real enterprise estates
- What Push Security says its browser-based platform observes across unmanaged apps and login methods
👉 Read Push Security’s analysis of NYDFS MFA enforcement and Part 500 changes →
Enterprise-wide MFA validation under NYDFS: are your controls real?
Explore further
12/06/2026 7:46 am
Account-level MFA proof is now the real control boundary. Part 500 is no longer satisfied by saying MFA exists at the IdP or for remote access. The regulator is testing whether every account and login method is actually covered, which means the control boundary has moved from policy declaration to observable authentication state. Practitioners should treat this as a governance shift, not a configuration tweak.
Enterprise MFA now needs continuous evidence, not quarterly assurance. As soon as authentication can happen through unmanaged apps, local passwords, or shadow SaaS, the organisation’s real control boundary moves faster than its audit cycle. Teams that still treat MFA as a policy setting will keep discovering gaps after regulators or attackers do.
A question worth separating out:
Q: Who is accountable when a breach exposes data through missing MFA?
A: Accountability sits with the covered entity, not with the convenience of the login architecture. If an organisation allows accounts to remain accessible without MFA, or fails to inventory the systems that should be protected, regulators can treat that as a governance failure regardless of whether the breach came through an internal, cloud, or third-party path.
👉 Read our full editorial: NYDFS is forcing enterprise-wide MFA validation, not policy theater
