Why do shared accounts and vendor credentials need different controls from employee passwords?

Shared accounts and vendor credentials are non-human access paths, so the main risk is not memorisation but governance. They need time-bound access, session brokering, masking, and revocation because multiple people or external parties may touch the same secret, and every use has to be attributable and recoverable.

Why shared accounts and vendor credentials need different controls

Shared accounts and vendor credentials are not just “harder passwords.” They create a different trust model. Employee passwords are usually tied to one person, one employment relationship, and one internal identity lifecycle. Shared and external credentials can be used by multiple people, may cross organisational boundaries, and often need stronger attribution, tighter expiry, and more restrictive session handling.

That difference matters because the control objective changes. With an employee password, the main goal is to prove and protect a single user. With a shared or vendor credential, the main goal is to reduce blast radius, preserve accountability, and make access revocable even when several humans or a third party are involved in the same access path.

What changes when one secret represents many users

shared credentials blur ownership. If five administrators or a vendor team can all use the same login, password strength alone does not solve the problem, because the security question becomes who used it, from where, and under what authority. That is why controls such as session brokering, step-up approval, time-bound access, and logging become more important than simple memorisation hygiene.

Vendor credentials add another layer: the organisation often does not control the vendor’s internal handling, rotation discipline, or offboarding process. If a supplier rotates personnel or subcontractors, a static shared secret can outlive the people who were supposed to use it. Current guidance suggests treating that credential as a governed access path, not a normal user password.

For the identity and secret lifecycle side of this problem, see the Ultimate Guide to NHIs, Key Challenges and Risks and the Guide to NHI Rotation Challenges, which both cover rotation, unmanaged credentials, and lifecycle control where a secret is used by more than one operator or system.

Why attribution and recovery drive the control design

When multiple people touch the same secret, the organisation loses clean user-level attribution unless it adds compensating controls. That is why shared access is often brokered through a vault, privileged access platform, jump host, or approved session layer instead of being distributed as a long-lived password. The control goal is not only access, but defensible evidence of access.

Recovery matters as much as prevention. If a shared password is exposed, you need to know which systems accepted it, whether the secret was reused elsewhere, and how quickly it can be revoked without breaking operations. Vendor credentials should therefore be issued with scope limits, expiry, and a clear offboarding trigger, because revocation is the real control boundary once the secret leaves the organisation.

For the underlying secret-management pattern, the Secrets Management Guide and the API Key Management Guide are useful references for centralisation, rotation, and revocation discipline. Where a provider secret is involved, the OAuth 2.0 Authorization Framework is the cleaner model because it separates client access from a human password.

Risk and Threat Considerations

Shared and vendor credentials increase exposure because one compromise can affect many users, systems, or organisations. The biggest failure mode is not weak memorisation, it is credential persistence: a secret stays valid after personnel changes, contractor changes, or operational handoffs, which creates hidden access paths and makes misuse harder to detect.

Failure mechanism: A single reusable secret is copied, stored, or shared too widely, then remains valid after one of the users, administrators, or vendor staff should no longer have access.

Impact: The resulting compromise is harder to attribute, harder to revoke cleanly, and more likely to produce lateral movement or repeated misuse before detection.

For a concrete example of how shared access paths can outlive normal password assumptions, the Poland ArcGIS password leak 2023 shows why old shared credentials are operationally dangerous when they remain valid beyond the expected user lifecycle.

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 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Shared and vendor creds must be revoked when users or suppliers change.
	NHI-02 — Secret Leakage	Shared credentials and vendor secrets are high-risk when copied or reused.
	NHI-05 — Overprivileged NHI	Shared and vendor access often accumulates excessive permissions over time.
Recommendation — Enforce timely offboarding and revoke shared access as soon as ownership changes. Centralize and rotate secrets to reduce leakage and uncontrolled reuse. Apply least privilege to shared and vendor credentials and remove excess scope.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Shared and vendor credentials need lifecycle controls, rotation, and revocation.
	IA-9 — Service Identification and Authentication	Vendor credentials often function as shared non-human or system-to-system access.
	AC-6 — Least Privilege	Shared access paths should be tightly scoped because many users may touch them.
Recommendation — Manage credential issuance, rotation, storage, and revocation with strict lifecycle discipline. Use stronger service authentication than shared passwords wherever machine access is involved. Restrict shared and vendor accounts to the minimum access needed for the task.
ISO/IEC 27001:2022	A.5.15 — Access control	Shared and vendor credentials require access rules different from normal user passwords.
	A.8.5 — Secure authentication	Vendor and shared access should use stronger authentication patterns than simple passwords.
Recommendation — Define and enforce access rules that reflect shared custody and external access risk. Use secure authentication methods that reduce password reuse and shared-secret exposure.
OWASP API Security Top 10	API2 — Broken Authentication	Shared and vendor credentials fail when authentication is reusable, weakly scoped, or hard to revoke.
	API5 — Broken Function Level Authorization	Vendor and shared access often needs tighter function scoping than employee login models.
Recommendation — Harden authentication and avoid reusable shared secrets for API and vendor access. Limit each shared or vendor credential to the exact functions it must perform.

Practitioner Guidance

What to prioritise: Treat shared and vendor credentials as exceptions that need an owner, expiry, and review cadence. If you cannot name the accountable owner or define when the credential must be revoked, the control is incomplete.

What to verify: Confirm that access is time-bound, scoped to the minimum required system, and delivered through a session layer or broker where feasible. If the same secret is reused across environments or teams, require a stronger access pattern before trusting it.

Common mistake: Teams often try to compensate for a shared secret with a stronger password policy alone. That helps little when the main problem is multi-user access, external custody, and weak attribution.

Practitioner takeaway: The control question is not “is the password strong enough?” It is “can we prove, limit, and revoke every use of this access path quickly enough to contain misuse?”