Multi-Factor Authentication Requirements

Under 23 NYCRR § 500.12, you must enforce multi-factor authentication (MFA) for (1) any access to your information systems from an external network, (2) all privileged accounts, and (3) remote access to third-party applications where nonpublic information is accessible. Operationalize this by scoping the access paths, standardizing MFA methods, enforcing through centralized identity controls, and retaining evidence that MFA is consistently required and cannot be bypassed. (23 NYCRR Part 500)

Key takeaways:

• Scope MFA to three buckets: external-network access, privileged accounts, and remote third-party applications with nonpublic information access. (23 NYCRR Part 500)
• Implement MFA as a control enforced by your identity layer (SSO/IdP, PAM), not as an honor-system policy. (23 NYCRR Part 500)
• Keep audit-ready artifacts: system inventory, access mappings, conditional access rules, MFA enrollment reports, and exception approvals. (23 NYCRR Part 500)

Multi-factor authentication requirements often fail in execution for one reason: teams implement MFA “in the abstract” (some systems, some users, some conditions) and assume they are covered. 23 NYCRR § 500.12 is narrower and more operational. It tells you exactly where MFA must exist, and examiners will test those specific access paths. The 2023 amendments expanded the practical scope: remote access to your information systems, remote access to third-party applications where nonpublic information is accessible, and all privileged accounts. (23 NYCRR Part 500)

For a CCO, GRC lead, or security governance owner, the job is to translate that scope into enforceable controls and durable evidence. That means: identify which systems are “information systems,” enumerate how people access them from external networks, define privileged accounts across IT and SaaS, and map third-party applications that expose nonpublic information. Then enforce MFA with centralized identity and privileged access tooling, manage exceptions tightly, and prove it works with logs and reports. (23 NYCRR Part 500)

Regulatory text

Requirement (operator interpretation): “Each covered entity shall implement multi-factor authentication for any individual accessing the covered entity's information systems from an external network, privileged accounts, and remote access to third-party applications containing nonpublic information.” (23 NYCRR Part 500)

What the operator must do

You must make MFA mandatory in three situations: (1) access to your information systems from an external network, (2) use of privileged accounts, and (3) remote access to third-party applications where nonpublic information is accessible. “Multi-factor” means at least two factors from knowledge, possession, or inherence. Your control design must prevent access if MFA is not satisfied, and you must be able to demonstrate that enforcement consistently. (23 NYCRR Part 500)

Plain-English interpretation (what MFA must cover)

Treat § 500.12 as a scope statement plus a control requirement:

1. External-network access to information systems: If someone is not on your internal network and they access an information system (VPN, VDI, web apps, cloud consoles, admin portals), MFA must be required. (23 NYCRR Part 500)
2. Privileged accounts: If an account can administer, configure, change security settings, manage identities, access sensitive data broadly, or bypass controls, it must use MFA every time it is used. Don’t limit “privileged” to domain admins; include SaaS admins and cloud IAM roles. (23 NYCRR Part 500)
3. Remote access to third-party applications with nonpublic information access: If a third-party application can be accessed remotely and exposes nonpublic information (for example, CRM, portfolio/accounting systems, claims platforms, HR systems), MFA must be required for that remote access. (23 NYCRR Part 500)

Who it applies to (entity and operational context)

Entities

• Covered entities under NYDFS Cybersecurity Regulation such as financial institutions and state-registered advisers. (23 NYCRR Part 500)

Operational context (where teams get tripped up)

MFA scope is not limited to employees. The text applies to “any individual” accessing in-scope paths. That includes:

• Employees and interns
• Contractors and consultants
• Third-party support personnel
• Developers and IT administrators
• Temporary staff during incidents or conversions
  All of those identities must be addressed by your identity governance, access provisioning, and third-party access processes. (23 NYCRR Part 500)

What you actually need to do (step-by-step)

Step 1: Define MFA standard and acceptable factors

Document what counts as MFA in your environment: at least two factors from knowledge/possession/inherence. Avoid “password + email link” designs that collapse into a single compromised mailbox. Write down your approved methods (for example, authenticator app, hardware key, biometric tied to a managed device) and your prohibited methods (for example, shared OTP accounts). (23 NYCRR Part 500)

Deliverable: MFA Standard (1–2 pages) mapping allowed MFA methods to factor types. (23 NYCRR Part 500)

Step 2: Build the MFA scope inventory (the three buckets)

Create a single table with three sections:

1. External network → information systems

• List information systems and their access methods: VPN, VDI, SSH, RDP gateways, cloud consoles, web admin portals, enterprise apps.
• Identify which are reachable from external networks and which identities use them. (23 NYCRR Part 500)

2. Privileged accounts

