Accountability sits with the institution that must demonstrate operational resilience, even if access is granted through vendors or automation. Under DORA, teams need evidence that critical identities, permissions, and recovery paths are governed well enough to withstand disruption and audit scrutiny.
Why This Matters for Security Teams
When identity visibility is too weak to support resilience testing, the issue is not only technical blind spots. It is an accountability gap. Under DORA, the institution that must evidence operational resilience remains responsible for proving that critical identities, permissions, and recovery paths are known, controlled, and testable, even when vendors, automation, or platform teams hold the keys. That expectation aligns with control discipline in DORA and the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls.
For non-human identities, weak visibility usually means teams cannot answer basic resilience questions: which service account can reach production, which API key is still active, which secrets remain embedded in CI/CD, and which recovery path actually works during a fault. NHIMG research shows only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which makes resilience testing more guesswork than evidence. In practice, many security teams discover identity sprawl only after a failed control test or a disruptive incident has already exposed the gaps.
How It Works in Practice
Accountability starts with scope definition. The institution must identify every identity that can affect resilient operation, including service accounts, workload identities, API keys, certificates, break-glass credentials, and delegated vendor access. That inventory must connect each identity to an owner, purpose, privilege level, expiration or rotation rule, and recovery dependency. Without that mapping, resilience testing cannot prove that a control failure will remain survivable.
Practically, teams should test identity resilience the same way they test failover: by simulating loss, corruption, or delay. If a privileged API key is revoked, can the workload recover with a just-in-time replacement? If a CI/CD token is invalidated, does the pipeline fail safely? If an admin service account is unavailable, is there a documented and approved fallback path? NHIMG’s NHI Lifecycle Management Guide is useful here because resilience depends on lifecycle discipline, not just discovery.
- Map critical services to the identities they depend on.
- Assign accountable owners for issuance, rotation, and revocation.
- Define recovery paths for lost secrets and expired credentials.
- Test detection for stale, orphaned, and overprivileged identities.
- Keep evidence that control failures were observed, remediated, and retested.
For control design, the institution can anchor evidence in NIST SP 800-53 Rev 5 Security and Privacy Controls while using DORA to frame operational resilience obligations. These controls tend to break down when identity ownership is split across SaaS, cloud, and outsourced operations because no single team can prove end-to-end recovery readiness.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, requiring organisations to balance resilience evidence against velocity and distributed ownership. That tradeoff is real, especially where automation creates high churn or third parties administer parts of the stack.
Current guidance suggests the accountable institution should still retain evidence of control, even if it delegates execution. Best practice is evolving for complex environments such as shared platform teams, multi-cloud estates, and managed service dependencies, but there is no universal standard for replacing named accountability with vendor assurances alone. If a provider rotates credentials on the institution’s behalf, the institution still needs proof that the rotation occurred, that the secret was invalidated, and that the service recovered cleanly.
Weak visibility also complicates incident recovery. NHIMG research in the 52 NHI Breaches Analysis shows how identity issues often surface only after compromise has spread across systems. That is why resilience testing should include orphaned identities, stale tokens, and broken revocation paths. The main exception is highly constrained lab or sandbox systems, where temporary identity gaps may be tolerated if they cannot affect regulated production services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 | Asset and identity visibility are required to know what must be protected and tested. |
| NIST SP 800-63 | Digital identity assurance supports trust in credential issuance and lifecycle evidence. | |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero trust requires continuous verification of identity before access is granted. |
| NIST AI RMF | GOVERN | AI RMF governance aligns with proving accountability for autonomous identity decisions. |
Document ownership, decision rights, and evidence collection for identity-driven resilience controls.
Related resources from NHI Mgmt Group
- What breaks when customer identity verification is too weak for support and recovery requests?
- Who is accountable when identity proofing is too weak for a regulated sale?
- Who is accountable when production visibility is too weak to detect problems early?
- How do you know if identity governance evidence will withstand SOX testing?
