Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
Expanded Definition
Third-party access sits at the intersection of identity governance, vendor risk, and privileged access control. In NHI security, it usually refers to access granted to contractors, managed service providers, support engineers, and other external operators who need to reach systems without becoming employees. The term is used broadly across IAM programs, but definitions vary across vendors: some treat any external user as third-party, while others reserve it for privileged or production access. For that reason, organisations should define whether the scope includes human vendors only, or also their service accounts, APIs, and delegated automation. That distinction matters because external access often inherits additional risk from shared devices, weak offboarding, and unclear accountability. The OWASP Non-Human Identity Top 10 is useful here because third-party access frequently becomes the entry point for exposed secrets, overbroad permissions, and unmanaged tokens.
The most common misapplication is treating a vendor login as equivalent to employee access, which occurs when access reviews ignore device trust, session duration, and downstream secret exposure.
Examples and Use Cases
Implementing third-party access rigorously often introduces friction for onboarding and support response times, requiring organisations to weigh operational speed against tighter auditability and shorter privilege windows.
- A managed service provider receives time-bound production access through Ultimate Guide to NHIs-style governance, with approvals, expiry, and session recording attached to each request.
- A software vendor uses a support account to diagnose failures, but the account is restricted to specific systems and monitored because vendor-issued credentials can still become part of an attack path, as shown in 52 NHI Breaches Analysis.
- A contractor is granted access through a privileged access workflow, with MFA, just-in-time elevation, and mandatory revocation at contract end. This aligns with the spirit of the OWASP Non-Human Identity Top 10, even though vendor identity structures vary.
- A cloud integration partner is allowed to call APIs, but the organisation limits scopes, rotates Secrets frequently, and records which service accounts were introduced by the third party.
These patterns are common in incident response, SaaS support, and outsourced operations, especially where an external team needs temporary access to investigate failures without receiving broad standing privilege.
Why It Matters in NHI Security
Third-party access becomes a security problem when it is granted too broadly, retained too long, or left unlinked to a clear owner. In practice, external users often accumulate access that outlives the business need, and that same access may extend to APIs, service accounts, and admin consoles. NHI programs care about this because external operators frequently touch the same systems that hold Secrets, automation tokens, and privileged workflows. NHI Mgmt Group research shows that Ultimate Guide to NHIs found 92% of organisations expose NHIs to third parties, which underscores how often vendor relationships create hidden identity sprawl. That exposure can turn a routine support arrangement into a durable attack surface, especially when offboarding is inconsistent or approvals are informal. The practical lesson is to pair vendor access with inventory, expiration, and revocation discipline, not just legal contracts and ticket notes.
Organisations typically encounter the real cost of third-party access only after a vendor account is abused, at which point access review, secret rotation, and session forensics become 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 | Third-party access often exposes secrets and overprivileged NHI pathways. |
| NIST Zero Trust (SP 800-207) | 3.1 | Zero Trust requires continuous verification for external users and sessions. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control directly applies to external vendor entitlements. |
Treat every third-party session as untrusted and verify context before each access grant.
