NYDFS MFA Requirements: How to Enforce MFA Across Web Applications
Table of contents
NYDFS MFA requirements are no longer limited to VPNs, email, or remote access. As of November 1, 2025, 23 NYCRR Part 500.12 requires covered entities to use multi-factor authentication for any individual accessing their information systems, unless a limited exemption or approved compensating control applies.
For many teams, the challenge is not enabling MFA in Okta, Microsoft Entra ID, Ping, Duo, or another identity provider. The harder problem is enforcing MFA everywhere users actually log in: external-facing portals, internal apps, vendor access, admin tools, and direct login pages that may still accept only a password.
Datawiza helps enforce MFA at the access layer across any web application, using built-in MFA with existing application credentials or MFA from an existing enterprise identity provider.
What NYDFS MFA Requires
Under Section 500.12, covered entities must use MFA for individuals accessing information systems. Organizations with a limited exemption under Section 500.19(a) still need MFA for remote access, third-party applications where nonpublic information is accessible, and privileged accounts other than non-interactive service accounts.
If a covered entity has a CISO, the CISO may approve reasonably equivalent or more secure compensating controls in writing, with periodic review at least annually.
The NYDFS MFA Challenge: Cover Every Web Application
The compliance test is coverage. Every in-scope application and access path must enforce MFA, whether the app is modern or legacy, customer-facing or internal, custom-built or packaged.
Customer-Facing and Third-Party Web Applications
Customer, broker, partner, and vendor portals often expose nonpublic information or support important business workflows. These applications may use local accounts, separate user stores, or login patterns that do not fit a workforce identity rollout. Datawiza can add MFA without requiring every external user to move into the enterprise identity provider.
Internal, Administrative, and Privileged Web Applications
Many internal applications already use enterprise SSO and MFA. The remaining gaps often appear in admin tools, custom applications, packaged systems, privileged interfaces, and direct login pages that still accept a password without an MFA challenge.
If a user can reach an in-scope web application using only a password, that access path is an MFA coverage gap.
How Datawiza Enforces NYDFS MFA Across Web Applications
Datawiza Access Proxy sits in front of web applications and applies MFA at the access layer before approved traffic reaches the protected app. See how Datawiza can add MFA to any web app using built-in MFA or an existing identity provider.
This gives teams one MFA enforcement pattern across on-premises, private-cloud, public-cloud, customer-facing, internal, modern, custom, packaged, and legacy web applications.
Built-in MFA is a practical fit for customers, partners, vendors, and other external users who are not in the organization's enterprise identity provider. Users sign in with the application username and password they already have. After the application verifies those credentials, Datawiza triggers MFA and grants access only after the challenge succeeds. No IdP account or user migration is required.
Enterprise IdP MFA is a natural fit for employees and internal users who already use the organization's identity provider. Datawiza integrates with Microsoft Entra ID, Okta, Ping Identity, Cisco Duo, Google Identity, and other IdPs, extending the organization's existing authentication and MFA policies to web applications that do not natively integrate with the IdP.
With Datawiza, organizations can:
- Enforce MFA across modern, custom, packaged, and legacy web applications
- Protect customer-facing, third-party, internal, administrative, and privileged access
- Preserve existing application login, session, and user-store patterns
- Use Datawiza built-in MFA or MFA from an existing enterprise identity provider
- Block direct password-only access paths
- Capture authentication and access logs for audit and compliance review
Teams can standardize MFA coverage without turning every application into a separate identity migration, customization, or development project.
NYDFS MFA Checklist
Use this checklist to find the gaps that matter most:
- Inventory all authenticated applications.
- Identify apps that still accept password-only login.
- Check whether SSO-protected apps still expose local login pages.
- Review portals and third-party apps with access to nonpublic information.
- Confirm MFA for privileged accounts, except non-interactive service accounts.
- Document compensating controls, CISO approvals, and MFA enforcement logs.
Close NYDFS MFA Coverage Gaps Across Web Applications
NYDFS MFA compliance is not just an identity provider setting. It requires proof that MFA is enforced across the real access paths people use. Whether the application is modern, packaged, custom-built, or legacy, Datawiza provides a consistent enforcement layer in front of it.
Book a demo to see how Datawiza enforces NYDFS MFA across web applications through the access layer.
