The New York Department of Financial Services (NYDFS) has released a new set of Frequently Asked Questions (FAQs 18–23) under 23 NYCRR Part 500, reinforcing its position that multifactor authentication (MFA) remains a critical component of a covered entity’s cybersecurity program. These FAQs provide highly prescriptive guidance, including clarifications on technical requirements for the “possession” factor and risks associated with push-based authentication methods. We have summarized below the key takeaways from the updated FAQs that covered entities should consider moving forward.
FAQs 18 & 19 – Defining “Something You Have”
NYDFS emphasizes that MFA must include at least two of the following methods of authentication: (1) knowledge (something you know, such as a password or PIN), (2) possession (something you have, such as a hardware token or mobile device), and (3) inherence (something you are, such as a fingerprint or facial recognition). The newly issued FAQs provides important clarification on what qualifies as the “Possession” factor. Previously, in the Assessment of Public Comments (APCs) accompanying the Second Amendment, NYDFS indicated that it may be acceptable, in some circumstances, to use a device, such as an office workstation, mobile phone, or laptop as one of the authentication methods. This language suggested a degree of flexibility, implying that access from a trusted corporate device (e.g., a company-issued phone) could satisfy one of the MFA verification method requirements.
FAQs 18 and 19 significantly narrow the interpretation of what qualifies as the “Possession” factor. As a result, standard trusted devices — even those with mobile device management (MDM) software installed — are effectively excluded from satisfying this element of MFA. For example, FAQ 18 clarifies that a valid “something you have” factor typically requires cryptographic proof of possession, meaning the system can mathematically verify that the key or token is authentic and uniquely tied to the user and their device. Simply relying on a computer to “remember” information is not sufficient. FAQ 18 explicitly states that methods based solely on device recognition, policy-based controls, or software-stored certificates do not constitute reasonable evidence of possession, as these approaches can be easily copied or bypassed and are therefore insufficient to meet the MFA requirements under § 500.12.
FAQ 20 – Strengthening Push Notifications
Many organizations use push-based authentication methods, such as sending a notification to a user’s mobile device to “Approve” or “Deny” a login request, as a means of satisfying the “Possession” factor for MFA. However, as noted in NYDFS’s 2021 guidance on MFA, FAQ 20 emphasizes that this approach is a higher risk due to the growing prevalence of MFA fatigue (also known as push bombing), where users overwhelmed by repeated prompts inadvertently approve a malicious request. Consistent with regulators growing expectations for phishing-resistant MFA, FAQ 20 notes that push-based MFA is not phishing-resistant, making it vulnerable to fake login prompts and real-time phishing attacks that can lead to session hijacking.
To mitigate these risks, NYDFS recommends implementing the following safeguards:
- Enable Number Matching or Challenge-Response Verification: Replace the simple “Approve” button with a mechanism requiring the user to enter a two-digit number displayed on the login screen into their authenticator app. This ensures the user is physically present at the device initiating the login, reducing the likelihood of accidental approvals.
- Display Contextual Login Details: MFA notifications should include specific information about the login attempt, such as geographic location, IP address, or application name, so users can quickly identify and reject suspicious requests.
- Limit the Number of Push Retries and Enforce Adaptive MDA for Suspicious Activity: Restrict the number of times a push notification can be retried to reduce MFA fatigue and brute force attempts. In addition, implement adaptive MFA, which dynamically adjusts authentication requirements based on risk signals. For example, if the system detects unusual behavior — such as multiple failed attempts, an unfamiliar device, or a login from a high-risk location — it should escalate the challenge by requiring stronger verification (e.g., number matching, additional factors, or phishing-resistant methods). This approach helps prevent attackers from exploiting stolen credentials through repeated MFA prompts.
FAQ 21 – Single Sign-On
FAQ 21 clarifies that Single Sign-On (SSO) by itself does not meet NYDFS’s MFA requirements. SSO is an authentication method that allows users to access multiple applications or systems using a single set of credentials, typically by logging in once through a centralized identity provider (IdP). While SSO simplifies user experience and reduces password fatigue, it does not inherently provide multi-factor authentication.
To comply with NYDFS, covered entities must enforce MFA at the point of authentication to the IdP — meaning users must complete MFA when initially logging into the SSO platform. Once MFA is successfully applied at this initial login, the user can access integrated applications without re-authenticating for each one. The guidance makes clear that MFA is not required for every individual application accessed through SSO, provided the initial SSO login is MFA-protected. This approach ensures strong security at the gateway while maintaining usability across connected systems.
FAQ 22 – Cloud-Based Services
FAQ 22 makes clear that cloud-based platforms, such as cloud-based email (e.g., O365), document hosting, and collaboration tools, are “information systems” as defined under Part 500. Accordingly, MFA is required to access these cloud-based platforms, even if hosted by the third party cloud-provider.
FAQ 23 – Public Websites: A Shift in Scope and New Administrative Burden
FAQ 23 provides new guidance on external-facing information systems, including public-facing websites. As a baseline requirement, covered entities that do not qualify for an exemption under § 500.12 must implement MFA for every external-facing information system — including public websites (which NYDFS interprets to include marketing and informational pages) and applications.
If a covered entity elects not to implement MFA on an external-facing system, the CISO must formally document that the system:
- Does not contain nonpublic information (NPI), or that any NPI has been pseudonymized or tokenized;
- Does not allow unauthenticated access to other internal information systems; and
- Does not pose material cybersecurity risk to the entity, its customers, other systems, or NPI.
This requirement creates a compliance burden, as CISOs must produce “negative assurance” documentation for low-risk public assets.
The latest NYDFS FAQs (18–23) reflect a clear shift toward more prescriptive and rigorous MFA standards. Covered entities should proactively review their MFA architecture, confirm compliance across all systems — including cloud services and external-facing applications — and strengthen MFA protocols where appropriate.
