NYDFS MFA at a Glance
- Regulation: 23 NYCRR Part 500, Section 500.12 — effective November 1, 2025
- Requirement: MFA for any individual accessing any information system of a covered entity, including customers, clients, agents, and partners on external-facing portals
- Annual certification: due each April 15; the first covering the expanded rule was April 15, 2026
- Per NYDFS, the most common noncompliance: incomplete MFA coverage — and external-facing portals are the most commonly missed systems
- Fastest fix: enforce MFA at a reverse proxy in front of the portal — no code changes, no corporate IdP required, and with the hosted option, only a DNS change to deploy
Most covered entities have MFA solved for employees. The exposed systems are the ones facing outward: customer and client portals, agent and partner portals, loan servicing and claims systems — applications where the users are not employees and were never part of the workforce identity program. In its February 2026 “Let’s Talk MFA” guidance, NYDFS said examiners will look at whether MFA coverage is actually complete, with particular attention to externally accessible systems.
Does NYDFS Require MFA for Customer-Facing Portals?
Yes. Section 500.12 requires MFA for any individual accessing any information system of a covered entity. A customer portal — whether it serves bank customers, borrowers, insurance policyholders, or brokers and agents — is an information system, and the external users who log into it are individuals accessing it. If they sign in with a username and password alone, that is a coverage gap — the exact gap NYDFS identified as the most common MFA violation.
Why External-Facing Portals Are the Hardest to Cover
External users are not in your identity provider. Customers, agents, and partners authenticate against the portal’s own user database. Extending Okta or Entra ID to cover them means external-identity licensing for every user, a migration project, and directory management for people you don’t employ.
The portals have no native MFA. Most were built years ago with a local login and don’t support SAML or OIDC. Adding MFA in code means a development project on a revenue-facing system — or waiting on a vendor roadmap.
Direct access bypasses bolt-ons. NYDFS’s FAQs require MFA at the point of authentication. If the login page works without an MFA challenge on any path, the system is not compliant.
The fallback — documenting compensating controls for a customer-facing portal holding nonpublic information — is a difficult position to defend in an examination. Enforcing MFA is the stronger answer, if it can be done without a rebuild.
Add MFA Without Code Changes — and Without an IdP
The Datawiza Access Proxy enforces MFA in front of the portal instead of inside it, using built-in MFA with no corporate IdP dependency:
- No IdP licensing or migration. External users complete MFA through Datawiza directly — no need to add customers, agents, or partners to Okta or Entra ID.
- The portal keeps its existing login. Users sign in with their current credentials; Datawiza layers an authenticator-app (TOTP) challenge on top. The app’s user database and password flows are untouched.
- No bypass path. The proxy is the only route to the portal, so every request on every URL requires an MFA-verified session — satisfying NYDFS’s point-of-authentication expectation.
- Examiner-ready evidence. Access logs document MFA enforcement per user and per application.
How it works: with Datawiza’s hosted service, a DNS change is all it takes — point the portal’s domain at the proxy and enforcement is live, with no infrastructure to deploy. Organizations that prefer to self-host can run the proxy as a container or VM in their own environment, on-premises or in any cloud. Either way, a user signs in to the portal as usual, the proxy requires a TOTP verification (with one-time enrollment for new users), and only then forwards traffic to the application. No SDK, no plugin, no code changes — a typical portal goes from password-only to enforced MFA in days, including user enrollment communications.
For organizations that prefer IdP-enforced MFA, the Access Proxy also integrates with Microsoft Entra ID, Okta, Duo, Auth0 and others via OIDC/SAML. But no IdP is required.
Datawiza Access Proxy enforces strong multi-factor authentication (MFA) in front of any web app—using either Datawiza MFA or your existing IdP—without rewriting the application.
Frequently Asked Questions
Can the portal keep its existing username and password login?
Yes. The Access Proxy layers the MFA challenge on top of the portal’s existing login — the application is unchanged.
How quickly can we add MFA to an external-facing portal?
With Datawiza’s hosted service, enforcement goes live with a DNS change — no infrastructure to deploy. Including testing and user enrollment communications, a typical portal moves from password-only login to enforced MFA in days, not the months a code-level integration would take.
Do we need to add external users to our identity provider to comply?
No. NYDFS requires MFA to be enforced; it does not mandate how. A reverse proxy with built-in MFA enforces it for external users without IdP licensing or user migration.
If a customer, client, or partner portal is blocking your NYDFS MFA compliance, Datawiza can enforce MFA in front of it — without code changes, in days.
