TL;DR: NYDFS’s 2023 amendment to Section 500.7 now requires Class A companies to implement a privileged access management solution and automatically block common passwords for system accounts, while all covered entities must limit privilege, review access annually, and terminate access promptly, according to StrongDM. The compliance problem is no longer access policy in the abstract, but whether privilege is actually constrained, reviewed, and removed in time.
NHIMG editorial — based on content published by StrongDM: How to Meet NYDFS Section 500.7 Amendment Requirements
By the numbers:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should organisations apply least privilege to privileged access in regulated environments?
A: Map every privileged entitlement to a specific job function, system, or data domain, then remove any access that cannot be justified.
Q: Why do standing privileged accounts create compliance and security risk?
A: Standing privileged accounts keep high-risk access available even when no task requires it.
Q: How do you know if just-in-time access is actually working?
A: JIT is working when privilege is granted only for an active task, automatically expires at task completion, and cannot be reused outside the approved window.
Practitioner guidance
- Inventory privileged access paths Build a complete register of human and non-human accounts that can administer systems, access nonpublic information, or bypass normal controls.
- Enforce just-in-time privilege Require privileged access to be provisioned only for the task at hand and expired automatically when the task ends.
- Automate recertification into offboarding Make access review outputs trigger removal of unnecessary access, especially after departures or role changes.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- A breakdown of how StrongDM maps its platform to NYDFS Section 500.7 access privilege requirements.
- The specific PAM and JIT access workflows StrongDM says support privilege removal and review.
- The article's own summary table showing how each amendment requirement maps to a corresponding control.
- Guidance on how the vendor frames compliance for Class A companies and broader covered entities.
👉 Read StrongDM's guide to NYDFS Section 500.7 access management requirements →
NYDFS section 500.7 and PAM: what IAM teams need to enforce?
Explore further
Section 500.7 turns privilege governance into an evidence problem, not a policy problem. The amendment is explicit that access must be limited, reviewed, and terminated, which means auditors will look for proof that privilege is bounded in practice. That shifts the burden from documenting a control to demonstrating that the control actually changes exposure. Practitioners should treat privilege evidence as a first-class governance artefact.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when privileged access is not removed after departure?
A: Accountability should sit with the access owner, the system owner, and the offboarding process owner, because failure to remove access is a lifecycle control gap, not just an IT issue. In regulated environments, the organisation must be able to prove that departure triggers access removal across all relevant systems.
👉 Read our full editorial: NYDFS section 500.7 now ties access governance to PAM