An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
Expanded Definition
Third-party identity is the access identity used by a vendor, contractor, partner, outsourcer, or external service to reach internal applications, data, and infrastructure. In NHI programs, it should be treated as a governed identity with a lifecycle, not a one-time integration artifact. Definitions vary across vendors on whether machine-to-machine partner accounts, federated workload identities, and managed service connections all count, but the operational risk is the same: externally controlled access can persist longer than intended.
The term sits between IAM, PAM, and NHI governance. A third-party identity may be human-operated, but it often behaves like an NHI when it uses API keys, service accounts, certificates, or delegated tokens. The OWASP Non-Human Identity Top 10 is a useful external reference for the credential and lifecycle failures that emerge when these identities are not inventoried, scoped, or rotated properly. NHI Mgmt Group’s Ultimate Guide to NHIs frames this as a governance problem, not just an access-control problem.
The most common misapplication is treating third-party identity as a vendor onboarding checkbox, which occurs when access is granted before ownership, expiration, and revocation criteria are defined.
Examples and Use Cases
Implementing third-party identity rigorously often introduces coordination overhead, requiring organisations to weigh faster partner enablement against tighter approval, review, and revocation controls.
- A logistics partner receives a federated account to upload shipment data into an internal portal, with scoped RBAC and scheduled access reviews.
- A managed service provider uses a privileged maintenance identity to patch systems, but the identity is constrained with JIT access and monitored through PAM.
- A SaaS integration authenticates with an API key or certificate, and the key is rotated on a fixed schedule rather than left as a standing trust path.
- A contractor is granted temporary access to a code repository, then offboarded with automated deprovisioning when the project ends.
- A developer tool exposed through a partner workflow is later abused because the external identity still has broad permissions, similar to patterns discussed in the 52 NHI Breaches Analysis.
These examples align with the control themes in the OWASP Non-Human Identity Top 10, especially around secret handling, inventory, and authorization scope. In practice, third-party identity may be provisioned through federation, direct credentials, or token exchange, and the right model depends on how much operational control the organisation can enforce.
Why It Matters in NHI Security
Third-party identity matters because external access often expands faster than governance can keep pace. NHI Mgmt Group reports that 92% of organisations expose NHIs to third parties, which makes partner access a common path for privilege creep, secret sprawl, and weak offboarding. When a vendor account is not tied to an owner, expiry date, or remediation workflow, it becomes a durable trust path that can survive contract changes, personnel turnover, and forgotten integrations.
This is where Top 10 NHI Issues and the The 52 NHI breaches Report are especially relevant: both show how weak lifecycle controls turn external identities into breach enablers. The broader governance lesson also matches the Ultimate Guide to NHIs, which treats visibility, rotation, and revocation as baseline requirements, not optional maturity steps. Organisation that cannot inventory third-party access usually discover the problem only after a compromise, audit finding, or failed offboarding event, at which point third-party 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 and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and lifecycle gaps that often affect third-party identities. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous authorization for externally sourced access paths. |
| NIST CSF 2.0 | PR.AC-1 | Access control governance maps to managing who may use partner identities and when. |
Treat every third-party identity as untrusted until continuously verified and least-privileged.