• Define privileged accounts (include break-glass, service accounts with interactive login, SaaS super-admins, cloud IAM admins, security tooling admins).
• Enumerate privileged groups/roles in each system. (23 NYCRR Part 500)

3. Remote third-party applications with nonpublic information access

• Inventory third-party applications where nonpublic information is accessible.
• Confirm how access happens (SSO via IdP, local accounts, vendor-managed identities). (23 NYCRR Part 500)

Deliverable: MFA Scope Register (system, access path, user population, MFA enforcement point, owner). (23 NYCRR Part 500)

Step 3: Choose enforcement points (make MFA non-bypassable)

You want MFA enforced at the layer you control:

• Identity Provider (IdP)/SSO: Conditional access rules requiring MFA for remote access and for admin roles.
• Privileged Access Management (PAM): MFA at checkout/approval, session start, and step-up for sensitive commands.
• VPN/Remote access gateways: MFA at connection time.
• SaaS apps not on SSO: Turn on native MFA and restrict to strong factors; migrate to SSO where feasible. (23 NYCRR Part 500)

Decision rule: If an application is in the scope register and MFA cannot be enforced reliably, it becomes a remediation priority or requires a tightly governed exception with compensating controls documented. (23 NYCRR Part 500)

Step 4: Implement policies for each bucket

Use separate, testable policies:

• Remote access policy: MFA required for any authentication from external networks to in-scope systems.
• Privileged access policy: MFA required for all privileged accounts; include step-up MFA for privilege elevation.
• Third-party application access policy: MFA required for remote access to third-party apps exposing nonpublic information, ideally through SSO with enforced MFA. (23 NYCRR Part 500)

Practical control tests: Try to log in from an unmanaged network/location, try a privileged role, and try a third-party app path. The expected result is “blocked or prompted for MFA,” with logs proving it. (23 NYCRR Part 500)

Step 5: Handle exceptions without creating a permanent hole

Examiners focus on exceptions because they become the real control environment. If you must permit an exception:

• Require written approval by the control owner and security leadership.
• Define compensating controls (for example, network restrictions, monitored jump host, time-bound access, session recording, narrowed privileges).
• Set an expiration and a remediation owner.
• Track exceptions centrally. (23 NYCRR Part 500)

Step 6: Operationalize onboarding, offboarding, and periodic assurance

• Joiner/mover/leaver: Enrollment in MFA must be part of identity lifecycle.
• Privileged access requests: Route through ticketing with role approval, then enforce MFA in PAM/IdP.
• Monitoring: Review authentication logs and MFA enrollment status; investigate repeated MFA failures and unusual bypass patterns.
• Third-party access: Provision third-party users through your identity stack where possible, not through ad hoc vendor local accounts. (23 NYCRR Part 500)

Step 7: Package evidence for audit and exams

Don’t wait for the exam request list. Maintain an “MFA evidence binder” mapped to the three buckets in § 500.12. (23 NYCRR Part 500)

Required evidence and artifacts to retain

Keep artifacts that prove scope, enforcement, and ongoing operation:

• MFA Standard defining factors and approved methods. (23 NYCRR Part 500)
• MFA Scope Register covering the three required buckets. (23 NYCRR Part 500)
• IdP/SSO conditional access policies (screenshots/exported configs) showing MFA requirements for remote access and admin roles. (23 NYCRR Part 500)
• PAM configurations showing MFA for privileged session initiation and elevation, plus session logs. (23 NYCRR Part 500)
• VPN/remote access configs proving MFA is enforced. (23 NYCRR Part 500)
• SaaS app settings evidence for apps not behind SSO showing native MFA enabled. (23 NYCRR Part 500)
• Enrollment/compliance reports showing which users (including third parties) are enrolled and which are blocked pending enrollment. (23 NYCRR Part 500)
• Exception register with approvals, compensating controls, and expiration tracking. (23 NYCRR Part 500)
• Testing evidence (access test scripts/results, screenshots, log excerpts) showing MFA prompts/blocks for each bucket. (23 NYCRR Part 500)

Common exam/audit questions and hangups

Expect questions framed around completeness and bypass risk:

• “Show me all remote access paths to information systems and where MFA is enforced.” (23 NYCRR Part 500)
• “How do you define privileged accounts, and how do you know you captured all of them?” (23 NYCRR Part 500)
• “Which third-party applications contain or allow access to nonpublic information, and how is MFA enforced for remote access?” (23 NYCRR Part 500)
• “Do any admins have an MFA exception? Why, and what compensating controls exist?” (23 NYCRR Part 500)
• “Demonstrate, live, that MFA cannot be bypassed for a privileged user.” (23 NYCRR Part 500)

Hangup to anticipate: Teams can produce an MFA policy but cannot produce an accurate access-path inventory or a privileged account list that matches reality.

