SSOGEN / NYDFS MFA: What 23 NYCRR 500.12 Requires and Which Controls Relate
SSOGEN
NYDFS MFA: What 23 NYCRR 500.12 Requires and Which Controls Relate
Read 23 NYCRR 500.12 line by line, each requirement set beside the SSOGEN policy setting that answers it.
NYDFS MFA is short to state and wide in reach. Section 500.12(a) of 23 NYCRR Part 500 says multi-factor authentication “shall be utilized for any individual accessing any information systems of a covered entity”, unless the entity qualifies for a limited exemption.
Below: what the text says, then the SSOGEN control that relates to each part. This is not legal advice.
Software alone does not make an organization compliant.
Whether you are a covered entity, which exemption applies, and whether your controls are enough are decisions for you, your counsel and your regulator.
What section 500.12 says
Sources: the Cornell Legal Information Institute copy of the New York code and the Department of Financial Services (DFS) guidance, both read 2026-10-08.
500.12(a) requires MFA for any individual accessing any information system of a covered entity. An entity that qualifies for the limited exemption in section 500.19(a) needs MFA only for:
- remote access to the covered entity’s information systems;
- remote access to third-party applications, including cloud-based ones, from which nonpublic information is accessible; and
- all privileged accounts, except service accounts that prohibit interactive login.
500.12(b). If the entity has a CISO, the CISO can approve in writing reasonably equivalent or more secure compensating controls. Those controls are reviewed periodically, at least once a year.
What counts as MFA. Section 500.1 defines it as checking at least two of three factor types: knowledge (such as a password), possession (such as a token) or inherence (such as a biometric characteristic).
When. DFS’s July 2025 guidance on MFA says the amendments phase in from November 2023 through November 2025.
From November 1, 2025. Covered entities must use MFA for any individual accessing any information system. Location, type of user and type of information do not matter.
SMS codes. The same guidance says SMS codes are generally weaker, because of SIM-swapping and interception.
App approval. The guidance also says app-based approval with number matching is more secure than push approval without it.
Which SSOGEN controls relate to each requirement
| Requirement in 500.12 | SSOGEN control that relates | How it is set |
|---|---|---|
| MFA for any individual accessing any information system (a) | An authentication policy with Required strength set to Plus a second factor or Passkey or security key, assigned per application or as the default policy | SSO Policies > Policies in the Admin Console |
| Systems that have no MFA of their own | SSOGEN signs people in in front of the application through the Web Agent or the SSOGEN Gateway, so the second factor is enforced even where the application knows nothing about it | Per application |
| Remote access to information systems (a)(1) | Network zones and access rules, so a rule can require a stronger sign-in when the person is off the corporate network; Remote Access (SSH, RDP and VNC in the browser through the Gateway, with approvals and audit) | Policy rules and zones |
| Remote access to third-party and cloud applications (a)(2) | Applications connected by SAML or OpenID Connect carry the same policy; for sign-in done at another provider, SSOGEN trusts what that provider reports about how strongly the person signed in | Application’s sign-in policy |
| Privileged accounts (a)(3) | A separate sign-in policy for the Admin Console, which never accepts email or text codes; administrators must enter admin mode with an authenticator code (“Confirm administrator elevation”), on by default | Settings > Security |
| Possession and inherence factors (500.1) | Authenticator app (TOTP) codes and passkeys or security keys, where the device checks a fingerprint, face or PIN. Email and text codes are off unless a policy lists them, and are labeled weaker | Policy’s Second step |
| Weak methods (DFS guidance) | Leave Text message and Email off in the policy | Policy |
| Compensating controls approved by the CISO (b) | Not a software setting. The audit log and the What if simulator help you document what a control does | Organizational process |
| Showing an examiner what happened | A tamper-evident audit log with a hash chain, a daily signed checkpoint and export | Monitoring > Audit |
Two caveats about how SSOGEN works matter in an assessment.
- Windows desktop sign-in. Kerberos counts as single-factor, so a policy that requires a second factor still asks for one.
- The policy picks the methods. Someone with no usable method cannot sign in under a policy that requires one. Plan enrollment before you tighten a policy.
A checklist for your own review
- Exemption. Decide with counsel whether the limited exemption in 500.19(a) applies to you. It turns on employees and contractors, revenue or assets, as the text spells out.
- Systems. List every information system and mark where MFA is enforced today. Applications with no MFA of their own are the first gap to close.
- Privileged accounts. Put privileged accounts under the strictest policy. Test it with the What if simulator before you enforce it.
- Weak methods. Turn off email and text codes unless you have a written reason to keep them.
- Service accounts. Check that your own process handles service accounts, since 500.12(a)(3) treats them separately.
- Compensating controls. Record any CISO-approved compensating control and its annual review. 500.12(b) requires the written approval and the periodic review.
Questions people ask
Does SSOGEN make us compliant with NYDFS MFA?
No software does that on its own. SSOGEN provides the controls each requirement relates to, and compliance remains a judgment about your whole organization.
Is MFA required for all employees?
Under the text and DFS guidance above, yes: from November 1, 2025, MFA applies to any individual accessing any information system. A limited exemption or a CISO-approved compensating control is the exception.
Does the regulation say which MFA methods are acceptable?
Section 500.1 gives the three factor types. DFS’s guidance weighs the trade-offs between methods and does not ban any of them.
Where to go next
- MFA software. MFA software and passkeys.
- Adaptive authentication. How adaptive authentication policies decide when to ask for a second factor.
- Setup. The multi-factor authentication setup guide.
- Insurance. Insurers ask similar questions. See cyber insurance MFA.