A third-party account is an identity used by a vendor, supplier, or external service provider to access an organisation’s systems. These accounts create governance risk when they outlive the work that justified them, especially if ownership, expiry, and monitoring are unclear.
Expanded Definition
A third-party account is an identity issued to a vendor, supplier, contractor, or managed service provider so they can perform authorised work inside an organisation’s environment. In NHI governance, the account is not defined by who owns the relationship commercially, but by how the identity is provisioned, scoped, monitored, and retired. That distinction matters because third-party access often persists longer than the contract, project, or incident that justified it.
Definitions vary across vendors and IAM programmes, but the operational meaning is consistent: if an external party can authenticate into your systems, that account must be treated as a governed non-human or delegated identity surface. NHI Management Group aligns this problem space with lifecycle control, least privilege, and offboarding discipline, as reflected in the OWASP Non-Human Identity Top 10 and broader NHI guidance. A third-party account may be interactive, service-based, or tied to remote support tooling, but the security question is the same: who approved it, what does it reach, and when does it expire?
The most common misapplication is treating external access as a one-time onboarding task, which occurs when account creation is separated from ownership, review, and removal.
Examples and Use Cases
Implementing third-party account governance rigorously often introduces friction for vendor support and project delivery, requiring organisations to weigh faster access against tighter approval, logging, and expiry controls.
- A cloud integrator receives a scoped account to configure a tenant, then the access remains active after the engagement closes because no expiry was set.
- A managed service provider uses a privileged account for patching and monitoring, but the organisation cannot prove which individual used it at a given time.
- A software vendor is granted emergency support access, yet the same account is reused across multiple clients, complicating audit and segregation.
- A contractor account is provisioned through HR onboarding, but the revocation step is never triggered when the statement of work ends.
- During a supply-chain incident, investigators trace suspicious access to an external identity that was trusted by default, similar to patterns described in the The 52 NHI breaches Report and exposed by the Reviewdog GitHub Action supply chain attack.
For protocol-driven access models, teams often cross-check account handling against the OWASP Non-Human Identity Top 10 and related NHI lifecycle practices.
Why It Matters in NHI Security
Third-party accounts are a common pathway for overprivilege, orphaned access, and weak accountability because they sit at the intersection of procurement, IAM, and operations. Once an external identity is created, it can outlive the business need, bypass standard joiner-mover-leaver controls, or remain invisible in shared admin tooling. That becomes especially dangerous when secrets, tokens, or remote-admin credentials are embedded in automation and not rotated. NHI Management Group notes that only 20% have formal processes for offboarding and revoking API keys, which helps explain why external access often persists after vendors leave.
The security consequence is not just unauthorised login. It is also weak incident attribution, unclear ownership, and delayed containment when external access is abused. The same patterns appear in software supply-chain compromises and credential theft events, where vendor pathways become the shortest route into production systems. Organisations typically encounter the cost of third-party account sprawl only after a vendor relationship ends or a breach is investigated, at which point the account 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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Third-party accounts are external identities that need lifecycle and ownership control. |
| NIST CSF 2.0 | PR.AC-1 | Access provisioning and authorisation are central to third-party account governance. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires each third-party session to be explicitly verified and constrained. |
Treat every vendor account as untrusted by default and enforce per-session validation.