Frequent implementation mistakes and how to avoid them

• Mistake: MFA “enabled” but not “required.” Fix by enforcing MFA via conditional access rules and disabling legacy authentication paths where possible. (23 NYCRR Part 500)
• Mistake: Privileged accounts handled informally. Fix by defining privileged roles centrally, tying them to PAM/IdP policies, and reviewing privileged group membership routinely. (23 NYCRR Part 500)
• Mistake: Third-party application access is ignored. Fix by building a list of third-party apps where nonpublic information is accessible and migrating them to SSO with MFA enforcement, or enabling native MFA with evidence. (23 NYCRR Part 500)
• Mistake: Third-party support uses shared accounts. Fix by requiring named accounts, MFA enrollment, and time-bound access with traceable approvals. (23 NYCRR Part 500)
• Mistake: Exceptions become permanent. Fix by using expirations, tracked remediation, and periodic review with ownership. (23 NYCRR Part 500)

Enforcement context and risk implications

No public enforcement cases were provided in the available sources for this page, so don’t assume what NYDFS “typically” penalizes. Treat MFA as a high-scrutiny control because it sits on the direct path to nonpublic information and administrative control of systems, both explicitly referenced in § 500.12. (23 NYCRR Part 500)

Practical execution plan (30/60/90-day)

Use phases rather than day counts if your environment is complex; the goal is fast risk reduction plus durable coverage.

First 30 days (Immediate)

• Publish the MFA Standard (approved factors, prohibited patterns). (23 NYCRR Part 500)
• Build the MFA Scope Register for the three buckets and assign system owners. (23 NYCRR Part 500)
• Turn on MFA enforcement for privileged accounts in your IdP and key admin consoles where you already have control. (23 NYCRR Part 500)
• Stand up an exception register with required approvals and expirations. (23 NYCRR Part 500)

Next 60 days (Near-term)

• Expand conditional access: require MFA for external-network access to information systems, including VPN/VDI and remote admin portals. (23 NYCRR Part 500)
• Inventory third-party apps with nonpublic information access; prioritize those accessible remotely and not behind SSO. (23 NYCRR Part 500)
• Migrate high-risk third-party apps to SSO or enable native MFA, then capture evidence. (23 NYCRR Part 500)
• Start routine reporting: MFA enrollment, privileged users, exception status. (23 NYCRR Part 500)

Next 90 days (Operationalize and prove)

• Close legacy/bypass paths (for example, local accounts, weak recovery flows) where feasible and document what remains with compensating controls. (23 NYCRR Part 500)
• Implement PAM coverage for privileged sessions if not already in place, or strengthen it (MFA at session start, session logging). (23 NYCRR Part 500)
• Run a table-top test: pick users from each bucket and demonstrate enforced MFA and log evidence end-to-end. Store the results in your evidence binder. (23 NYCRR Part 500)

Where Daydream fits: Use Daydream to maintain the MFA Scope Register, link each in-scope system to its MFA evidence (configs, screenshots, reports), and track exceptions with owners and expirations so your § 500.12 package stays exam-ready as systems change. (23 NYCRR Part 500)

Frequently Asked Questions

Does “any individual” include contractors and third-party support staff?

Yes. The requirement is scoped to “any individual” accessing covered paths, so you should include employees, contractors, and third parties who have accounts or remote access into in-scope systems. (23 NYCRR Part 500)

What counts as “privileged” for MFA purposes?

Treat accounts as privileged if they can administer systems, manage identities, change security configurations, or broadly access sensitive data. Include SaaS admin roles and cloud IAM administrative roles, not only on-prem admins. (23 NYCRR Part 500)

If a third-party application is behind SSO, is that enough?

SSO helps only if your IdP enforces MFA for that application’s remote access and you can produce evidence of the policy and its effectiveness. If the app allows local logins that bypass SSO, you need to control or disable that path. (23 NYCRR Part 500)

Are service accounts required to use MFA?

The regulation text addresses “any individual” and explicitly calls out “privileged accounts.” If a service account is interactive or effectively functions as a privileged user account, treat it as privileged and redesign to remove interactive use or route through controlled privileged access methods. (23 NYCRR Part 500)

Can we allow an MFA exception for a legacy system?

You can document an exception, but you still need to manage the risk with compensating controls and a plan to remediate. Keep approvals, scope, controls, and an expiration in an exception register. (23 NYCRR Part 500)

What evidence is most persuasive to examiners?

Evidence that ties scope to enforcement: a system/access inventory mapped to the three § 500.12 buckets, the actual conditional access/PAM/VPN configurations, and logs or test results showing users are blocked or challenged when MFA is not satisfied. (23 NYCRR Part 500)