Remote access
NYDFS Part 500 programs commonly need MFA for remote access into information systems.
NYDFS MFA
Datawiza Access Proxy helps regulated teams enforce MFA for web applications, remote access, third-party applications, and privileged accounts without rewriting every application before an audit or remediation deadline.










Section 500.12 focus areas
The hard part is not understanding that MFA is required. The hard part is applying it consistently across business web apps, third-party access paths, remote access workflows, privileged tools, and older applications that were not built for modern MFA.
NYDFS Part 500 programs commonly need MFA for remote access into information systems.
Third-party and cloud applications where nonpublic information is accessible can create MFA coverage gaps.
Privileged accounts need stronger controls, especially when admin tools or legacy portals do not support modern MFA natively.
Where Datawiza helps
Use Datawiza when regulated applications need MFA coverage now, but the app portfolio includes old portals, custom apps, on-prem tools, and vendor-facing systems.
Add MFA in front of apps that cannot easily support modern authentication, SAML/OIDC, or direct MFA SDK work.
Protect employee, customer, partner, vendor, and internal portals without rewriting each app before a compliance deadline.
Apply one access-layer pattern across apps that live on premises, in private cloud, or in hybrid environments.
Capture access decisions and policy enforcement signals that security teams can use during audits and remediation planning.
Customer proof
“Datawiza is the least friction option to move to a modern MFA. By going with Datawiza and getting this done in a very short time, we were the heroes.”
Rollout pattern
Start where the risk and compliance pressure are highest, prove the pattern, then expand across the application portfolio.
Map web applications and access paths that fall into MFA scope, including remote access, third-party applications with nonpublic information, privileged tools, customer portals, internal apps, and legacy systems.
Place Datawiza Access Proxy in front of the web applications that need stronger authentication, without changing app code.
Enable MFA policies for the right users, groups, apps, and paths. Start with the highest-risk access points first.
Review logs, access outcomes, and rollout status so security and compliance teams can show progress and plan remediation.
Comparison
App-by-app MFA work is sometimes necessary. Datawiza is the faster path when the immediate need is consistent enforcement across apps that already exist.
| Criteria | Datawiza Access Proxy | App-by-app remediation |
|---|---|---|
| Legacy app support | Enforce MFA through the proxy without changing app code | May require app rewrite, SDK work, or identity protocol support |
| External-facing portals | Protect customer, partner, vendor, and employee web access | Often handled app by app with inconsistent controls |
| Rollout speed | Pilot one app, then repeat the access-layer pattern | Timeline depends on every app team and integration path |
| Audit evidence | Centralized MFA enforcement and access logs | Evidence may be split across individual applications |
FAQ
NYDFS Part 500 MFA planning commonly focuses on remote access, third-party applications where nonpublic information is accessible, and privileged accounts. Teams should confirm exact applicability with their compliance and legal advisors.
Yes. Datawiza Access Proxy can enforce MFA outside the application, which helps when legacy or custom apps cannot be changed quickly.
Datawiza is not a legal compliance certification tool. It helps enforce MFA and generate access evidence that can support a broader NYDFS cybersecurity program.
A practical rollout usually starts with high-risk web applications, remote-access paths, privileged tools, or third-party-access applications, then expands across the app portfolio.
Related MFA use cases
Explore practical MFA patterns for customer portals, internal systems, legacy applications, ERP platforms, and other existing web apps.
Start with the main overview for built-in MFA, proxy enforcement, app coverage, and rollout strategy.
Get the definition of no-code MFA, including built-in MFA, identity provider mode, and where access-layer enforcement fits.
Protect PeopleSoft HCM, payroll, employee self-service, retiree portals, and other web-based HR systems without changing app code.
Add MFA to legacy applications without changing source code, migrating users, or waiting for an application rewrite.
Add MFA or 2FA to public-facing, external-facing, internet-facing, internal, and custom web applications without changing app code.
Add MFA to IIS applications without touching code, using Datawiza built-in MFA or Entra ID, Okta, Ping, or Duo as the identity provider.
Protect admin portals, admin dashboards, back-office apps, and privileged web consoles with MFA before app access.
Protect customer portals, partner apps, vendor portals, and customer-facing applications without forcing a CIAM migration.
This page is for informational purposes only and is not legal advice. Organizations should review NYDFS Part 500 requirements with their legal, compliance, and security teams. Datawiza is not affiliated with or endorsed by the New York State Department of Financial Services.
From industry events to new product releases, read it here first.
Sign up to secure your AI agents and critical enterprise apps