Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
What makes third-party NHI different
Third-party NHI is not just “someone else’s service account.” The important distinction is that an external party owns or operates the identity, so the primary enterprise depends on another organisation’s issuance, hygiene, and revocation practices to control access.
That external ownership changes the trust model. A third-party NHI can be legitimate and necessary for integration, but it also creates dependency on partner controls, contract terms, and the partner’s ability to limit scope and remove access promptly when relationships change.
Typical forms and where they appear
Third-party NHI often appears as API keys, OAuth tokens, certificates, service accounts, or automated agents used in SaaS integrations, vendor support tooling, managed services, and supply-chain workflows. These identities may bridge business systems, data pipelines, or operational tooling across organisational boundaries.
Because they are often embedded in automated processes, they can be easy to forget after the original integration is live. That is why inventory and ownership matter: without a clear register, the enterprise may not know which external identity is still active, what it can reach, or which business process depends on it.
Governance and control expectations
Governance for third-party NHI should treat the identity as an access path with an owner, a purpose, and a lifecycle. The practical questions are whether the external party can justify the access, whether the scope is minimal, whether the access is monitored, and whether revocation can happen without waiting on an informal request chain.
Contractual language matters because technical control alone is rarely enough. The agreement should support accountability for issuance, rotation, incident notification, and offboarding, while the technical implementation should reflect those obligations through tightly scoped permissions and traceable authentication material.
For practitioners, this is where third-party NHI overlaps with OWASP Non-Human Identity Top 10 on overprivilege, secret handling, and third-party exposure, and with EU Digital Operational Resilience Act (DORA) where ICT third-party risk and operational resilience are material obligations.
Why these identities are hard to manage
Third-party NHI is difficult because the enterprise often does not fully control the lifecycle. The vendor may rotate credentials on its own schedule, use shared tooling across customers, or rely on opaque internal automation that is difficult to inspect from the outside.
That makes discovery, attestations, and periodic review essential. If the enterprise cannot see where the identity is used, it cannot confidently answer whether the access is still required, whether the credential material is still valid, or whether the integration has become a standing exception.
Where the subject is third-party integration security rather than generic identity governance, external references like the NIST SP 800-53 Rev 5 Security and Privacy Controls and the EU Digital Operational Resilience Act (DORA) help anchor access control and third-party accountability expectations.
Risk and Threat Considerations
Third-party NHI is attractive to attackers because it can provide a trusted path into enterprise systems with fewer user-facing safeguards than human access. If the vendor’s credential, token, or certificate is stolen, over-scoped, or left active after the relationship ends, the compromise can be both durable and hard to spot.
Failure mechanism: Weak ownership, long-lived secrets, excessive privilege, or poor offboarding lets an external identity remain valid after the original business need has changed, creating a persistent access path for abuse or lateral movement.
Impact: The result can be unauthorized data access, integration abuse, supply-chain compromise, or a widened blast radius when one partner compromise is inherited by multiple downstream systems.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party NHI is defined by external ownership and partner-controlled exposure. |
| NHI-01 — Improper Offboarding | External identities create offboarding risk when access survives the business relationship. | |
| NHI-05 — Overprivileged NHI | Third-party NHI frequently accumulates more access than the integration needs. | |
| Recommendation — Require supplier-owned non-human identities to be scoped, reviewed, and revoked under contract. Tie vendor offboarding to immediate revocation of credentials, tokens, and certificates. Constrain external identities to least privilege and review entitlements regularly. | ||
| NIST SP 800-53 Rev 5 | AC-20 — Use of External Information Systems | External-party access directly concerns controls for information systems outside the organization. |
| IA-5 — Authenticator Management | Third-party NHI depends on lifecycle control of tokens, keys, and certificates. | |
| IA-9 — Service Identification and Authentication | Third-party NHI authenticates services and automated actors across trust boundaries. | |
| Recommendation — Authorize and monitor external-system use before allowing third-party identities into enterprise resources. Rotate, store, and revoke external authenticators under a defined lifecycle process. Authenticate third-party services with strong machine-to-machine controls and traceable credentials. | ||
| DORA | ICT Third-Party Risk Management | The subject directly involves operational resilience and third-party access accountability. |
| Recommendation — Contract for access governance, incident notification, and termination of third-party identities. | ||
| CIS Controls v8 | CIS-5 — Account Management | External identities need ownership, lifecycle, and deprovisioning discipline. |
| Recommendation — Inventory and retire third-party accounts, keys, and tokens when access is no longer required. | ||
Practitioner Guidance
Governance implication: Treat third-party NHI as a jointly managed control surface, not a purely technical integration detail. The enterprise should require a named business owner, a technical owner, and a documented offboarding path so that access can be reviewed and revoked without ambiguity.
What to watch for: Pay special attention to credentials that outlive contracts, identities that are shared across customers, and integrations where the vendor cannot clearly describe rotation and revocation behavior. Those are the patterns that most often turn a legitimate external identity into a standing exposure.
Related resources from NHI Mgmt Group
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What is the difference between third-party risk management and NHI governance?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when a third-party NHI causes PCI scope exposure?
