Third-party access should stay distinct from non-human identities

At a glance

What this is: This is an analysis of why third-party access should be governed separately from non-human identities, because who controls the identity changes the risk, compliance, and detection model.

Why it matters: IAM, PAM, and NHI teams need separate treatment for vendor-controlled access so that external lineage, destructive outliers, and regulatory oversight do not disappear inside a generic NHI bucket.

By the numbers:

• One vendor in ClearVector's production data ran 40 percent destructive.

Context

Third-party access and non-human identity management are related but not identical problems. Non-human identity describes the form of the credential or role, while third-party access describes external control, inherited risk, and the accountability gap that comes with vendor-owned access.

At runtime, the activity may look the same in logs and cloud telemetry, but the governance model is not the same. If a vendor controls the originating identity, security teams need lineage-aware oversight, not just a larger NHI inventory.

ClearVector's article uses production access patterns to show that third-party behaviour can be both low-volume and high-impact, which is why aggregation hides the cases that matter most.

Key questions

Q: What breaks when third-party access is merged into NHI reporting?

A: The main failure is that ownership, accountability, and external assurance disappear behind a generic machine-identity label. Teams can still see runtime activity, but they lose the ability to separate internally managed service accounts from vendor-controlled access, which makes audit answers slower, incident scoping weaker, and destructive outliers harder to spot.

Q: Why does third-party access create different compliance obligations?

A: Because the access is controlled by an external organisation, the governance question is no longer only what the credential can do. It is also who is responsible for its upstream posture, how that responsibility is reviewed, and whether the organisation can evidence oversight without reconstructing lineage after the fact.

Q: How should IAM teams track vendor-controlled access in production?

A: They should keep a separate third-party category with lineage, approval history, and scope data attached to each access path. That lets teams query risk by external organisation rather than by broad identity type, which is essential when one vendor can behave very differently from the rest of the machine population.

Q: How do organisations tell whether third-party access is becoming a blind spot?

A: Warning signs include rising production coverage by external vendors, unclear ownership of role chains, and risk reports that only describe total NHI counts. If destructive or high-impact actions cannot be isolated by originating organisation, the reporting model is already hiding the cases that matter most.

Technical breakdown

Why third-party access is not just another NHI

A third-party identity can behave like any other non-human account in the cloud. It may assume roles, call APIs, and read or modify resources through standard execution paths. The distinction is not operational shape but control ownership: the vendor manages the upstream identity, its security posture, and often the authentication boundary before any action reaches your environment. That makes the lineage of the action a governance signal, not just an audit detail. Practical implication: treat external control as a separate identity attribute, not a subcategory buried inside generic NHI inventory.

Practical implication: classify vendor-controlled access separately so lineage, ownership, and approval logic stay visible.

How provenance changes the risk model

Provenance is the link between the action you see and the organisation that actually controls the identity behind it. In a chained vendor flow, the acting role in your environment may be several steps removed from the human who initiated it. That distance matters because it creates inherited risk, where your controls govern the final hop but not the upstream posture that enabled it. The result is a different detection problem from standard workload identity monitoring. Practical implication: build lineage-aware detection that preserves the originating organisation across role assumptions.

Practical implication: preserve upstream identity lineage in telemetry so attribution does not collapse at the final role assumption.

Why compliance treats third parties as a distinct class

Auditors and regulators already expect third-party access to be tracked separately because the risk is external, not internal. That requirement aligns with governance frameworks such as SOC 2, HIPAA, and PCI-DSS, which ask organisations to elevate oversight of vendor access rather than merely count it among machine identities. When third-party access is merged into NHI reporting, the compliance answer becomes a reconstruction exercise instead of a routine control view. Practical implication: maintain a distinct third-party access register that can be reported without forensic cleanup.

Practical implication: keep third-party reporting separable enough to satisfy audit and regulator expectations without after-the-fact reconstruction.

Threat narrative

