Multi‑factor authentication (MFA) is now a well-established baseline cybersecurity control. The amended New York Department of Financial Services (NY DFS) solidified that understanding and expanded MFA requirements under 23 NYCRR Part 500 (the NY DFS Cybersecurity Regulation). Since November 1, 2025, Covered Entities are required to use MFA for any individual accessing the Covered Entity’s information systems, subject to limited exceptions.
In its “Let’s Talk MFA” training on February 26, 2026, NY DFS highlighted additional guidance including updated FAQs addressing Section 500.12. Covered Entities have until April 15, 2026 to certify their compliance with the NY DFS Cybersecurity Regulation in the annual notifications to NY DFS.
Put simply, NY DFS expects Covered Entities to show that MFA is implemented effectively across their systems, that the scope is complete, and that any risk-based exceptions or compensating controls are well documented, with particular attention to SSO, cloud services, and external-facing systems.
The FAQs provide notably granular direction on how NY DFS views common MFA approaches. The FAQs provide guidance on (i) what does and does not qualify as MFA, (ii) push-based authentication, (iii) single sign-on (SSO), (iv) cloud platforms, and (v) when external-facing systems may require MFA.
NY DFS defines MFA as authentication using at least two different factor types:
Knowledge – something you know, such as a password, passphrase, or PIN.
Possession – something you have, such as a token, authenticator app, or smartcard.
Inherence – something you are, such as a biometric characteristic.
NY DFS emphasizes utilizing multiple distinct factor categories. Simply layering more checks that fall into a single bucket does not satisfy NY DFS’s requirements. For example, requiring two passwords is not considered MFA, because both passwords fall under the same “knowledge” factor type. Requiring a password (a “knowledge” factor) plus a token placed on your company-issued device (a “possession” factor) would constitute MFA since those incorporate two different factor types.
“Possession” means real proof of possession. NY DFS highlights that a possession factor should provide cryptographic or technical proof that the user controls a specific device/token/authenticator at the moment of authentication.
Push-based MFA is common, but NY DFS is focused on its weaknesses. NY DFS flags risks associated with push prompts (including “MFA fatigue”) and points to safeguards such as number-matching or challenge-response, displaying contextual login details, limiting push retries, and using adaptive MFA for suspicious activity.
Single sign-on (SSO) can work, but SSO alone is not the answer. NY DFS states SSO may be used; however, MFA must be enforced as part of the authentication process in order to prevent the SSO layer from becoming a bypass route.
Cloud email and document platforms are firmly in scope. NY DFS indicates that MFA is required for Covered Entities accessing cloud-based document storage and collaborative platforms.
External-facing systems: often no MFA, but “material risk” changes the analysis. NY DFS notes that many external-facing systems, such as basic marketing pages, may not require MFA. But MFA may be expected where an external-facing system can be used to access other information systems without authentication, or where it otherwise poses a material cybersecurity risk to the Covered Entity, customers, other systems, or nonpublic information. For example, an insurance company’s website that contains only publicly available marketing materials would not need MFA. If the website enables access to personal information, however, additional analysis may be necessary.
Part 500 permits “reasonably equivalent or more secure” compensating controls in in place of MFA, but only with specific governance guardrails: CISO approval in writing and periodic review at least annually. Similarly, in examinations, NY DFS often focuses on the reasonableness of the decision-making and the supporting documentation, not just the existence of a tool. A compensating control may be reasonable immediately following the acquisition of another company during the transition period but may not be reasonable the following year.
NY DFS’s recent guidance reinforces that MFA is a baseline expectation under Part 500. In practice, NY DFS supervision focuses on whether MFA is implemented effectively, whether coverage is complete, and whether exceptions or alternatives are supported by documentation and governance. Here are a few steps to help identify potential gaps and achieve compliance:
1. Confirm MFA is implemented broadly and consistently
Validating that MFA is not only deployed but consistently enforced across the access paths and information systems is key. NY DFS highlights the scope and sufficiency of implementation, including whether MFA has been implemented with third-party platforms.
2. Review documentation supporting MFA scope and design choices
NY DFS emphasizes documentation and reasonableness of risk-based determinations. Even strong technical controls can fall short if the organization cannot explain scope, exceptions, and design decisions.
3. Review and assess whether the existing process for compensating controls meets NY DFS requirements
NY DFS highlights governance requirements for compensating controls, including written CISO approval and periodic review at minimum annually.
The NY DFS guidance is another reminder for Covered Entities to get ready to demonstrate that MFA is consistently enforced across environments, and any exceptions or compensating controls are supported by clear documentation and governance practices.
Thanks to Jake Alfarah for his assistance with this post.