Notifications
Clear all
Topic starter
14/09/2026 10:09 am
TL;DR: Third-party access should be governed as its own identity category because “non-human” describes the identity type while “third-party” describes external control, compliance scope, and lineage risk, according to ClearVector. Folding vendors into the broader NHI population hides provenance, masks destructive outliers, and weakens oversight.
NHIMG editorial — based on content published by ClearVector: Why break out third parties from non-human identities?
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
Questions worth separating out
Q: How should security teams handle runtime visibility for non-human identities?
A: Security teams should tie runtime visibility to the identities actually driving workload behaviour, including service accounts, tokens, and AI-driven automation.
A: Risk rises because engineers will route around friction.
Q: What are the signs that third-party access is being hidden inside NHI reporting?
A: Look for vendor-controlled activity that appears only as a final role assumption, broad production coverage from a small external population, and destructive actions that are diluted in aggregate dashboards.
Practitioner guidance
- Separate third-party identities from internal NHI inventories Create a distinct inventory field for external controller, vendor name, and trust source so vendor access is queryable without forensic reconstruction.
- Map identity lineage back to the originating organisation Preserve the full hop chain from human to vendor role to customer role so incident responders can identify who actually controls the access path.
- Segment monitoring by external controller and behaviour Build detections that flag destructive actions, unusual hours, and broad production coverage separately for third-party identities rather than blending them into generic NHI baselines.
What's in the full article
ClearVector's full blog post covers the operational detail this post intentionally leaves for the source:
- The full lineage example showing how a vendor human authenticates, assumes a role, and then reaches your environment through chained trust.
- The production data breakdown that separates read-only vendor behaviour from destructive vendor behaviour across the top external accounts.
- The runtime explanation of how provenance reveals which external organisation actually controls a role assumption chain.
- The argument for keeping third-party identities queryable as a distinct population rather than flattening them into generic NHI reporting.
👉 Read ClearVector's analysis of why third-party access should stay separate from NHI →
Third-party access vs NHI: what IAM teams need to separate?
Explore further
14/09/2026 10:10 am
Third-party is a control-plane distinction, not just an identity label: The runtime shape of access can be identical across internal NHIs and vendor-controlled identities, but the control responsibility is not. When an external company owns the origin of the access path, your governance model has to account for lineage, delegated trust, and outside-of-policy behaviour. Practitioners should treat third-party control as a separate governance class, not a subtype hidden inside generic NHI reporting.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: What is the difference between third-party access and ordinary NHI governance?
A: Ordinary NHI governance focuses on owned machine identities such as service accounts and tokens. Third-party access adds external control, inherited trust, and separate compliance obligations. The runtime permission may be similar, but the accountability model is different because another organisation sits at the top of the chain.
👉 Read our full editorial: Third-party access should stay distinct from non-human identities
