At runtime, a third-party vendor's access looks almost identical to any other non-human identity. Here is why ClearVector still gives third parties a category of their own.
At runtime, a third-party vendor's access into your production environment looks almost identical to any other non-human identity. A role assumption here, an API call there, a read from a storage bucket. If the shape of the activity is the same, why not simply count third parties as non-human identities and move on?
Because "non-human" describes what the identity is. "Third-party" describes who controls the identity. Those are different facts, and the second one reshapes the risk, the compliance obligation, and the kind of detection the identity requires.
An external control plane is a different risk
You provisioned your own service accounts and execution roles. You did not provision a vendor's security posture. When a third party holds access into production, you have inherited risk owned and operated by an external organization, on the strength of a trust relationship rather than a control you enforce yourself.
That trust relationship is a favored path for the adversary. SolarWinds remains the reference case: legitimate third-party access, abused to reach thousands of downstream environments. The 2026 supply-chain compromises documented in our Identity Intelligence Report follow the same logic, riding trusted vendor software and trusted publishing workflows into environments that never carried a direct vulnerability of their own. A third party can be entirely well-behaved and still be the route an adversary takes to reach you.
Compliance already treats third parties as a separate class
Auditors and regulators settled this question long ago. SOC 2, HIPAA, and PCI-DSS all require organizations to specifically track and elevate oversight of third-party access. Dissolve your third parties into one undifferentiated non-human population, and producing that view means untangling them after the fact, every time. A first-class third-party category turns the answer into a query instead of an investigation.
At runtime, provenance is the only thing that separates them
Consider an ordinary vendor workflow:
- A vendor employee, a human, authenticates to the vendor's own identity provider. The vendor assumes a role inside the vendor's production environment. That role, in turn, assumes a role inside your production environment. Activity follows.
Three identity types, human, non-human, and third-party, inside one routine vendor access flow. By the time the activity lands in your environment, the acting identity is a role, plainly non-human in shape. Only the lineage reveals that the role traces back to an external company rather than to your own automation. Break third parties out, and the originating identity resolves to a named vendor. Leave third parties folded into NHI, and you are watching a role with no idea which external organization controls that role.
The data: a small population with distinct behavior
Third parties are only 4 percent of active identities in AWS and GCP, the smallest of the three groups. Their activity does not resemble the non-human population they are so easily mistaken for.
One vendor in ClearVector's production data ran 40 percent destructive.
Consider the top four vendors in the report. All four hold 100 percent coverage across the production environment. Three of them, an observability vendor, a second security vendor, and a compliance vendor, run strictly read-only and earn a low-risk profile. One does not. Security Vendor 1 runs 60 percent read-only and 40 percent destructive: delete, terminate, and similar high-impact actions.
Set that 40 percent against the non-human population as a whole, which is 3 percent destructive. A single external vendor, operating at 40 percent destructive activity with full coverage of production, is precisely the signal that disappears the instant you average that vendor into an 87 percent NHI group that barely acts destructively at all. The separate category is what keeps the outlier visible. And like the broader non-human population, most third-party activity runs outside standard business hours on a periodic, scheduled cadence, nightly syncs, hourly scans, weekly compliance checks, so simple working-hours assumptions describe these identities poorly.
So, why break third parties out from non-human identities? Because the two labels answer different questions. "Non-human" tells you the identity is not a person. "Third-party" tells you the identity belongs to someone else, carries external risk, sits under a separate compliance regime, and, as Security Vendor 1 shows, can behave in ways your own automation never would. The only reliable way to hold that line at runtime is to map every action back to the originating identity, and to model the pattern of life of humans, non-humans, and third parties as three distinct populations. Lump the three together, and the most important vendor behavior is the first thing you lose.
%201.avif)
.png)
