Multi-Factor Authentication: Meeting NY DFS 500.12 Requirements

Section 500.12 of NY DFS 23 NYCRR 500 requires covered entities to use multi-factor authentication (MFA). The Second Amendment, adopted in November 2023, replaced the old risk-based rule with a much broader one, which has applied in full since 1 November 2025.

What Does Section 500.12 Require?

Under the current regulation (500.12(a)), MFA is required for any individual accessing any of your information systems. If you qualify for the limited exemption in 500.19(a), MFA is required for:

Remote access to your information systems
Remote access to third-party applications, including cloud-based ones, from which nonpublic information is accessible
All privileged accounts, other than service accounts that prohibit interactive login

If you have a CISO, the CISO may approve in writing reasonably equivalent or more secure compensating controls, which must be reviewed at least annually (500.12(b)).

2023 Amendment Changes

The November 2023 amendment gave covered entities two years to meet the new MFA rule (500.22(d)(4)). Since 1 November 2025, MFA covers every individual accessing any information system, not just remote access to internal networks. That includes employees on the office network, cloud services and SaaS applications. The old option of "risk-based authentication" was removed.

What Qualifies as MFA?

Multi-factor authentication requires at least two of the following factors:

Something You Know

Password, PIN, security questions

Something You Have

Phone, hardware token, smart card

Something You Are

Fingerprint, facial recognition, voice

Acceptable MFA Methods

Not all MFA methods provide equal security. Here's a breakdown:

Recommended Methods

Hardware security keys (FIDO2/WebAuthn) - Most secure option
Authenticator apps (Microsoft Authenticator, Google Authenticator) - Strong and practical
Push notifications - Convenient with good security

Acceptable but Less Secure

SMS-based codes - Vulnerable to SIM swapping. The amended MFA definition (500.1(j)) no longer lists a text message as an example of a possession factor, so treat SMS as a fallback only
Email-based codes - Only if email itself is protected by MFA

Implementation Strategy

Follow these steps to implement MFA across your organization:

Inventory your systems - Identify all systems requiring MFA protection
Choose your MFA solution - Consider Microsoft 365, Okta, Duo, or similar platforms
Start with privileged users - Implement MFA for admins and IT staff first
Roll out to all users - Expand to every individual accessing any information system, on-site or remote
Address third-party access - Ensure vendors and contractors use MFA
Train your users - Provide clear instructions and support
Monitor and enforce - Track MFA adoption and enforce compliance

Common Challenges and Solutions

User Resistance

Some employees may resist MFA as inconvenient. Address this by explaining the security benefits, providing training, and choosing user-friendly methods like push notifications.

Legacy Systems

Older systems may not support modern MFA. Consider using a VPN or identity proxy that adds MFA in front of legacy applications.

Lost Devices

Have a recovery process in place for when users lose their MFA devices. This should include identity verification before resetting MFA.

Buffalo Sentinel MFA Tracking

Our platform monitors MFA enrollment status across your organization and integrates with Microsoft 365, Okta, and other identity providers to provide real-time compliance visibility.

Documentation Requirements

For compliance purposes, maintain records of:

MFA enrollment status for all users
Systems protected by MFA
MFA method used (app, hardware key, etc.)
Any exceptions, with the CISO's written approval of compensating controls and their annual review