What the expansion of NYCRR Part 500 means for MFA regulation and compliance

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, due to vulnerabilities affecting both its consumer-facing and internal quoting tools. 

Several of the companies did not have multi-factor authentication in place for insurance agents who used the private version of the tool. 

This isn’t the first time that NYDFS has issued fines for missing MFA. NYDFS fined:

• Travelers Insurance $1.55m for failing to enforce MFA on its system used by insurance agents.

• National Securities Corporation $3m for failing to implement MFA.

• OneMain Financial $4.2m for working with third-party service providers that did not enforce MFA.

NYDFS is not alone in issuing enforcements for missing MFA. Fines levied under HIPAA and GDPR have also penalised MFA gaps. There are also recent examples of insurance claim denial due to the lack of MFA. 

This serves as the backdrop for upcoming changes to NYCRR Part 500 that will further tighten the requirements around MFA and asset inventory procedures. 

How NYCRR Part 500 is getting stricter on MFA

As demonstrated by the enforcements relating to MFA gaps, NYCRR Part 500 is already quite strict on its MFA requirements. Section 500.12 mandates MFA for:

• Remote access to internal systems: Any user connecting from outside the organization’s network (e.g. over the internet or other external networks) must authenticate with MFA.

• Remote access to third-party or cloud applications holding non-public information: Covered entities must also use MFA for access to external applications (such as cloud services) that contain non-public Information. NYDFS explicitly considers platforms like Office 365, Google Workspace, Salesforce, AWS/Azure cloud resources, fintech or AI platforms, and any other third-party service provider systems that handle the company’s data as part of a firm’s “internal network”.

• Privileged accounts: MFA is required for all privileged accounts (administrative or elevated privilege accounts) to prevent unauthorized use. 

The changes coming into place on November 1st broaden the scope of MFA to all access: covered entities must require multi-factor authentication for any individual accessing any of the entity’s information systems, regardless of user type, location, or the sensitivity of the system. In other words, MFA is no longer limited to remote logins or systems containing non-public information – it now applies enterprise-wide, even for internal or on-premises access and for systems that may not hold sensitive data.

The newly introduced requirement for a maintained and periodically reviewed asset inventory of all information systems also directly impacts the scope of MFA enforcement. NYDFS has consistently included outsourced, third-party, and cloud applications services used by an organization within its scope.

What this means for compliance

To be able to maintain compliance with NYCRR Part 500, organizations must:

• Inventory all apps and services that are accessed over the internet.

• Achieve MFA compliance across all apps. 

• Regularly demonstrate an up-to-date app inventory and MFA coverage. 

If this cannot be achieved or a breach occurs that demonstrates inadequate visibility or coverage, precedent indicates that regulatory enforcement will follow. 

Unfortunately, this is easier said than done for most organizations. 

Why is this a problem?

App sprawl and shadow SaaS

Most organizations now use hundreds of SaaS applications, which translates into thousands of sprawling user identities, login methods, and ways to access company systems and data. True MFA coverage expands beyond your centrally managed, SSO-connected apps or your primary enterprise login to any and every app used by your employees for work.

But with many apps not directly managed by IT or properly onboarded, it’s all too common for shadow apps to sit outside the scope of typical audits — but inside the reach of attackers.

Configuration challenges

Even when apps are known about, each app is built differently. Design choices can have a big impact on how authentication and account management is handled. This leads to situations where, for example, apps allow simultaneous login methods, don’t provide admin-level controls to enforce MFA, or allow account config changes on behalf of users in your app tenant.

This isn’t just an app sprawl problem either — even when it comes to core environments the complexities of configuration can lead to coverage gaps. Anyone that’s had to manage group policy in Microsoft, for example, can attest to how convoluted and error-prone this is. 

Ghost logins

When an app is first used, particularly if self-adopted, a username and password is typically created. Even when an SSO login is created, it’s usually added on top of password authentication instead of replacing it. And unless specifically disabled or removed, these password-based login methods can continue to be used. 

Because most organizations rely on configuring MFA at their IdP login, local logins without MFA can go unnoticed. These “ghost logins” can lead to unexpected MFA gaps that leave accounts exposed. According to Push data, 2 in 5 accounts are missing MFA, and many also have a password vulnerability (such as appearing in a password breach or compromised credential feed) that means they’re sitting ducks for an attacker, waiting to be exploited.

The future of compliance

NYDFS is leading the way in terms of its stance on MFA and understanding of the modern, decentralized, SaaS-centric IT landscape. But they’re not alone, and other regulators will follow suit as breaches continue to dominate the headlines. 

It can take a while for a major breach to translate into regulatory enforcement. 2024’s Snowflake breaches are a great example of this. Attackers exploited widespread MFA gaps to log into customer Snowflake tenants and steal hundreds of millions of customer records. This was made worse by the fact that the credentials used to access these accounts were found in infostealer credential dumps dating back to 2020 — just sitting around waiting for attackers to exploit them. 

In the wake of Snowflake, multiple regulatory bodies have yet to make a judgement. The Spanish data protection authority (AEPD), the U.S. FCC, FTC, and various state data protection authorities all have investigations ongoing, with class action lawsuits also taking place against many of the impacted businesses. 

As we’ve seen with NYDFS’s post-breach enforcement, even if you think you’ve complied by rolling out MFA at the application level, but still have vulnerable accounts, you will be penalised in the event of a breach. This is why a policy or control based view of MFA compliance is no longer sufficient — you need to be able to audit and validate MFA configuration at the account level.

How Push Security can help

Push Security’s browser-based security platform observes logins directly in employee browsers, building a comprehensive picture of user identities and login methods across every app.

Push shows you every app your employees are using (even the unmanaged ones you don’t know about), providing detailed information about how users are logging in, and where vulnerabilities exist. This includes accounts missing MFA, where users are logging in with a username and password over SSO, and where a user’s password has appeared in a compromised credential feed. You can also use Push to deliver in-browser guidance to users to prompt them to remediate insecure logins.

With Push, you can build a full picture of your app estate and MFA posture down to the individual account level, with real-time, continuous monitoring of identities to catch and course-correct any drift that could be exploited by attackers — helping you to achieve and maintain compliance with regulations like NYCRR Part 500.

Check out the video below for more information.

Learn more

This isn’t all we do: Push’s browser-based security platform provides comprehensive detection and response capabilities against the leading cause of breaches. Push blocks browser-based attacks like AiTM phishing, credential stuffing, malicious browser extensions, malicious OAuth grants, ClickFix, and session hijacking. You don’t need to wait until it all goes wrong — you can also use Push to proactively find and fix vulnerabilities across the apps that your employees use, like ghost logins, SSO coverage gaps, MFA gaps, vulnerable passwords, and more to harden your identity attack surface.

To learn more about Push, check out our latest product overview or book some time with one of our team for a live demo.