Accountability should sit with the system owner, the identity governance function, and the control owner for the secret store or vault. In regulated environments, the institution must also be able to prove to auditors that access was limited, logged, and removed when the underlying use case ended.
Why This Matters for Security Teams
Once a leaked credential is used against banking systems, accountability is no longer just a technical question. It becomes a governance issue across the system owner, identity governance, and the control owner for the secret store or vault. The practical problem is that leaked secrets often behave like live access paths, not expired artefacts, which is why incidents escalate quickly. NHIMG research on the Guide to the Secret Sprawl Challenge shows how unmanaged secrets create durable exposure across environments.
Current guidance from the OWASP Non-Human Identity Top 10 treats leaked machine credentials as an identity failure, not just a secret-handling failure, because the credential can be replayed, chained, and reused by an attacker long after the original use case changes. In regulated banking, that means accountability must extend beyond who stored the secret to who approved its lifetime, who monitored its use, and who proved revocation happened on time. In practice, many security teams encounter this only after a compromised token has already been used to move into customer-facing or payment systems, rather than through intentional control testing.
How It Works in Practice
For banking environments, accountability should be mapped to the control plane rather than to a single person. The system owner is accountable for the business need and the risk acceptance. The identity governance function is accountable for policy, entitlement review, and periodic validation. The vault or secret store control owner is accountable for secure issuance, rotation, logging, and revocation. This aligns with the way NHI incidents are typically analysed in NHIMG material such as the 52 NHI Breaches Analysis, where leaked credentials become operationally dangerous only when ownership and lifecycle controls are weak.
Operationally, teams should be able to show four things:
- who requested the credential and for what banking workload
- who approved access and whether least privilege was applied
- what logging existed on secret retrieval and downstream system use
- when the credential was rotated, revoked, or invalidated after the use case ended
That evidence usually needs to line up with audit expectations in NIST SP 800-63 Digital Identity Guidelines, even though those guidelines are not bank-specific. In a mature setup, leaked credentials should also be treated as a signal to review whether the workload should have been using dynamic secrets instead of a long-lived static secret, as described in NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets. These controls tend to break down when shared service accounts, poor asset ownership, or unmanaged third-party integrations make it impossible to trace a secret back to a single accountable control owner.
Common Variations and Edge Cases
Tighter accountability often increases operational overhead, requiring organisations to balance faster delivery against stronger evidence and revocation discipline. That tradeoff is real in banking, especially where many teams touch the same integration path. Best practice is evolving, but there is no universal standard for this yet on whether accountability should be assigned primarily to the application team, the platform team, or the central IAM function when a leaked credential spans multiple services.
In practice, the answer depends on custody and control. If the secret was issued through a central vault, the vault owner owns the control failure. If the application team embedded the secret in code or failed to rotate it, that team owns the implementation failure. If governance never required expiry, logging, or review, identity governance owns the policy gap. This is also why banking institutions should document whether the secret was human-operated, service-to-service, or tied to an automated NHI, because that changes the evidence trail and the revocation model. The Shai Hulud npm malware campaign is a useful reminder that once secrets leave controlled storage, attribution becomes harder and containment windows shrink. In those cases, accountability cannot be inferred from intent alone; it must be proven through ownership records, access logs, and post-incident remediation.
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 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses leaked and overlong-lived machine secrets. |
| NIST CSF 2.0 | PR.AC-4 | Covers least-privilege access and entitlement accountability. |
| NIST AI RMF | Supports governance and accountability for AI-enabled identity misuse. |
Define accountability, monitoring, and incident evidence requirements before credentials reach production.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
