An account, token, key, certificate, or federated credential that a third party uses to access customer systems. These identities often sit outside standard employee lifecycle workflows, which makes ownership, expiry, offboarding, and monitoring harder unless they are explicitly governed.
Expanded Definition
Supplier-Held Identity is best understood as an externally managed identity used by a vendor, contractor, integrator, or managed service provider to reach a customer environment. It can take the form of a federated login, API token, SSH key, certificate, service account, or delegated application credential. In identity security terms, the defining feature is not who created the identity, but who controls it day to day and whether the customer can still govern its use.
This matters because supplier-held identities often sit outside normal joiner-mover-leaver processes, privileged access reviews, and endpoint controls. They may be long-lived, shared across teams, or provisioned for automation rather than a named person. That makes them easy to overlook during audits and easy to retain after a contract ends. Guidance varies across vendors, but the governance expectation is consistent: the customer should know what the identity can access, who owns it, how it is authenticated, when it expires, and how it is revoked. The NIST Cybersecurity Framework 2.0 is useful here because it frames access management, monitoring, and supplier risk as part of an integrated control model.
The most common misapplication is treating a supplier-held identity as a one-time provisioning task, which occurs when access is granted without a defined owner, expiry, or review cadence.
Examples and Use Cases
Implementing supplier-held identity governance rigorously often introduces friction for third parties, requiring organisations to weigh faster onboarding against tighter control over external access.
- A cloud provider receives a federated administrative role into a tenant for break-glass support, but the customer requires named ownership, MFA, and quarterly recertification.
- A software supplier uses an API key to send telemetry into a customer platform, and the key must be rotated, scoped narrowly, and revoked when the contract ends.
- An integrator maintains SSH certificates for automated deployment pipelines, with issuance tied to a service account and monitored through a central audit trail.
- A managed service provider uses delegated access into a SIEM or EDR platform, and the customer separates support access from production change privileges to limit blast radius.
- A research partner connects through a temporary federation relationship, and the access policy is aligned to NIST SP 800-63 Digital Identity Guidelines principles for assurance, authentication, and lifecycle discipline.
These patterns are common in cloud operations, software supply chains, and managed security services. They also appear in identity federation, where the relationship is technically valid but operationally fragile if ownership records, expiry dates, and logging are not maintained. For deeper control thinking, teams often pair identity governance with OWASP Non-Human Identity Top 10 guidance when the supplier identity is automated or machine-operated.
Why It Matters for Security Teams
Supplier-held identities create risk because they combine third-party dependency with direct access to sensitive environments. If a supplier account is overprivileged, shared, or left active after a service relationship changes, it can become a durable entry point that bypasses normal employee controls. That problem is especially serious in environments where access is federated into admin consoles, cloud control planes, CI/CD systems, or data platforms. Security teams need a clear model for ownership, authentication strength, logging, review, and revocation, otherwise supplier access becomes a hidden exception rather than a governed control.
This is also where identity, NHI, and access governance intersect. A supplier-held identity may be human-operated today and automated tomorrow, which means the same access path can shift from a person to a script without changing the entitlement record. In that situation, the security question is no longer only who signed in, but what authority the credential holds and whether that authority still matches the contract. The governance lens is reinforced by NIST Cybersecurity Framework 2.0, which emphasises supplier oversight, access control, and continuous monitoring.
Organisations typically encounter the real exposure only after a supplier relationship ends or a third-party incident forces an emergency credential review, at which point supplier-held identity becomes operationally unavoidable to address.
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 surface, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Addresses access control and least privilege for external identities. |
| NIST SP 800-63 | AAL2 | Defines assurance expectations that help govern supplier authentication strength. |
| OWASP Non-Human Identity Top 10 | Covers governance risks for non-human and externally managed identities. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Supports zero trust segmentation and policy enforcement for external access paths. |
| DORA | Requires oversight of third-party ICT risk and resilient access governance. |
Treat supplier-issued tokens, keys, and certificates as governed NHI assets with owner and expiry controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
