What is the difference between wallet custody and access governance?

Why This Matters for Security Teams

Wallet custody and access governance solve different problems, and confusing them creates blind spots. Custody answers where the signing material lives and who can technically move it. Governance answers whether that use is justified, time-bound, approved, and reviewed. In NHI environments, that distinction matters because secrets are rarely static assets; they are operational capability. When teams treat possession as sufficient control, they often miss overreach, stale access, and unauthorized reuse.

This is why lifecycle thinking is central in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, and why the OWASP Non-Human Identity Top 10 treats weak control over NHI credentials as a recurring failure mode. Governance also has to account for review, revocation, and exception handling, not just storage. In the Ultimate Guide to NHIs — Regulatory and Audit Perspectives, NHIMG consistently frames auditability as a lifecycle requirement, not a point-in-time check. In practice, many security teams discover that custody was “controlled” only after a dormant secret has already been reused in an unauthorised path.

How It Works in Practice

Custody is usually enforced through vaults, HSMs, secret managers, hardware-backed wallets, or MPC-based signing workflows. That layer establishes who or what can physically hold or derive the signing material. Access governance sits above it and defines the policy around use: who may request access, what task or context justifies it, how long the credential may be active, who approves exceptions, and when the entitlement is revoked. Current guidance suggests that both layers should be evaluated together, because custody without governance becomes durable exposure.

For NHI programs, the practical model is: issue the minimum signing capability, limit it to the narrowest task window, and require workflow-based review before renewal. This is consistent with Top 10 NHI Issues, which highlights rotation, visibility, and over-privilege as common control failures. It also aligns with the NIST Cybersecurity Framework 2.0, especially governance and access-control outcomes that depend on clear ownership and review. Practitioners typically separate the questions this way:

• Custody: Where is the signing material stored, and what system can release it?
• Use: Which workload, service, or operator is allowed to invoke it?
• Condition: Under what context, time window, or approval state is use valid?
• Review: How is continued access re-validated, rotated, or revoked?

That separation matters because a wallet can be technically secure while still being operationally overexposed through broad entitlements, stale approvals, or unmanaged delegation. These controls tend to break down when signing authority is shared across many services and teams because ownership, approval, and revocation paths become ambiguous.

Common Variations and Edge Cases

Tighter custody control often increases operational friction, requiring organisations to balance stronger protection against recovery, automation, and service availability. That tradeoff is especially visible when wallets support high-frequency transactions, emergency access, or multi-operator approval flows.

One common edge case is delegated custody, where a third party holds the material but the organisation still owns the access policy. Another is custodial multi-sig or shared-signature workflows, where possession is distributed but governance can still fail if approval thresholds are too broad or poorly reviewed. There is also no universal standard for whether policy should live primarily in the wallet system, the IAM layer, or both. Best practice is evolving toward layered controls that make custody technical and governance procedural.

The most useful mental model is that custody protects the key material itself, while governance protects the right to act with it. That distinction becomes harder in environments with service accounts, automation pipelines, or platform teams that provision wallets for many downstream users. In those cases, the 52 NHI Breaches Analysis shows why lifecycle gaps matter more than storage alone, and why auditors increasingly ask for evidence of approval, rotation, and revocation rather than proof of vaulting alone.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between human IAM controls and NHI governance?