NYDFS is forcing enterprise-wide MFA validation, not policy theater

At a glance

What this is: This is an analysis of NYDFS tightening Part 500 MFA and asset inventory expectations, with the key finding that compliance now depends on validating MFA at the account level across every access path.

Why it matters: It matters because IAM, NHI, and human identity programmes all fail if they only govern central SSO while unmanaged accounts, ghost logins, and third-party access remain outside validation.

By the numbers:

• The latest regulatory enforcement from NYDFS resulted in a total of $14.2m in fines across 8 insurance providers following data breaches that exposed the private information of more than 825,000 people.
• According to Push data, 2 in 5 accounts are missing MFA.

👉 Read Push Security’s analysis of NYDFS MFA enforcement and Part 500 changes

Context

NYDFS Part 500 is shifting from control existence to control proof. The core problem is not whether MFA has been configured somewhere in the environment, but whether every account, login path, and application access route is actually covered and auditable.

For IAM teams, that changes the unit of governance from policy statements to account-level evidence. Shadow SaaS, local credentials, and unmanaged application logins create gaps that traditional IdP-centric audits often miss, which is why regulators are treating missing MFA as a compliance failure rather than a technical oversight.

Key questions

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. That means mapping local passwords, SSO, fallback paths, and privileged accounts, then tying each one to an asset inventory and evidence trail. If a login route can still bypass MFA, the organisation does not have provable coverage.

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. In practice, the failure shows up as accounts that look protected in audit reports but remain reachable through a weaker path that attackers can use.

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. Shadow SaaS is dangerous because it can create unreviewed login methods, hidden account stores, and untracked data access. Once those apps are in use, they belong in the MFA and inventory programme even if IT never formally approved them.

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.

Technical breakdown

Why central IdP MFA does not equal account-level coverage

Many organisations assume that enforcing MFA at the identity provider means MFA is enforced everywhere. That assumption breaks when applications retain local passwords, alternate login methods, or tenant-specific account settings that bypass the IdP. In SaaS-heavy environments, the authentication path is often distributed across dozens of apps, each with different enforcement capabilities. Account-level validation is therefore required to distinguish policy intent from actual login behaviour.

Practical implication: audit login methods per account, not just IdP settings.

How ghost logins create hidden MFA gaps

A ghost login is a secondary or legacy authentication path that still works even after SSO has been added. Users may keep local credentials, app-specific passwords, or bypass routes that were never disabled. These paths are invisible if teams only measure federation status, which means a single account can appear compliant while still being reachable without MFA. The technical failure is incomplete deprovisioning of old login methods, not just weak password hygiene.

Practical implication: remove unused local authentication paths during every app review.

Why asset inventory is now part of MFA enforcement

MFA control scope depends on knowing which systems exist and who can reach them. A maintained asset inventory is not just discovery work; it is the evidence base for deciding where MFA must be enforced and where exceptions exist. Without it, unmanaged SaaS tools, third-party services, and internal utilities can remain outside security review while still processing regulated data. In practice, asset visibility and authentication enforcement have become one control problem.

Practical implication: tie MFA validation to a continuously maintained app inventory.

Threat narrative

Attacker objective: The attacker aims to use the least-governed login path to reach regulated data or business systems while bypassing the MFA controls the organisation assumes are in place.

1. Entry occurs through exposed or unmanaged login paths, especially in shadow SaaS or applications with local passwords left active alongside SSO.
2. Escalation happens when accounts that appear federated still retain password-based or non-MFA access, allowing attackers to authenticate through the weakest path.
3. Impact follows when those accounts give access to non-public data, internal tools, or third-party systems that regulators now treat as in-scope enterprise access.

Breaches seen in the wild

• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Ghost logins are a lifecycle failure, not an authentication footnote. When SSO is layered on top of legacy passwords instead of replacing them, organisations create duplicate identity paths that survive normal assurance checks. That is a lifecycle and offboarding problem as much as it is an IAM problem. The implication is that access reviews must examine login method persistence, not just account ownership.

Shadow SaaS turns MFA into an inventory problem. If the application is not known, it cannot be governed, and if the login path is not mapped, it cannot be validated. This is the point at which NHI-like governance discipline matters for human access too: every unmanaged app behaves like an unmonitored identity surface. Practitioners should align discovery, authentication validation, and audit evidence into one programme.

NYDFS is signalling that regulators will punish control claims, not control intent. The presence of a policy is no longer persuasive if account-level evidence shows weak or bypassable authentication. That changes how security and compliance teams should document readiness across human users, third-party access, and service-facing systems. The practical conclusion is that evidence quality now determines whether the control exists in the regulator’s eyes.

Enterprise MFA coverage is becoming an identity governance metric, not just a security setting. The article shows that authentication now intersects with asset management, SaaS governance, and exception handling in ways that traditional IAM reporting often misses. Teams should read this as a mandate to measure real coverage, not declared coverage, across the full access estate.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: Read NHI Lifecycle Management Guide for the governance pattern that connects provisioning, rotation, and offboarding across machine and autonomous identities.

What this signals

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.

The stronger signal is that identity governance and asset management are converging. Once you can no longer prove which applications exist, you cannot prove where MFA applies, and that makes discovery part of the access control problem. For programmes that already struggle with service accounts and other non-human identities, the same visibility discipline is now being demanded for human login paths too.

Ghost login drift: when a secondary authentication method survives after SSO adoption, the environment contains a hidden route that compliance reporting may miss. That drift should be monitored alongside access reviews and tied back to the app inventory, not left as an application-team exception. Organisations that already use the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs will recognise the same lifecycle logic applies here.

For practitioners

• 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. Prioritise apps that handle non-public information, third-party access, and privileged users.
• Remove ghost logins during app reviews Disable local passwords, legacy auth routes, and duplicate credentials wherever SSO has been introduced. If an app still permits fallback authentication, treat that as a governance gap until the path is removed or formally controlled.
• 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. This makes it possible to prove coverage during audit and identify blind spots before enforcement does.
• Re-test third-party access paths Review supplier and cloud application access with the same rigor as internal systems, because regulators are treating external services that hold non-public information as part of the enterprise network. Revalidate MFA after each change in login method or tenant configuration.

Key takeaways

• NYDFS is treating incomplete MFA coverage as a governance failure, not a documentation problem.
• Shadow SaaS, legacy passwords, and duplicate login paths are the practical reasons policy-level MFA claims do not hold up.
• Teams now need account-level evidence linked to asset inventory if they want to defend compliance under Part 500.

Key terms

• Ghost Login: A ghost login is a secondary or legacy authentication route that remains active after a newer sign-in method has been added. In practice, it often means a local password or fallback path still works even when the organisation believes SSO and MFA are fully enforced.
• Account-level MFA validation: Account-level MFA validation is the practice of proving that each specific user or service account actually authenticates with MFA, rather than assuming protection from a central policy. It is more precise than policy reporting because it reveals alternate login methods and exception paths.
• Shadow SaaS: Shadow SaaS is software used for work that exists outside formal IT visibility or governance. It becomes an identity risk because unknown applications often create unmanaged accounts, unreviewed login methods, and access routes that do not appear in standard IAM reporting.
• Asset inventory: An asset inventory is the maintained record of systems, applications, and services that an organisation operates or relies on. In identity governance, it is the evidence base for deciding where authentication controls apply and where gaps, exceptions, or unmanaged services may exist.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: NYDFS MFA enforcement and the tightening of Part 500 requirements. Read the original.