Yes, on the plain text. Section 500.12(a) of NYDFS Part 500 requires multi-factor authentication for any individual accessing any information system of a covered entity, unless a limited exemption applies. Git hosting, CI consoles, cloud accounts and admin panels are information systems, so engineers sit inside the rule.
This is general information, not legal advice.
The rule in two sentences
Section 500.12(a) says MFA must be used for any individual accessing any information systems. Section 500.12(b) lets a CISO approve in writing a reasonably equivalent or more secure compensating control, and requires that such controls be reviewed at least annually.
The definition in 500.1 says MFA means verifying at least two of three factor types: knowledge, possession or inherence. A password plus a hardware key qualifies. Two passwords do not.
Where engineering teams find gaps
Gaps rarely show up in the corporate directory. They show up at the edges:
- Source hosting accounts that use a local password outside single sign on.
- Package registry and container registry accounts held by one person.
- CI and deployment consoles with shared logins.
- Cloud root and break glass accounts.
- Vendor and contractor access to staging or support tooling.
Section 500.1 defines an authorized user as an employee, contractor, agent or other person who is authorized to access the covered entity's systems. Contractors are therefore in scope.
What about service accounts and tokens
Machines do not use a second factor in the way people do. The text of 500.12(a) speaks about individuals. The limited exemption branch mentions privileged accounts other than service accounts that prohibit interactive login, which shows the drafters distinguished them. How your program treats API tokens and deploy keys is a risk assessment and policy decision. A sound approach is to bind tokens to a service identity, scope them narrowly, rotate them, and make sure nobody can use one to log in interactively.
A review you can run this quarter
- List every developer facing system and how people sign in.
- Mark each as single sign on with MFA, local MFA, or password only.
- Close password only gaps first, starting with systems that touch production or nonpublic information.
- For anything you cannot fix, write down the compensating control and who approved it.
- Put the annual review of those approvals on a calendar.
Mistakes to avoid
Three errors come up often. Treating single sign on as the same thing as MFA, when the identity provider itself accepts only a password. Exempting a few senior engineers because the prompt is annoying, which creates the most valuable targets without a second factor. And approving a compensating control once and never looking again, when the rule asks for an annual review. Fix these by testing sign in from a clean browser, by publishing the exception list to the CISO, and by putting the annual review of approvals on the same calendar as the access review.
Quick check
Who can approve a compensating control?
If the covered entity has a CISO, the CISO may approve in writing a reasonably equivalent or more secure control, and it must be reviewed at least annually.
Does a limited exemption remove MFA entirely?
No. Under 500.12(a) an exempt entity must still use MFA for remote access to its systems, remote access to third party applications that hold nonpublic information, and privileged accounts other than non interactive service accounts.
Sources
Last reviewed: 19 October 2026.
