Why do NHIs create such a difficult DORA compliance problem?

Why This Matters for Security Teams

DORA turns NHI sprawl from a hygiene issue into an audit problem. If service accounts, API keys, and machine tokens cannot be tied to a clear owner, lifecycle, and business purpose, then access reviews, incident reporting, and resilience evidence all become weak. The issue is not just volume. It is also the speed at which NHIs are created, copied, embedded in automation, and forgotten. NHI Mgmt Group research shows Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which helps explain why DORA evidence often collapses under scrutiny.

For regulated firms, that creates a mismatch between operational reality and what auditors expect to see under DORA --- Digital Operational Resilience Act and the control discipline reflected in NIST Cybersecurity Framework 2.0. NHIs are often provisioned outside standard joiner-mover-leaver workflows, so evidence is fragmented across cloud consoles, CI/CD pipelines, secrets vaults, and vendor integrations. That makes compliance difficult to prove even when some controls exist on paper. In practice, many security teams encounter NHI exposure only after an access review, incident, or vendor assessment has already exposed the gap, rather than through intentional governance.

How It Works in Practice

The hard part is not discovering that NHIs exist. The hard part is proving they are governed consistently across their full lifecycle. DORA expects firms to show control over access, change, incident handling, and third-party dependencies, while NHIs commonly live in separate technical domains with different owners and different review rhythms. A practical response starts with inventory, then moves to classification, ownership, and expiry. NHI Mgmt Group’s Top 10 NHI Issues highlights why this is so difficult: most organisations do not have reliable visibility into where secrets sit, who uses them, or whether they are still needed.

Security teams should treat the problem as a control chain, not a single task:

• discover every NHI across cloud, SaaS, code, and vendor-managed workflows;
• assign a business owner and technical steward for each identity;
• link each secret or token to a documented purpose and expiry;
• rotate or revoke credentials when the workload changes or stops;
• log access and entitlement changes in a way that supports audit evidence;
• review third-party NHIs with the same discipline used for internal accounts.

This also aligns with the lifecycle emphasis in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the accountability expectations in EU Digital Operational Resilience Act (DORA). The strongest programmes also apply least privilege, short-lived secrets, and documented offboarding so that access can be evidenced, not merely assumed. These controls tend to break down when teams rely on manually maintained spreadsheets and static secrets in fast-moving CI/CD and vendor-integrated environments because ownership and revocation fall behind change.

Common Variations and Edge Cases

Tighter NHI governance often increases operational overhead, so organisations must balance auditability against delivery speed. That tradeoff is especially visible in cloud-native estates, managed service ecosystems, and autonomous automation, where rigid review cycles can slow release pipelines if they are not designed well. Current guidance suggests that the answer is not broader standing access but better runtime control: use JIT credentials, short-lived secrets, and policy checks that match the actual task rather than a static role label. Best practice is evolving here, especially for agent-driven workflows and machine-to-machine orchestration.

One edge case is the third-party NHI. A vendor may own the system that creates or uses the identity, but the regulated firm still needs evidence that the access is necessary, bounded, and revoked when no longer required. Another is ephemeral automation in CI/CD, where credentials may exist for minutes rather than months. In those environments, traditional quarterly review models do not give enough signal; the more useful control is continuous inventory plus event-based review. This is consistent with the accountability themes in 52 NHI Breaches Analysis and the ecosystem risk described in Cisco DevHub NHI breach. There is no universal standard for exactly how often every NHI must be reviewed, but there is broad agreement that unmanaged standing credentials are the wrong default.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?
• When does a machine identity become a compliance problem?
• When do IAST and RASP create a false sense of coverage for NHIs?