Attacker objective: The objective is to abuse trusted vendor-controlled access to reach downstream environments and operate with the authority of a legitimate third party.

1. Entry occurs through legitimate third-party access rather than through a direct vulnerability in the target environment, which is why the activity initially appears normal in logs.
2. Escalation happens when the external organisation's access is trusted into production and can reach resources at scale through assumed roles and inherited permissions.
3. Impact follows when a well-behaved vendor path becomes the route for destructive or broad downstream activity, making the external lineage the decisive risk factor.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party access and non-human identity are different governance classes. Non-human describes the identity form, but third-party describes external control, separate accountability, and inherited risk. Collapsing the two into one inventory hides the fact that the same runtime shape can sit under very different ownership and assurance models. The practitioner conclusion is simple: governance begins with control ownership, not with log similarity.

External lineage is the control boundary that matters most. A role assuming a role may look ordinary in cloud telemetry, but provenance tells you whether the access is controlled by your organisation or by another company. That difference changes review, escalation, and incident scoping because the risk is partly outside your enforcement boundary. The practitioner conclusion is that lineage must remain first-class in identity monitoring.

Third-party aggregation creates blind spots that matter most at the tail, not the average. ClearVector's analysis shows that a small vendor population can contain outsized destructive behaviour, and that signal disappears when the population is averaged into a broader NHI bucket. The important concept here is vendor outlier visibility: separate classification keeps the high-risk case from being statistically diluted. The practitioner conclusion is to retain third-party segmentation wherever destructive activity must remain visible.

Compliance already recognises third-party access as a distinct oversight problem. That is not because vendor accounts are technically exotic, but because they sit under a different assurance and accountability regime than owned service accounts. When organisations blur that line, they make it harder to answer basic questions about who is responsible when access is misused. The practitioner conclusion is to align reporting structures with accountability boundaries, not with identity shape alone.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: NHI Ownership and Accountability Guide

What this signals

Vendor-controlled access needs its own governance lane. When external companies own the upstream identity, the security team is no longer managing a standard NHI lifecycle. The practical boundary is provenance, not runtime shape, so access reviews and incident workflows have to preserve the originating organisation all the way through the chain.

Third-party segmentation is a visibility control, not just a taxonomy choice. Once vendor activity is averaged into general NHI reporting, destructive outliers become statistically invisible and the programme loses the ability to explain who can do what in production. The useful question is not whether the access looks machine-like, but whether the organisation can still isolate external accountability when it matters.

For practitioners

• Separate third-party access from NHI inventory Create a distinct classification for vendor-controlled access, with ownership, approval, and review fields that do not get merged into general NHI reporting.
• Preserve provenance in identity telemetry Tag each cloud action with the originating organisation and the chained role path so investigators can distinguish internal automation from vendor-controlled access.
• Review destructive vendor actions independently Track delete, terminate, and other high-impact actions as a separate third-party risk slice rather than averaging them into overall machine identity behaviour.
• Build audit-ready third-party reporting Maintain a queryable register that can answer which external organisations have production access, what they can do, and when that access last changed.

Key takeaways

• Third-party access can look like ordinary NHI activity in logs, but its governance problem is different because the upstream identity is controlled by another organisation.
• The most important risk is not volume but visibility. A small vendor population can contain destructive behaviour that disappears inside a broad NHI aggregation model.
• Separate classification, provenance tracking, and audit-ready reporting are the controls that keep external accountability from being lost in machine-identity reporting.

Key terms

• Third-Party Access: 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.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
• Inherited risk: Inherited risk is the exposure an organisation accepts through trusted suppliers, platforms, or integrations that can reach internal systems or data. It matters because the attack does not have to begin inside the organisation for the organisation to suffer the impact.
• Vendor Outlier Visibility: The ability to keep a small but high-impact external population visible when reporting and analytics would otherwise average it away. This matters when a vendor's access pattern differs sharply from the broader non-human population and must remain separately reviewable.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.