Regulators now write privileged access rules into the text itself, but each regime sets different review cycles, authentication rules and expectations for tooling, so one PAM programme has to satisfy several masters at once. PCI DSS sets six-monthly account reviews and strict rules for system and application accounts; DORA's ICT risk management standard asks for six-monthly reviews on systems behind critical or important functions and automated privileged access management where feasible; NYDFS Part 500 requires larger firms to run a PAM solution and monitor privileged activity; the NIS2 technical measures regulation demands dedicated admin accounts and separate admin systems; APRA guidance expects stronger monitoring and multi-factor authentication. This map sets them side by side so PAM owners, GRC teams and auditors can build one control set and one evidence pack. Status as of 12 November 2026.
Source note: this map summarises official texts, regulator guidance and the sources listed at the end, with status as of 12 November 2026. It is not legal advice. Confirm against the official text before relying on it.
Key takeaways
- Review cycles differ and the shortest wins. PCI DSS 7.2.4 and DORA RTS Article 21 for critical or important functions both set at least every six months; NYDFS 500.7 sets at least annually; NIS2 and APRA leave the interval to you but expect it planned and documented.
- Service accounts are privileged accounts. NYDFS defines a privileged account to include service accounts, and PCI DSS 8.6 and 7.2.5 bring system and application accounts under named controls, including a ban on hard-coded passwords.
- MFA for privileged access is close to universal. NYDFS 500.12, DORA RTS Article 21, NIS2 Annex 11.3, PCI DSS 8.4 and APRA CPG 234 all expect strong or multi-factor authentication for administrative access.
- Some regimes name the tooling. NYDFS 500.7(c) requires Class A companies to implement a privileged access management solution, and DORA asks for automated PAM where feasible and appropriate; others describe outcomes only.
- Separation is now explicit. NIS2 Annex 11.3 and 11.4 require dedicated admin accounts that connect only to administration systems kept logically separate from everyday applications.
Regulations and frameworks at a glance
| Regime | Who it applies to | Core privileged access rule | Review cycle | Authentication | Status (12 November 2026) |
|---|---|---|---|---|---|
| PCI DSS v4.0.1, Requirements 7, 8 and 10 | Entities that store, process or transmit cardholder data | Least privilege for all accounts; shared accounts only by exception (8.2.2); system and application accounts controlled (8.6.1 to 8.6.3) | User accounts at least every six months (7.2.4); application and system accounts at a frequency set by targeted risk analysis (7.2.5.1) | MFA for non-console administrative access into the cardholder data environment (8.4.1) and for all non-console access into it (8.4.2) | In force; former future-dated requirements apply since 31 March 2025 |
| NYDFS 23 NYCRR 500.7 and 500.12 | NYDFS-regulated covered entities | Limit the number and functions of privileged accounts and use them only when needed; Class A: PAM solution, privileged activity monitoring, common password blocking | At least annually | MFA for all privileged accounts other than service accounts that prohibit interactive login | Amended 500.7 compliance due 1 May 2025; amended 500.12 due 1 November 2025 |
| EU DORA RTS on ICT risk management, Commission Delegated Regulation (EU) 2024/1774, Articles 20 and 21 | EU financial entities under the full ICT risk framework | Privileged, emergency and administrator access on a need-to-use or ad hoc basis; dedicated admin accounts where possible; automated PAM where feasible and appropriate | At least every six months for systems supporting critical or important functions; at least once a year for other systems | Strong authentication for privileged access, remote access and critical or publicly accessible assets | Applies alongside DORA since 17 January 2025 |
| NIS2 Implementing Regulation (EU) 2024/2690, Annex section 11 | DNS, TLD, cloud, data centre, CDN, managed service and managed security service providers, online marketplaces, search engines, social networks and trust service providers | Dedicated admin accounts, individualised and restricted privileges, admin accounts only on admin systems | At planned intervals | Strong identification and authentication such as MFA for privileged accounts; separate credentials | Applies |
| APRA CPS 234 with CPG 234 guidance | APRA-regulated entities in Australia | CPS 234 sets information security controls; CPG 234 describes least privilege, heightened monitoring of privileged accounts and a two-person rule for the most sensitive assets | Regular reviews by information asset owners | MFA for privileged access, remote access and other high-risk activities (CPG 234) | CPS 234 in force; CPG 234 is guidance and not enforceable on its own |
For how to design and run the programme itself, see the Privileged Access Management Guide. For testing obligations across the same regimes, see the Penetration Testing Requirements Map.
Scope: which accounts count as privileged
The definition decides how many accounts fall into scope.
- NYDFS 500.1: a privileged account is any authorised user account or service account that can perform security-relevant functions ordinary users cannot, including adding, changing or removing accounts or changing system configuration. Service accounts are in by definition.
- DORA RTS Article 21: names privileged, emergency and administrator access, covering break-glass accounts as well as day-to-day admins, across all ICT systems.
- NIS2 Annex 11.3: covers privileged accounts and system administration accounts, and 11.5 requires every identity, for users and for systems, to be unique and managed through its lifecycle.
- PCI DSS: distinguishes user accounts (7.2.4), shared or generic accounts (8.2.2) and system and application accounts (7.2.5, 8.6), and treats administrative access into the cardholder data environment separately for MFA.
- APRA CPG 234: refers to privileged users and to special purpose system accounts, and accepts shared generic accounts only where technology constraints make them unavoidable.
The practical answer is to classify any human or machine identity that can change security settings, other accounts or production configuration as privileged, then apply the strictest rule below. The Privileged Account Discovery and Onboarding Guide covers how to find them.
Key obligations by control area
Least privilege and need-to-use assignment
| Regime | Requirement |
|---|---|
| PCI DSS 7.2.5 | Application and system accounts receive only the privileges needed to operate, limited to the systems and processes that need them |
| NYDFS 500.7(a)(2) and (3) | Limit the number of privileged accounts and their access functions to what the job requires; use them only for functions that need elevated access |
| DORA RTS Art. 21(e)(ii) | Privileged, emergency and administrator access assigned on a need-to-use or ad hoc basis |
| NIS2 IR Annex 11.2 and 11.3 | Need-to-know, least privilege and separation of duties; privileges individualised and restricted as far as possible |
| APRA CPG 234 Attachment A | Access limited to the minimum required to achieve business objectives |
DORA's "ad hoc" wording and NYDFS's "only when performing functions that need it" both point towards just-in-time elevation rather than standing admin rights. See the Privileged Identity Management (PIM) Guide.
Dedicated accounts and administration systems
- NIS2 Annex 11.3 and 11.4: dedicated accounts used only for administration, connecting only to administration systems; those systems used only for administration, logically separated from non-admin applications and protected by authentication and encryption.
- DORA RTS Article 21: dedicated accounts for administrative tasks on ICT systems where possible.
- PCI DSS 8.2.2: shared or generic accounts used only when necessary, on an exception basis, with documented justification and management approval, and with individual accountability preserved.
- DORA RTS Recital 14 and NIS2 Annex 11.5: generic or shared identities only exceptionally, with explicit approval and documentation.
See the Privileged Access Workstations Guide.
Authentication
- NYDFS 500.12: MFA for any individual accessing information systems; even entities with the limited exemption must use MFA for remote access and for all privileged accounts other than service accounts that prohibit interactive login. A CISO may approve reasonably equivalent compensating controls in writing, reviewed at least annually.
- DORA RTS Article 21(f)(ii): strong authentication in line with leading practices for remote access, privileged access, access to assets supporting critical or important functions and publicly accessible assets.
- NIS2 Annex 11.3, 11.6 and 11.7: strong authentication such as MFA for privileged accounts, separate credentials for privileged accounts, lockout after repeated failures and timeouts for inactive sessions.
- PCI DSS 8.4.1 and 8.4.2: MFA for all non-console administrative access into the cardholder data environment, and for all non-console access into it.
- APRA CPG 234 Attachment C: MFA for privileged access, remote access and other high-risk activities.
Machine and service accounts
| Regime | Rule for system, application or service accounts |
|---|---|
| PCI DSS 8.6.1 | Interactive login prevented unless needed for an exceptional circumstance, time-limited, justified, approved by management and attributable to an individual |
| PCI DSS 8.6.2 | Passwords for accounts capable of interactive login not hard-coded in scripts, configuration or property files, or custom source code |
| PCI DSS 8.6.3 | Passwords changed periodically at a risk-analysis frequency and on suspected or confirmed compromise, with complexity suited to that frequency |
| PCI DSS 7.2.5.1 | Access of application and system accounts reviewed at a risk-analysis frequency, with management acknowledgement |
| NYDFS 500.1 and 500.12 | Service accounts are privileged accounts; the MFA exception applies only to service accounts that prohibit interactive login |
| DORA RTS Article 20 | Unique identification and authentication of systems as well as people, with lifecycle management automated where feasible |
| NIS2 IR Annex 11.5 | Lifecycle management of identities for systems and users; unneeded identities deactivated without delay |
Vaulting and rotation are the usual way to meet these rules. See the How to detect interactive logons by service accounts guide for the PCI DSS 8.6.1 evidence.
Monitoring and logging
- NYDFS 500.7(c): Class A companies must monitor privileged access activity.
- DORA RTS Article 12(2)(c) and (d): logging covers access control and identity management, and logs are protected against tampering, deletion and unauthorised access.
- NIS2 Annex 11.2 and 11.5: management of access rights and of identities is logged.
- PCI DSS 10.2.1.2: audit logs capture all actions taken by anyone with administrative access.
- APRA CPG 234: privileged accounts subject to a greater level of monitoring given the heightened risk.
Review and removal
| Regime | Review interval | Removal |
|---|---|---|
| PCI DSS | User accounts at least every six months (7.2.4); system and application accounts per targeted risk analysis (7.2.5.1) | Inappropriate access corrected; management acknowledges the review |
| NYDFS | At least annually (500.7(a)(4)) | Remove or disable unneeded access; promptly terminate on departure |
| DORA RTS | Six months for critical or important function systems; yearly for others | Withdrawn without undue delay on termination or when no longer needed |
| NIS2 IR | Privileged accounts at planned intervals (11.3.3) | Unneeded identities deactivated without delay (11.5.4) |
| APRA CPG 234 | Regular reviews by information asset owners | Timely removal on role change or exit |
Emergency access and segregation
DORA RTS Article 21 is the only text here that names emergency access, placing it under the same need-to-use rule. APRA CPG 234 suggests a two-person rule for the highest sensitivity assets, and NIS2 Annex 11.2 requires separation of duties. See the Break-Glass Account Guide and the Dual control and four-eyes approval guide.
Timeline and current status
- 1 July 2019: APRA CPS 234 takes effect; CPG 234 guidance dated June 2019.
- 1 November 2023: second amendment to NYDFS Part 500 takes effect.
- 17 January 2025: DORA applies, with the ICT risk management RTS (EU) 2024/1774.
- 31 March 2025: PCI DSS v4 future-dated requirements, including 7.2.5, 7.2.5.1, 8.4.2 and 8.6.1 to 8.6.3, become mandatory.
- 1 May 2025: amended NYDFS 500.7 compliance date, including the Class A PAM and monitoring duties.
- 1 November 2025: amended NYDFS 500.12 MFA compliance date.
The NIS2 implementing regulation entered into force on the twentieth day after its publication in the Official Journal in October 2024. Watch the NIS2 Amending Directive Proposal 2026 for changes to scope.
Enforcement and penalties
None of these texts carries a fine specific to privileged access; failures are judged under each regime's wider enforcement. PCI DSS gaps appear in the Report on Compliance and can lead to acquirer action. NYDFS treats a missing control as a violation of Part 500, and the annual certification makes a senior officer attest to compliance; see the NYDFS Part 500 Annual Certification Checklist. DORA and NIS2 failures fall under national penalty regimes for ICT risk and cyber risk management.
What it means for AI agents and non-human identities
- Agents that can change configuration are privileged accounts: under the NYDFS definition an agent or automation identity that can add accounts or change systems is in scope, so it needs least privilege, review and monitoring like a human admin.
- Interactive login is the dividing line for MFA: NYDFS exempts only service accounts that prohibit interactive login, and PCI DSS 8.6.1 blocks interactive use. Enforce non-interactive logon for machine identities and alert on any interactive session. See the How to Find Accounts Excluded From MFA and Conditional Access guide.
- No hard-coded secrets: PCI DSS 8.6.2 rules out passwords in scripts and configuration; pipeline and agent credentials should come from a vault at runtime.
- Unique system identities: DORA Article 20 and NIS2 Annex 11.5 require systems to have unique identities, which rules out one shared automation account across many workloads.
Decision guidance
| Situation | Approach | Trade-off |
|---|---|---|
| PCI DSS only, small estate | Six-monthly user reviews, MFA into the cardholder data environment, vault for system account passwords | Low tooling cost, but manual reviews and rotation need discipline |
| Payments or banking group under PCI DSS, DORA and NYDFS | Single PAM platform with just-in-time elevation, session logging and six-monthly certification for critical systems, annual for the rest | Higher cost, but one evidence pack satisfies all three |
| NYDFS standard (not Class A) company | Meet 500.7(a) and 500.12 with directory roles, MFA and annual review; plan for PAM if growth crosses Class A thresholds | Lighter now, migration later if thresholds are met |
| Cloud or managed service provider under NIS2 | Tiered admin model with separate admin workstations, individual admin accounts and documented review intervals | Operational friction for engineers; strong evidence for auditors |
| APRA-regulated entity | Use CPG 234 as the control baseline, including heightened monitoring and two-person rules for crown jewels | Guidance gives flexibility, but APRA expects justification where you depart from it |
- Calendar or risk-based reviews: use the six-month cycle as the default for anything shared across regimes; it meets PCI DSS 7.2.4, DORA for critical systems and the annual NYDFS floor at once.
- Small versus large organisations: NYDFS ties the PAM solution duty to Class A size, DORA says "where feasible and appropriate", and NIS2 scales by risk. Smaller firms can meet outcomes with native cloud and directory features, but must still show monitoring and review.
Compliance steps
- Build the obligations register: list which regimes apply by entity, system and contract.
- Inventory privileged identities: human admins, emergency accounts, service accounts, automation and agent identities, using the NYDFS definition as the widest net. See the Privileged Account Inventory Template.
- Tag systems by criticality: mark systems supporting critical or important functions (DORA) and cardholder data environment systems (PCI DSS) to drive review cycles.
- Enforce authentication: MFA for all interactive privileged access; block interactive logon for service accounts and document any exception.
- Separate administration: dedicated admin accounts and admin workstations; remove standing admin rights where just-in-time works.
- Vault and rotate: move system account credentials out of code and configuration; set rotation frequency through a documented risk analysis.
- Monitor and log: record privileged sessions and admin actions, protect logs from tampering and alert on unusual use.
- Review and attest: run access certifications at the strictest interval, record management sign-off and keep the evidence for each audit cycle.
Measuring it
- Standing privilege: share of admin rights held permanently rather than granted just in time.
- MFA coverage: percentage of interactive privileged accounts protected by MFA, target 100 percent.
- Review completion: certifications completed within the required interval per regime.
- Vault coverage: percentage of service and system accounts whose credentials are vaulted and rotated.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management; AC-6 Least Privilege; AC-6(5) Privileged Accounts; AC-6(7) Review of User Privileges; AC-6(9) Log Use of Privileged Functions; IA-2(1) Multi-factor Authentication to Privileged Accounts | Control baseline that most regime requirements map onto |
| NIST CSF 2.0 | PR.AA-03 Users, services and hardware are authenticated; PR.AA-05 Access permissions are managed with least privilege and separation of duties | Outcomes for the programme |
| CIS Controls v8.1 | 5.4 Restrict administrator privileges to dedicated administrator accounts; 6.5 Require MFA for administrative access | Safeguards matching NIS2 and DORA dedicated account rules |
| ISO/IEC 27001:2022 | Annex A 8.2 Privileged access rights; 5.18 Access rights | Controls auditors map PAM evidence to |
Common failure patterns
- Service accounts left out of scope: reviews and MFA cover human admins only, despite the NYDFS definition and PCI DSS 8.6.
- Annual reviews on critical systems: a yearly cycle applied everywhere misses the six-month rule under PCI DSS 7.2.4 and DORA for critical or important functions.
- Admin from everyday devices: administrators browse and read email from the same session they administer from, contrary to NIS2 Annex 11.4.
- Shared admin accounts without justification: generic accounts kept for convenience without the documented exception PCI DSS 8.2.2 and NIS2 11.5 require.
- Rubber-stamp certifications: reviews signed without removing anything, which gives evidence on paper but not least privilege.
Practitioner checklist
- Define privileged accounts to include service, automation and agent identities.
- Keep a register of privileged access obligations by entity and system.
- Review privileged access at least every six months on critical and cardholder systems.
- Require MFA for every interactive privileged session.
- Block interactive logon for service accounts and document exceptions.
- Use dedicated admin accounts on separate administration systems.
- Vault system account credentials and remove them from code.
- Log privileged actions and protect the logs from tampering.
Standards and references
- 23 NYCRR 500.7: Access privileges and management
- 23 NYCRR 500.12: Multi-factor authentication
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk management RTS)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 technical measures)
- APRA: Prudential Practice Guide CPG 234 Information Security
- NYDFS: Cybersecurity Requirements by entity type
- NIST: SP 800-53 Rev. 5
- Schellman: PCI DSS service account requirements
This guide summarises privileged access requirements as of 12 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Privileged Access Management Guide · PCI DSS 4.0 Guide · DORA ICT Risk Management Framework Guide · NYDFS Part 500 Guide · Identity Security Regulatory Map