# What NYDFS Part 500 requires for access privileges and MFA

Part 500 requires DFS-regulated firms to limit access to job need, review it at least yearly, end it promptly at departure, and use MFA for nearly all access.

Updated: October 16, 2026

New York's cybersecurity regulation for financial services companies, 23 NYCRR Part 500, sets the account rules in section 500.7. A covered entity must limit each user's access to what their job needs, review all access at least once a year, and end access promptly when people leave. Section 500.12 requires multi-factor authentication (MFA) for anyone accessing the company's information systems. Section 500.11 extends access control expectations to vendors.

## Who Part 500 covers

The rule applies to "covered entities." A covered entity is anyone operating under, or required to operate under, a license, registration, charter, certificate, permit or similar authorization. That authorization must come under the Banking Law, the Insurance Law or the Financial Services Law. It applies even when another regulator also supervises the company.

Size changes some obligations. A "Class A company" has at least $20 million in gross annual revenue in each of the last two fiscal years. That figure counts the covered entity's business and its affiliates' New York operations. It must also have over 2,000 employees, averaged over the last two fiscal years, or over $1 billion in gross annual revenue in each of those years, counting all affiliates. Class A companies carry extra duties in 500.7(c).

Smaller entities may qualify for the limited exemption in 500.19(a). It covers an entity with fewer than 20 employees and independent contractors, or less than $7.5 million in revenue in each of the last three fiscal years. Less than $15 million in year-end assets also qualifies. The exemption doesn't list 500.7, so the access rules apply to them too. It changes how far 500.12 reaches, as described below.

## What 500.7 requires

Section 500.7(a) lists six duties, each based on the company's risk assessment:

1. Limit user access to systems that hold nonpublic information to only what the user's job needs.
2. Limit the number of privileged accounts, and what each one can do, to what the job needs.
3. Use privileged accounts only for tasks that need them.
4. Review all user access at least once a year, and remove or disable accounts and access no longer needed.
5. Turn off, or securely configure, every protocol that allows remote control of devices.
6. End access promptly after people leave.

Part 500 defines a privileged account as any user or service account that can do security-relevant things ordinary users can't. Its examples are adding, changing or removing other accounts, and changing system settings. An admin login to a cloud service that can add or remove users fits that definition.

Where you use passwords, 500.7(b) requires a written password policy that meets industry standards. Class A companies must also monitor privileged access activity, use a privileged access management solution, and automatically block commonly used passwords (500.7(c)).

## Multi-factor authentication under 500.12

The amended 500.12(a) says MFA "shall be utilized for any individual accessing any information systems of a covered entity." MFA means verifying at least two factor types, such as something you know (a password) and something you have.

Entities under the 500.19(a) limited exemption must use MFA in three places:

- Remote access to the company's own systems.
- Remote access to third-party applications, including cloud apps, from which nonpublic information can be reached.
- All privileged accounts, except service accounts that don't allow interactive login.

If the company has a chief information security officer (CISO), the CISO may approve in writing controls that are reasonably equivalent or more secure. Those controls must be reviewed at least once a year.

## Vendors under 500.11

A third-party service provider, in Part 500's terms, is a non-affiliate, other than a government entity, that provides services to the covered entity and can reach its nonpublic information in doing so. Section 500.11(a) requires written policies for the security of systems and data those providers can reach or hold. The policies cover risk assessment of each provider, minimum security practices, due diligence and periodic reassessment.

Section 500.11(b) adds guidelines for due diligence or contract terms. The first item is the provider's own access controls, including its use of MFA under 500.12. The others are encryption, notice to you of a cybersecurity event that affects you, and representations and warranties about the provider's security.

## When the amended rules took effect

The Second Amendment became effective on November 1, 2023. Section 500.22 gave covered entities 180 days to meet most new requirements, with longer periods for some:

| Section | Transition period | Date it ended |
| --- | --- | --- |
| Most other new requirements | 180 days (500.22(c)) | April 29, 2024 |
| 500.7 | 18 months (500.22(d)(3)) | May 1, 2025 |
| 500.12 | Two years (500.22(d)(4)) | November 1, 2025 |

All three periods have ended, so the amended 500.7 and 500.12 apply in full.

## Where shared logins strain the rule

Part 500 doesn't mention shared accounts. Several of its duties are harder to meet when one login serves several people.

- Prompt removal (500.7(a)(6)): you can't switch off one person's access to a shared login. Your lever is a new password for everyone else, and until then the person who left can still sign in.
- Job-based limits (500.7(a)(1)): everyone on a shared login gets the same access, whatever each job needs.
- The annual review (500.7(a)(4)): a list of accounts doesn't show who uses a shared one, so you need a separate record of the people behind it.

A practical starting point is a list of every system and cloud service that holds nonpublic information. For each account, note who uses it, whether it's privileged, and whether more than one person signs in with it. That list feeds the annual review in 500.7(a)(4) and the asset inventory that 500.13 now requires. For more on keeping track of shared logins, see [How to take inventory of shared accounts and what to record](/guides/shared-accounts/shared-account-inventory).


## Frequently asked questions

**Does Part 500 apply to my company?**

It applies to covered entities, meaning anyone operating under a license, registration, charter or similar authorization under New York's Banking, Insurance or Financial Services Law, even if other regulators also oversee them.

**Do small covered entities still have to follow 500.7?**

Yes. The limited exemption in 500.19(a) doesn't list 500.7. For MFA, those entities still need it for remote access, remote access to cloud and other third-party apps, and privileged accounts.

**How often must we review access?**

Periodically, and at least once a year under 500.7(a)(4). The review removes or disables accounts and access that are no longer needed.

**Are shared accounts banned under Part 500?**

The text doesn't mention shared accounts. It does require access limited to each user's job, prompt removal when people leave, and MFA under 500.12, so a shared login has to meet all three.

## Sources

- [NY DFS: Second Amendment to 23 NYCRR 500, Cybersecurity Requirements for Financial Services Companies (adopted text, November 1, 2023)](https://www.dfs.ny.gov/system/files/documents/2023/10/rf_fs_2amend23NYCRR500_text_20231101.pdf)

## How Junify handles this

**Doing this by hand** You map each requirement to how your team actually works. You keep a record an auditor can review: which accounts exist, who may use each one, and who used it. And you reread the rules each time they change.

**With Junify** Junify takes the departure step off shared logins. Change the password at setup so only Junify holds it, and people sign in without ever seeing it. When someone leaves, remove their access and they can't open the account through Junify again, with no new password to hand out. People verify on their own phone each time, and Junify records who used which account and when, person by person, for your annual access review.

Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when.

- [Try the demo](https://www.junify.com/bpo/try?lang=en&from=guide&cluster=compliance&slug=nydfs-part-500-access-privileges)
- [Book a 30-minute demo](https://www.junify.com/bpo/demo)

## More on this topic

- [What access logs need to show when you decide whether to report a breach](/guides/compliance/breach-notification-access-logs): Logs show whether data was viewed, by whom, for how many people and since when. HIPAA presumes a breach unless you can show a low probability of compromise.
- [Password sharing and the federal anti-hacking law (CFAA)](/guides/compliance/cfaa-password-sharing): The CFAA turns on whether the system's owner allowed the access. In Nosal, former employees using a current employee's login acted without authorization.
- [What CIS Controls 5 and 6 (v8.1) ask of your accounts](/guides/compliance/cis-controls-account-access-management): Control 5 asks for an account inventory, disabled dormant accounts and separate admin accounts. Control 6 covers granting and revoking access, and MFA.