Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk Who is accountable for identity governance when credentials…
Governance, Ownership & Risk

Who is accountable for identity governance when credentials are stored on user devices?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 23, 2026 Domain: Governance, Ownership & Risk

Accountability shifts toward the organisation that defines the trust model, the endpoint controls, and the lifecycle rules for the credential. Device storage does not remove governance responsibility. It increases the need to prove that key protection, recovery, and audit review are still enforced across the full identity journey.

Why This Matters for Security Teams

When credentials live on user devices, accountability does not disappear into the endpoint. It moves across identity governance, device security, and operational ownership. Security teams are still expected to prove who can issue, use, recover, and revoke those secrets, even when the storage layer is local. That matters because device compromise, lost hardware, and weak recovery processes can turn a convenient control into a durable exposure.

The practical risk is not just theft. It is unclear ownership: one team manages the app, another manages the device, and a third assumes identity policy covers both. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point toward lifecycle ownership, traceability, and least privilege, but neither treats endpoint storage as a governance exemption. NHIMG research also shows the scale of the problem: 79% of organisations have experienced secrets leaks, and 71% of NHIs are not rotated on time, as documented in the Ultimate Guide to NHIs. In practice, many security teams discover the accountability gap only after a device loss or credential leak has already become an incident.

How It Works in Practice

Accountability should be assigned to the party that defines the trust model and lifecycle rules for the credential, not to the user simply carrying the device. In practice, that means identity owners set issuance and revocation policy, endpoint or platform teams enforce device protection, and application owners define whether a credential may exist on-device at all. The operating model needs clear evidence for key protection, recovery, audit review, and offboarding.

For most environments, the best pattern is to treat device-stored credentials as high-risk exceptions unless they are short-lived, bound to the device, and revocable. Where feasible, use certificate-based or token-based approaches with strong device posture checks, and avoid static long-lived secrets on endpoints. The NIST SP 800-63 Digital Identity Guidelines are useful for thinking about authentication assurance, while the Lifecycle Processes for Managing NHIs section reinforces that issuance, rotation, and revocation must remain auditable end to end.

  • Define a named credential owner, a device owner, and a recovery owner.
  • Bind stored credentials to device posture where the platform supports it.
  • Prefer short-lived tokens or certificates over static secrets on endpoints.
  • Require revocation workflows that work even if the device is lost or offline.
  • Log issuance, access, renewal, and removal events for audit review.

These controls tend to break down when BYOD fleets, offline field devices, or unmanaged laptops are allowed to cache long-lived secrets without a reliable revocation path.

Common Variations and Edge Cases

Tighter endpoint control often increases operational overhead, requiring organisations to balance usability against revocation certainty. That tradeoff is especially visible in mobile workforces, shared devices, and regulated environments where recovery and auditability matter as much as access speed.

There is no universal standard for this yet, but current guidance suggests several common distinctions. If the credential is a human login artifact stored by a password manager, accountability may sit with the identity and endpoint teams together. If it is an application or service credential stored on a user device, the application owner and identity governance function usually carry primary responsibility. If the device is personally owned, the organisation still owns the governance decision if it permits the credential to exist there.

NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that storage location does not reduce risk. It often increases it when secrets spread across apps, sync tools, backups, and browser stores. Organisations should also align local storage decisions with the Top 10 NHI Issues, especially around visibility, rotation, and offboarding. The main exception is tightly managed, encrypted hardware-backed storage with documented revocation and recovery. Even then, governance remains with the organisation that authorised the storage model in the first place.

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 SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Covers rotation and lifecycle control for stored secrets.
NIST CSF 2.0PR.AC-1Access governance must still define who can use device-held credentials.
NIST SP 800-63Digital identity assurance depends on trustworthy binding and recovery.

Set rotation and revocation rules for any device-stored credential and verify they work during offboarding.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org