Privileged Access Management Under NYDFS: Meeting the New Access-Governance Bar

The amended NYDFS Part 500 does not use the words “just-in-time,” but read Section 500.7 honestly and that is where it points. Most firms are still running standing administrator rights the rule no longer tolerates.

The access-privileges provisions of the amended 23 NYCRR Part 500 took effect on 1 May 2025, eighteen months after the Second Amendment was adopted. They are short. They are also more demanding than they look, because they stop describing access as a state you configure once and start describing it as something you have to limit, justify, review and prove on a cycle. That is an architectural shift, not a policy edit, and it is one many covered entities have not actually built.

What 500.7 actually requires

Strip the section to its operative verbs and Section 500.7(a) asks a covered entity to do five things. Limit user access to the nonpublic information needed to do the job. Limit the number of privileged accounts, and limit what those accounts can do, to what the role requires. Limit the use of privileged accounts to only when a function actually needs that access. Review all access privileges periodically, at least annually, and remove or disable what is no longer necessary. Disable or securely configure the protocols that permit remote control of devices, and terminate access promptly when people leave.

Read the third of those again. “Limit the use of privileged accounts to only when performing functions requiring the use of such access” is not a statement about who holds an account. It is a statement about when the privilege is live. A domain administrator who holds elevated rights twenty-four hours a day is, for all but a few minutes of that day, holding access no current function requires. Standing privilege is the default posture in most estates, and it is the posture this sentence is written against.

Class A companies carry an extra weight under 500.7(c): implement a privileged access management solution, and automatically block commonly used passwords, or document a CISO-approved compensating control each year. A Class A company here means, broadly, one with over 20 million dollars in New York gross annual revenue across the last two fiscal years and either more than 2,000 employees on average or over a billion dollars in gross annual revenue, affiliates included. If that is you, the tooling is no longer optional and the review is no longer a spreadsheet someone updates the night before an examination.

Why standing privilege is the thing to kill first

The failure mode a supervisor and an attacker both look for is the same: a population of accounts that can do damage at any moment, held by people who mostly are not using them. Every one of those accounts is a credential to be phished, a session to be hijacked, a lateral-movement path. The rule’s instinct is correct. If a privilege only needs to exist for the ten minutes an engineer is running a migration, then existing for the other twenty-three hours and fifty minutes is pure risk with no offsetting benefit.

The architectural answer is to make elevation a transaction rather than a status. Nobody holds standing admin. An engineer requests elevation against a specific target, for a specific reason, for a bounded time; a broker checks the request against policy, grants a short-lived credential, records the session, and revokes on expiry. This is just-in-time access, and it is the cleanest way to satisfy “only when performing functions requiring the use of such access” without asking humans to remember to hand privileges back. It also produces, as a by-product, exactly the evidence the rest of 500.7 wants: a log of who was elevated, to what, when, why, and for how long.

This is the same terrain as the audit finding you will get on privileged access, and it connects directly to how you hold the secrets those short-lived credentials are minted from. Deciding where that material lives is, as I have argued, a governance decision rather than a tooling one.

The pattern, expressed as policy

The reason to express the access model as policy-as-code rather than as tickets and runbooks is that the amendment asks you to prove the model operates, not merely that it exists. A declarative policy is enforced by the broker and is itself the documentation of intent. When an examiner asks how privileged elevation is governed, you show the file and the grant log it produced. The following is a minimal, broker-agnostic policy for a just-in-time grant with a bounded lifetime, mandatory approval for the highest tier, session recording, and an embedded review cadence.

# jit-access-policy.yaml
# Just-in-time privileged access, matched to 23 NYCRR 500.7(a)

roles:
  db-admin-prod:
    description: Elevated access to production database hosts
    target: prod/db/*
    standing_privilege: false          # no persistent admin rights
    grant:
      max_ttl_minutes: 30              # revoked automatically on expiry
      justification_required: true     # "reason" captured on every request
      approval:
        required: true
        approvers: [platform-lead, security-on-call]
      session_recording: true          # evidence of what was done
    review:
      cadence: quarterly               # exceeds the annual 500.7 minimum
      reviewer: head-of-infrastructure
      action_on_stale: disable         # remove access no longer necessary

  read-only-analyst:
    description: Standing read access to non-privileged reporting
    target: reporting/readonly/*
    standing_privilege: true
    review:
      cadence: annual
      reviewer: data-governance-lead
      action_on_stale: disable

global:
  remote_control_protocols: deny_by_default   # 500.7(a): disable or securely configure
  terminate_on_offboarding: true              # prompt removal on departure
  audit_log: append_only                      # tamper-evident grant record

The value here is not the syntax; your broker will have its own. The value is that each clause maps to a sentence in the rule, and each grant it issues is an audit record you did not have to assemble by hand. max_ttl_minutes is the bounded-privilege requirement. action_on_stale: disable is the periodic-review requirement made automatic. remote_control_protocols: deny_by_default is the protocol clause. The policy is the control and the evidence at once.

The review is the part that gets failed

Firms tend to invest in the grant path and neglect the review path, and it is the review path a supervisor tests. “Periodically, but at a minimum annually” is a floor, not a target, and an annual access recertification that rubber-stamps an exported list of accounts satisfies the letter and misses the point. A review that means something asks, per account and per entitlement, whether the access is still necessary, and disables what is not, and leaves a record of the decision and who made it. If your recertification cannot produce, for a named account, the evidence that a human looked at it on a date and decided to keep or remove it, you have a process a regulator will treat as decorative.

Sequence the move accordingly. Inventory privileged accounts and what each can reach. Move the highest-blast-radius roles to just-in-time first, leaving genuinely standing low-risk access alone. Wire the grant log into your evidence store. Then make the review consume that log, so recertification reasons about actual usage rather than a static entitlement dump. This is the same discipline the MFA and asset-inventory duties that followed on 1 November 2025 demand: not a control that exists, but a control that produces its own proof of operation.

The uncomfortable truth is that most estates already fail 500.7 not because they lack a PAM product but because privilege in them is a status somebody was granted years ago and nobody has revisited since. The rule has quietly made that arrangement indefensible. Elevation now has to be something you can watch happen, time-box, and switch off.