How should organisations govern vaulted credentials for third parties and automation?

Why This Matters for Security Teams

Vaulting third-party and automated credentials in the same platform creates a false sense of control. The vault stores secrets, but it does not define who the actor is, how long access should last, or how revocation will work when the relationship ends. That distinction matters because third parties bring human accountability and offboarding risk, while automation brings machine speed, repeatability, and scale. NHI Management Group guidance aligns with OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0: the control objective is not storage alone, but governance across identity, privilege, and lifecycle.

The risk is amplified by secret sprawl. Entro Security found that 91% of former employee tokens remain active after offboarding in its 2025 State of NHIs and Secrets in Cybersecurity, which is a strong indicator that offboarding failures are a lifecycle problem, not a vaulting problem. In practice, many security teams encounter credential misuse only after a vendor engagement ends or an automation job keeps running with privileges no one remembered to remove.

How It Works in Practice

Effective governance starts by separating the access model into two paths. Third parties should receive named, time-bounded access with explicit sponsor ownership, contract-linked approval, and a documented offboarding trigger. Automation should receive machine identity, not shared human-style accounts, with scoped permissions tied to workload purpose. That means using short-lived secrets, JIT issuance where possible, and revocation that is automatic rather than manual. Static credentials can still be vaulted, but the vault should serve as a distribution and control point, not as the primary security boundary. See Ultimate Guide to NHIs — Static vs Dynamic Secrets and Guide to the Secret Sprawl Challenge for the operational difference between long-lived and ephemeral credential models.

For automation, best practice is to bind access to workload identity and runtime policy, not to reusable shared secrets. That is where intent-based authorisation matters: the request should be evaluated in context, including the system, task, time window, and target resource. In mature environments, this often means policy-as-code plus an identity layer that proves what the workload is, rather than merely presenting a password. Current guidance from NIST SP 800-63 Digital Identity Guidelines and the NIST Cybersecurity Framework 2.0 supports strong identity assurance and continuous control.

• Assign a named owner for every third-party secret and every automated credential.
• Issue third-party access with expiry, sponsor approval, and offboarding checkpoints.
• Use workload identity and JIT credentials for automation wherever the platform supports it.
• Log secret retrieval, use, and revocation separately from the vault event itself.

These controls tend to break down in legacy environments where shared service accounts, flat network trust, and manual change windows make per-task identity impossible.

Common Variations and Edge Cases

Tighter vault governance often increases operational overhead, requiring organisations to balance speed against accountability. That tradeoff is real when vendors need repeated access, when batch jobs run across many systems, or when a legacy platform cannot support short-lived tokens. Current guidance suggests treating those cases as exceptions, not the default. If a third party truly needs persistent access, then the justification, scope, and review cadence should be stronger, not weaker. If automation cannot yet use workload identity, the fallback should be a tightly scoped secret with short TTL, clear rotation, and monitoring that flags reuse.

There is no universal standard for this yet, but the direction of travel is clear in 52 NHI Breaches Analysis and Reviewdog GitHub Action supply chain attack: broad credential reuse and weak lifecycle controls are common failure patterns. For that reason, organisations should review vault policy, PAM integration, and revocation workflows together, not as separate projects. When third-party access is time-bound but not actually revoked, or when automation shares a secret across multiple jobs, the vault becomes a high-value repository for stale privilege instead of a control point.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• How should healthcare organisations govern AI chatbots that can access PHI?
• How should healthcare organisations govern AI tools that handle PHI?