How should organisations handle shared credentials with third parties?

Shared credentials should be eliminated wherever possible and replaced with individually attributable access, delegated roles, or vault-mediated sharing with logging and expiry. If a third party must access sensitive systems, the organisation should know who used what, when, and for how long. That makes revocation and audit materially possible.

Why This Matters for Security Teams

shared credentials create a structural accountability problem: once the same secret is reused across people, vendors, or tools, audit trails stop showing who actually performed the action. That makes incident response, revocation, and blast-radius containment much harder than most access reviews assume. The issue is not just policy noncompliance. It is that shared access removes the attribution needed to prove whether a change came from the intended third party or from reused access elsewhere.

This risk is well documented in NHI guidance. The OWASP Non-Human Identity Top 10 treats secret sprawl and weak lifecycle control as recurring failure modes, while NHIMG’s Ultimate Guide to NHIs explains why static secrets are especially risky when they move outside the organisation’s direct control. The practical problem is amplified by insecure sharing habits; NHIMG’s Guide to the Secret Sprawl Challenge highlights how quickly unmanaged distribution turns into long-lived exposure.

In practice, many security teams encounter the evidence of shared credential abuse only after a vendor incident, not through intentional access design.

How It Works in Practice

The safest pattern is to replace shared credentials with individually attributable access wherever a third party must interact with sensitive systems. That can mean delegated roles, federated access, or vault-mediated sharing where each session is issued, logged, and time-bounded. Current guidance suggests the goal is not merely to hide the secret better, but to avoid making a single reusable secret the basis of trust.

For human third parties, NIST SP 800-63 Digital Identity Guidelines support stronger identity proofing and authentication patterns than shared passwords or group accounts. For operational control, NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces access enforcement, auditability, and least privilege. In NHI terms, the same logic applies to vendor scripts, service accounts, and integration keys.

• Issue access to a named person or named workload, not to a team mailbox or shared vault entry.
• Use short-lived tokens or delegated sessions with explicit expiry, not permanent secrets.
• Require vault logging so retrieval, use, and revocation are all visible.
• Map each third-party activity to an approved business purpose and system scope.
• Rotate or revoke access automatically when the engagement ends or the ticket closes.

NHIMG’s 52 NHI Breaches Analysis and vendor research in the 2024 Non-Human Identity Security Report both point to the same operational reality: insecure secret sharing persists because convenience is still winning over lifecycle discipline. These controls tend to break down when a third party needs break-glass access across multiple systems because emergency use often bypasses normal attribution and expiry workflows.

Common Variations and Edge Cases

Tighter third-party access controls often increase onboarding friction and coordination overhead, so organisations have to balance speed against traceability. That tradeoff is real, especially for managed service providers, contractors, and integration partners that expect broad, persistent access.

Best practice is evolving for high-automation environments. For machine-to-machine sharing, there is no universal standard for every stack yet, but the direction is clear: prefer ephemeral credentials, workload identity, and policy enforced at request time rather than distributing a shared API key across multiple environments. Static secrets may still appear in legacy systems, but they should be treated as exceptions with compensating controls, not as an acceptable default.

Two common edge cases need special handling. First, emergency support access may require temporary elevation, but that should be issued through a vault or PAM workflow with named approvers and expiry. Second, some third parties insist on operating from their own tooling. In those cases, the organisation still needs per-user attribution, scoped tokens, and offboarding hooks so one partner’s compromise cannot become everyone’s compromise.

NHIMG’s LLMjacking research shows how quickly exposed credentials can be abused, which is why even temporary sharing must be logged and short-lived. The operational rule is simple: if revocation cannot be performed quickly and cleanly, the access model is already too permissive.

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 organisations govern vaulted credentials for third parties and automation?
• How do organisations operationalise NHI ownership at scale?