Yes, because machine identities often sit inside the same authentication and access pathways that DORA expects firms to protect and recover. Service accounts, API keys, and privileged automation can become single points of failure if they are not inventoried, rotated, and recoverable. DORA-ready programmes should govern NHI alongside human access.
Why This Matters for Security Teams
DORA is not only about restoring customer channels or core banking workflows. It also depends on the identities that keep those services running: service accounts, API keys, certificates, bot users, and other NHI. If those credentials are not inventoried, governed, and recoverable, operational resilience becomes fragile long before a major incident is declared. Current guidance suggests teams should treat NHI as part of the same control plane that covers authentication, access, logging, and recovery under DORA and NIST Cybersecurity Framework 2.0.
The practical issue is that many machine identities are created quickly, used broadly, and forgotten. That leaves gaps in ownership, rotation, segregation of duties, and recovery testing. NHIMG research shows why this matters: 72% of organisations have experienced or suspect a breach of non-human identities, and the average organisation believes more than 1 in 5 of those identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities. In practice, many security teams encounter machine-account failure only after an outage or fraud event has already exposed the control gap, rather than through intentional resilience testing.
How It Works in Practice
For DORA programmes, the right model is to govern NHI through the same lifecycle thinking used for human identity, but with stricter attention to automation and dependency chains. That means identifying where machine credentials exist, who owns them, what systems they can reach, how often they are rotated, and whether they can be restored after compromise. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful for framing this as a repeatable process rather than a one-time clean-up.
In operational terms, teams should fold NHI into asset and service mapping, access reviews, incident response, backup and recovery, and third-party risk. The same applies to monitoring. If a service account is used by payments, data pipelines, or agentic workflows, its authentication events should be logged, reviewed, and correlated with workload behaviour. Where organisations have weak visibility, compromise often starts with over-privileged or unrotated secrets. That pattern is consistent with Top 10 NHI Issues, which is why NHI governance belongs in resilience testing, not only in IAM policy documents.
- Inventory all machine identities, including service accounts, API keys, certificates, and integrations.
- Assign accountable owners and define business criticality for each identity.
- Rotate secrets, remove unused credentials, and test recovery paths for failed automation.
- Include NHI events in incident drills, logging, and access review evidence packs.
This aligns with DORA’s emphasis on operational continuity, but it also supports broader control expectations in EU Digital Operational Resilience Act (DORA) because resilience fails fast when a forgotten secret still has production reach. These controls tend to break down when identities are embedded in legacy scripts, unmanaged vendor integrations, or ephemeral automation that was never formally registered.
Common Variations and Edge Cases
Tighter NHI governance often increases operational overhead, requiring organisations to balance resilience gains against delivery speed and automation sprawl. That tradeoff is real, especially where legacy applications hard-code secrets or where DevOps teams spin up identities faster than governance teams can review them. Best practice is evolving, and there is no universal standard for this yet, but the direction is clear: DORA programmes need a risk-based inventory, not a perfect inventory.
Some environments warrant different treatment. High-change cloud platforms may rely on short-lived tokens and workload-native identity, while on-premise systems may still depend on static credentials that need compensating controls such as privileged access management, segregation, and stricter monitoring. Vendor connections also matter: if an external SaaS tool authenticates through OAuth or an API key, that NHI is part of the firm’s operational resilience boundary even when the system is outside the perimeter. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps translate that reality into evidence for audit and supervision.
For teams assessing current maturity, the key question is not whether NHI exists in the estate. It is whether those identities are discoverable, governed, monitored, and recoverable when an incident or change window forces a failover. Where machine identity ownership is unclear or credentials are shared across services, DORA controls usually become paper controls rather than operational ones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | DORA requires ICT resilience, which includes machine identities and secrets. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential rotation is central to reducing NHI compromise and outage risk. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management applies directly to service accounts and API keys. |
Inventory machine credentials and automate rotation, revocation, and ownership checks.
