Because service accounts, API keys, certificates, and delegated automation often sit outside the visibility of traditional IAM and PAM reporting. If those identities are over-privileged, dormant, or unmanaged, financial institutions lose control over the access paths that DORA expects them to evidence.
Why This Matters for Security Teams
DORA raises the bar from basic access control to demonstrable operational resilience, and non-human identities sit directly in that evidence chain. Service accounts, API keys, certificates, and automation tokens are often the exact identities used for payment flows, controls testing, logging, backup, and incident response. If they are invisible to inventory, weakly governed, or impossible to attest to, the institution cannot confidently show who or what had access, when it changed, and how it was revoked. That makes compliance an evidence problem, not just a policy problem.
NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which explains why DORA reviews often stall at the audit trail stage. The regulatory expectation is not merely to secure identities in the abstract, but to prove control over access paths that can fail silently. That matters even more where third-party integrations, outsourced operations, and CI/CD automation are in scope, because those paths can bypass human-centric IAM review. In practice, many security teams encounter NHI control gaps only after an audit request or incident has already exposed the missing records.
How It Works in Practice
Meeting DORA means treating non-human identities as first-class regulated assets across the full lifecycle: issuance, privilege assignment, rotation, monitoring, and revocation. Current guidance suggests that institutions should maintain a complete inventory of NHIs, map each identity to an owner and business service, and enforce time-bound access where possible. That inventory should include secrets outside the vault, because hidden credentials are still operational identities even if they never appear in the IAM console.
For most financial institutions, the practical control set includes four moves:
- Discover all service accounts, API keys, certificates, and delegated automation used by critical services.
- Classify each NHI by business criticality, data access, and third-party exposure.
- Rotate or replace long-lived secrets with short-lived credentials and explicit expiry.
- Log issuance, use, and revocation so auditors can reconstruct access decisions.
This is where DORA intersects with identity governance. The regulation expects resilience evidence, so teams need records that show secrets were managed, not just that a policy exists. The NHIMG research on the Ultimate Guide to NHIs is useful here because it frames the audit challenge as lifecycle control, while the DORA text demands resilience and oversight rather than informal assurances. Practitioners should also align secrets discovery with code and pipeline scanning, because hard-coded credentials and build-time tokens are often where evidence disappears first. These controls tend to break down in legacy estates with shared service accounts and unmanaged third-party integrations because ownership, rotation, and revocation are not technically enforced end to end.
Common Variations and Edge Cases
Tighter NHI governance often increases operational overhead, so organisations must balance auditability against deployment speed and system uptime. That tradeoff is real in batch processing, mainframe bridges, and vendor-managed platforms where frequent rotation can disrupt stable integrations. Best practice is evolving, but there is no universal standard for how much automation is enough; many institutions use risk-based tiers so the most sensitive NHIs get the shortest lifetimes and the strongest approvals.
Edge cases usually involve identities that are technically “non-human” but operationally obscured. Examples include ephemeral build agents, certificates embedded in appliances, emergency break-glass automations, and outsourced tools that issue credentials on behalf of the institution. These need explicit ownership and documented controls, even when another party administers the platform. The research from Code Formatting Tools Credential Leaks and JetBrains GitHub plugin token exposure shows why supply-chain paths matter: credentials often leak through developer tooling before governance teams even know they exist. DORA compliance becomes harder in environments with shared credentials, stale documentation, or unmanaged third-party access because the institution cannot produce reliable evidence of control.
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 and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access identities must be identified and managed to evidence control. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Unmanaged service accounts and secrets are a core NHI risk in DORA scope. |
| NIST AI RMF | Governance and monitoring of automated identities support resilient AI-enabled operations. | |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires explicit verification of non-human access paths. |
Authenticate each NHI request contextually instead of trusting network location or permanence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
