Service accounts, API keys and other machine credentials sit inside almost every regulated system, but only a few rules name them, so teams often assume the identity requirements they apply to people do not reach them. They do. PCI DSS has dedicated requirements for system and application accounts; the DORA and NIS2 technical acts require identity management for "systems" as well as people; NYDFS counts service accounts as privileged accounts; HIPAA's access control standard covers "software programs"; and SOX auditors test access to programs as part of IT general controls. This map puts those obligations side by side for the machine identity: inventory and ownership, least privilege, shared and interactive use, credential storage and rotation, review and logging. It is for IAM and NHI programme owners, GRC leads and auditors. Status as of 12 November 2026. Cryptographic key life cycle rules are covered in the Encryption and Key Management Requirements Map and not repeated here.
Source note: this map summarises official texts and the sources listed at the end, with status as of 12 November 2026. PCI DSS requirement summaries are based on published QSA analysis because the PCI SSC standard document requires sign-in to download. It is not legal advice. Confirm against the official text before relying on it.
Key takeaways
- Machines are in scope even where unnamed. DORA's RTS requires "the unique identification and authentication of natural persons and systems"; the NIS2 Implementing Regulation requires managing "the full life cycle of identities for systems and users"; HIPAA limits access to "persons or software programs" with access rights.
- PCI DSS is the most specific. Requirements 7.2.5, 7.2.5.1 and 8.6.3 apply to all system and application accounts; 8.6.1 and 8.6.2 add controls where such an account can be used for interactive login, including no hard-coded passwords.
- Service accounts can be privileged accounts. NYDFS 23 NYCRR 500.1(n) defines a privileged account as "any authorized user account or service account" that can perform security-relevant functions, bringing them under 500.7 limits and annual review.
- Review cycles are written down. DORA requires access rights reviews at least annually and every six months for systems supporting critical or important functions; PCI DSS sets frequency by targeted risk analysis.
- Shared accounts need an exception. DORA Article 21, NIS2 Annex 11.5.3 and PCI DSS 8.2.2 all limit shared or generic accounts and require accountability for actions taken through them.
Regulations and frameworks at a glance
| Rule | Who it applies to | What it says about machine identities | Status (12 November 2026) |
|---|---|---|---|
| PCI DSS v4.0.1, Requirements 7.2.5, 7.2.5.1, 8.2.2, 8.6.1 to 8.6.3 | Entities that store, process or transmit cardholder data, and service providers | Least privilege for system and application accounts; periodic access review; interactive use prevented unless exceptional; no hard-coded passwords; password change by targeted risk analysis and on compromise | In force; former future-dated requirements mandatory since 31 March 2025 |
| EU DORA RTS, Delegated Regulation (EU) 2024/1774, Articles 20 and 21 | EU financial entities under the full ICT risk framework | Unique identification of persons and systems; identity and account life cycle; limit generic and shared accounts; review at least yearly, six months for critical or important functions | Applies since 17 January 2025 |
| EU NIS2 Implementing Regulation (EU) 2024/2690, Annex section 11 | Digital infrastructure and digital providers named in the Regulation; a common reference for other NIS2 entities | Policies cover people and systems; full life cycle for system identities; shared identities only with approval; protect secret authentication information; change credentials on compromise | In force since 7 November 2024 |
| New York 23 NYCRR 500.1(n) and 500.7 | DFS-licensed covered entities | Service accounts that can perform security-relevant functions are privileged accounts; limit number and functions; annual review; Class A: PAM and common password blocking for all accounts | In force (amended November 2023) |
| US HIPAA Security Rule, 45 CFR 164.312 | Covered entities and business associates | Access only for persons or software programs with access rights; unique identification (Required); audit controls; person or entity authentication | In force |
| SOX Section 404 with PCAOB AS 2201 | US-listed companies and their auditors | No machine identity text; auditors rely on IT general controls, including "access to programs", so service accounts with access to financial systems are tested | In force |
| NIST SP 800-53 Rev. 5 (US federal systems, FedRAMP) | Federal systems and cloud services authorised for them | IA-9 Service Identification and Authentication; IA-5(7) No Embedded Unencrypted Static Authenticators; AC-2 account management | Current control catalogue |
GDPR Article 32 and similar privacy laws require appropriate security without naming accounts, and regulators judge credential handling under that test. For multifactor rules see the MFA Mandates Map; for privileged access controls see the Privileged Access Management Guide.
Inventory, identity and ownership
Every regime starts from knowing which identities exist and who answers for them.
| Requirement | DORA RTS | NIS2 IR Annex | PCI DSS | HIPAA |
|---|---|---|---|---|
| Unique identity | Art. 20: unique identification and authentication of persons and systems | 11.5.2: identities unique and logged | 8.2.2 limits shared and generic accounts | 164.312(a)(2)(i): unique name or number (Required) |
| Life cycle | Art. 20: creation, changes, review, temporary deactivation, termination; automated where feasible | 11.5.1: full life cycle for systems and users; 11.5.4 deactivate when no longer needed | 7.2.5.1: periodic review of system and application account access | 164.308(a)(4) access management (cross-referenced in 164.312(a)(1)) |
| Records | Art. 20: records of identity assignments kept after reorganisation or contract end | 11.2.2(e): register of access rights; (f) logging of rights management | Documented justification for interactive use (8.6.1) | Audit controls (164.312(b)) |
In practice this means an NHI inventory with a named human owner, purpose, system, credential type and last use for every service account, API key, token and certificate. CIS Controls v8.1 Safeguard 5.5 asks for the same inventory of service accounts. See the NHI Inventory Reconciliation guide and How to assign owners to orphaned service accounts.
Least privilege, shared and interactive use
- Least privilege: PCI DSS 7.2.5 limits system and application accounts to the privileges and systems they need. DORA Article 21 uses "need-to-know, need-to-use and least privilege"; NIS2 Annex 11.2.2 uses need-to-know, least privilege and separation of duties.
- Privileged machine accounts: under NYDFS a service account that can add, change or remove accounts or change configuration is a privileged account, so 500.7(a)(2) and (3) limits apply. NIS2 Annex 11.3 requires separate policies for privileged and system administration accounts, with strong authentication such as multifactor and dedicated admin accounts.
- Shared accounts: DORA Article 21 requires limiting "the use of generic and shared user accounts" with users identifiable for actions at all times (Recital 14 accepts them exceptionally with accountability); NIS2 Annex 11.5.3 allows shared identities only where necessary, with explicit approval and documentation.
- Interactive use: PCI DSS 8.6.1 states "Interactive use is prevented unless needed for an exceptional circumstance", with time limits, documented justification, management approval, confirmed individual identity and attributable actions. See How to detect interactive logons by service accounts.
The Cloudflare Thanksgiving breach shows why privilege matters: a Smartsheet service account with administrative access to Jira, left unrotated after the Okta incident, gave the attacker the rights to install tooling. Integration accounts rarely need admin rights.
Credentials and secrets: storage and rotation
| Control | PCI DSS | NIS2 IR Annex | DORA RTS | NIST SP 800-53 |
|---|---|---|---|---|
| No credentials in code or config | 8.6.2: passwords for interactive-capable system and application accounts not hard-coded in scripts, configuration or property files, or bespoke source code | 11.6.2(b): protect secret authentication information | Art. 21: authentication methods matched to classification and risk | IA-5(7) No Embedded Unencrypted Static Authenticators |
| Rotation | 8.6.3: change per targeted risk analysis and on suspected or confirmed compromise; complexity suited to change frequency | 11.6.2(c): change at first use, at set intervals and on suspected compromise | Art. 21: strong authentication for privileged and remote access | IA-5 Authenticator Management |
| Separate privileged credentials | 7.2.5 scope limits | 11.6.2(f): separate credentials for privileged or administrative accounts | Art. 21: dedicated accounts for administrative tasks where possible | AC-6 Least Privilege |
| Service authentication | 8.6.x apply to all system and application accounts | 11.6.3: state-of-the-art methods, unique authentication information | Art. 20: authentication of systems | IA-9 Service Identification and Authentication |
No rule mandates a specific rotation period for machine credentials: PCI DSS and NIS2 tie it to risk analysis and compromise. Short-lived, federated credentials (workload identity federation, managed identities, gMSA) satisfy the intent better than long-lived secrets rotated on a calendar, and leave no static secret to hard-code. The Cloudflare breach also shows the compromise trigger in action: credentials judged "unused" and not rotated after a supplier breach were the way back in. See the Secrets Management Guide and the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6).
Review, logging and audit evidence
| Rule | Review requirement | Logging requirement | Evidence an auditor asks for |
|---|---|---|---|
| PCI DSS | 7.2.5.1: periodic review of system and application account access, frequency by targeted risk analysis, with management acknowledgement | Requirement 10 audit logs | Review records per account; risk analysis setting frequency; approvals for interactive use |
| DORA RTS | Art. 21: at least yearly; every six months for systems supporting critical or important functions | Art. 12 logging covers access control and identity management | Review cycles by system criticality; identity assignment records |
| NIS2 IR | 11.2.3 and 11.3.3: planned intervals, results documented; 11.5.4 regular identity review | 3.2.3(e): log privileged access and administrative account activity | Register of access rights; documented review results |
| NYDFS | 500.7(a)(4): review all access privileges at least annually; remove or disable unneeded accounts | 500.7(c): Class A monitors privileged access activity | Annual review evidence including service accounts |
| HIPAA | Access management under 164.308(a)(4) | 164.312(b): record and examine activity | Access lists for systems with ePHI; audit log reviews |
| SOX (PCAOB AS 2201) | ITGC testing of access to programs and data | As defined by the ITGC design | Service accounts with access to in-scope financial applications, their owners and change rights |
The Dropbox Sign breach involved a non-human back-end account with production privileges that reached the customer database, including API keys and OAuth tokens. Review and monitoring of that kind of account is exactly what these rules expect. See How to Run an Access Review for Service Accounts.
What it means for AI agents
AI agents authenticate with the same machine credentials: service principals, API keys, OAuth tokens. None of these rules exempt them. An agent with access to cardholder data is a system or application account under PCI DSS; an agent operating in a DORA entity needs a unique system identity, a life cycle record and a review cycle matched to the criticality of what it touches. Shared agent credentials fail the same shared account tests as human ones. See the AI Agents and PCI DSS guide.
Compliance steps
- Map rules to systems: tag each system with the regimes that apply (cardholder data, ePHI, DORA critical or important function, NYDFS, SOX in-scope).
- Build the inventory: every service account, key, token and certificate with owner, purpose, privilege level, interactive capability and last use.
- Classify privilege: flag machine identities that meet the NYDFS privileged account definition or NIS2 system administration scope.
- Remove interactive capability: deny interactive logon for service accounts by default; document and approve the exceptions under PCI DSS 8.6.1.
- Move secrets out of code: scan repositories, images and pipelines; move credentials to a vault or replace them with federation. Pilot on one application and keep the old credential valid until the new path is proven, so rollback is possible.
- Set review cycles by the strictest rule: six months for DORA critical or important functions, annual elsewhere, and record the PCI targeted risk analysis.
- Write the compromise rule: rotate every credential exposed in a supplier or internal incident, with "unused" exemptions verified by last-use data.
Metrics
- Ownership coverage: percentage of machine identities with a named owner (target 100% in regulated systems).
- Review completion: percentage of machine identities reviewed within their required cycle.
- Interactive-capable service accounts: count, and how many have an approved exception.
- Hard-coded secrets: open secret scanning findings in regulated repositories, and median age.
- Static credential share: percentage of machine authentications using long-lived secrets versus federated or short-lived credentials.
Common failure patterns
- Human-only reviews: access reviews cover people, while service accounts with the same access are never certified.
- Privileged service accounts outside PAM: NYDFS and NIS2 privileged account controls applied to admins but not to automation accounts with equal rights.
- Calendar rotation without a compromise trigger: credentials rotated yearly but not after a supplier breach.
- Shared integration accounts: one account used by several tools, so actions cannot be attributed as DORA and PCI DSS require.
- SOX scope gaps: batch and integration accounts that write to financial applications left out of ITGC testing.
Framework mapping
| Theme | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | ATT&CK risk addressed |
|---|---|---|---|---|
| Identity and credential management for services | PR.AA-01 | IA-4, IA-9, AC-2 | 5.16, 5.17 | T1078.004 Cloud Accounts |
| Least privilege and review | PR.AA-05 | AC-6 | 5.18, 8.2 | T1078 Valid Accounts |
| Credential storage | PR.AA-01 | IA-5, IA-5(7) | 5.17 | T1552.001 Credentials In Files |
| Regulatory requirements understood | GV.OC-03 | AU-2 (logging) | 5.31 | All of the above |
Practitioner checklist
- Tag every regulated system with the rules that apply to its machine identities.
- Keep an inventory of service accounts, keys, tokens and certificates with owners and last use.
- Treat service accounts with security-relevant rights as privileged accounts.
- Deny interactive logon for service accounts unless an approved, time-limited exception exists.
- Remove credentials from code and configuration; prefer federated, short-lived credentials.
- Review machine identity access on the strictest applicable cycle and keep the evidence.
- Rotate all credentials exposed in any incident, verifying "unused" claims with data.
- Include agent and integration accounts in SOX ITGC and PCI DSS scoping.
Standards and references
- PCI Security Standards Council: Document Library (PCI DSS v4.0.1)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk management RTS)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 technical and methodological requirements)
- Cornell LII: 23 NYCRR 500.7 Access privileges and management
- eCFR: 45 CFR 164.312 Technical safeguards
- PCAOB: AS 2201 An Audit of Internal Control Over Financial Reporting
- NIST: SP 800-53 Rev. 5
- Schellman: PCI DSS service account requirements
This guide summarises regulatory requirements for service accounts and machine identities as of 12 November 2026 and is not legal advice. Related NHI Mgmt Group resources: Service Account Security Guide · NHI lifecycle automation · NHI Governance Maturity Model · Encryption and Key Management Requirements Map