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.
At a glance
What this is: ClearVector argues that third-party access looks like NHI at runtime, but should remain a separate category because external control changes the governance and detection problem.
Why it matters: IAM and security teams need separate treatment for third-party lineage, because ownership, accountability, and compliance obligations differ even when the access pattern looks machine-like.
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.
👉 Read ClearVector's analysis of why third-party access should stay separate from NHI
Context
At runtime, third-party access can resemble ordinary non-human identity activity, but the governance question is different. Non-human identity tells you the actor is not a person. Third-party tells you the identity is controlled outside your organisation, which changes lineage, oversight, and incident attribution.
That distinction matters because external access inherits risk from another organisation's security posture and operating model. For IAM, IGA, PAM, and detection teams, the issue is not only what the account does in production, but who controls the originating identity and how quickly that control can be traced back when behaviour changes.
Key questions
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. Process and network telemetry only becomes useful when it preserves credential and role context. That lets teams tell the difference between expected automation and unauthorised activity before the workload state changes again.
A: Risk rises because engineers will route around friction. If the approved path is harder than the shortcut, teams may embed secrets in code, reuse human accounts, or skip ownership and rotation steps. A centralized, streamlined process reduces this drift and makes secure provisioning the easiest path, which is what actually drives adoption in day-to-day engineering.
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. Those signs suggest the reporting model is flattening distinct controller risk into a generic machine-identity bucket.
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.
Technical breakdown
Why third-party lineage changes runtime identity governance
A third-party workflow often contains multiple identity hops before activity reaches your environment. A human authenticates to the vendor's IdP, the vendor assumes a role in its own environment, and that role assumes another role in yours. At the point of action, the access looks like a normal NHI session, but the provenance chain reveals that control sits outside your organisation. That is why runtime similarity does not equal governance equivalence.
Practical implication: Track originating identity and trust lineage separately from the runtime role that appears in your logs.
Why compliance treats third parties differently from internal NHIs
Third-party access creates an oversight problem, not just an authentication problem. Regulators and auditors care about ownership, segregation of duties, and evidence that external access is reviewed as an external dependency. If third parties are collapsed into generic NHI reporting, the compliance view becomes harder to query and easier to dispute because vendor-controlled risk disappears into the aggregate.
Practical implication: Maintain separate review and reporting paths for vendor-controlled identities and internally owned NHIs.
How destructive vendor activity gets hidden inside NHI averages
Averaging third-party activity into the broader NHI population can conceal outliers that matter operationally. ClearVector notes that one vendor in its data performed 40 percent destructive actions, while the wider NHI population was only 3 percent destructive. That kind of spread is exactly why lineage-based segmentation matters: the dangerous pattern is the external controller, not the fact that the identity is non-human in shape.
Practical implication: Segment vendor access by controller and behaviour so destructive patterns remain visible in detection and review.
Threat narrative
Attacker objective: Use trusted third-party access to reach production environments and carry out actions that remain hard to attribute if lineage is not preserved.
- Entry occurs through legitimate third-party onboarding, where a vendor identity is granted production access under an approved trust relationship.
- Escalation happens through role chaining and inherited permissions, allowing the vendor-controlled identity to act inside the customer environment with effective access scope that may exceed the original intent.
- Impact follows when destructive or high-risk actions are taken under that trusted lineage, and the external controller behind the activity is obscured if third-party identities are not tracked separately.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Collapsing vendor access into NHI reporting creates identity blast-radius blind spots: Aggregation can make a small but risky population disappear inside a larger, quieter one. ClearVector's example of a vendor with 40 percent destructive activity shows why outliers matter more than averages in access governance. The implication is that detection, review, and escalation rules need segmentation by controller, not just by runtime permissions.
External trust should be measured as a distinct operational risk: Third-party access is not only a technical entitlement issue, it is an inherited security posture issue. The organisation can approve the role, but it cannot directly enforce the vendor's upstream authentication, posture, or internal role chaining. Security teams should therefore treat vendor lineage as a first-class risk dimension alongside privilege scope and session behaviour.
Separate populations produce better accountability than a unified machine-identity bucket: Humans, internally owned NHIs, and third-party identities behave differently enough that one governance model cannot explain them all. Clear separation makes it easier to ask who controls the identity, who can revoke it, and which compliance regime applies when behaviour changes. Practitioners should build identity views around ownership and provenance, not runtime resemblance.
Named concept: third-party provenance gap: This is the visibility loss that occurs when a vendor-controlled identity is observed only at the final hop, after its originating organisation has been abstracted away. The gap matters because the most actionable part of the trust relationship is the upstream controller, not the downstream role shape. Practitioners should preserve provenance if they want meaningful third-party governance.
From our research:
- 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.
- The broader governance lesson is covered in 52 NHI Breaches Analysis, which shows how identity lineage failures become real incidents.
What this signals
Third-party access will keep getting misclassified unless teams model controller ownership as a separate dimension from runtime identity shape. The practical shift is to treat vendor lineage as part of the access object, not as an annotation added later.
Third-party provenance gap: This is the governance blind spot created when a vendor-controlled role is observed only at the last hop. If your review process cannot answer where the access originated, your programme is measuring activity but not accountability.
With 92% of organisations exposing NHIs to third parties, according to Ultimate Guide to NHIs, the issue is now baseline operational design rather than an edge case. Teams should expect third-party lineage to become a standard audit question, not a special investigation.
For practitioners
- 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.
Key takeaways
- Third-party access is not just another NHI because external control changes the governance model, the response model, and the compliance model.
- Aggregating vendor-controlled identities into generic NHI reporting hides destructive outliers and weakens accountability for production access.
- Identity programmes should preserve provenance and controller ownership so third-party risk remains visible at runtime and during audit.
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, NIST SP 800-53 Rev 5 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 — Visibility and Inventory | Third-party lineage is only governable when external identities are separately inventoried. |
| NHI-03 — Secret and Credential Management | Third-party access often relies on credentials that must be tracked outside generic NHI pools. | |
| Recommendation — Inventory vendor-controlled identities separately and preserve provenance for every production access path. Apply stricter credential handling to vendor access and prevent external identities from blending into shared secret estates. | ||
| NIST CSF 2.0 | PR.AC-4 — Access Permissions and Authorisations | Third-party access requires explicit authorisation and differentiated permission governance. |
| Recommendation — Map vendor-controlled access to PR.AC-4 and review it as a distinct authorisation class. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | External controller risk increases when vendor roles have more access than required. |
| AU-3 — Content of Audit Records | Provenance and lineage must be captured so third-party accountability survives aggregation. | |
| Recommendation — Use AC-6 to constrain third-party roles to the minimum production scope they actually need. Log upstream identity lineage in audit records so vendor-controlled activity remains attributable. | ||
| NIST Zero Trust (SP 800-207) | Continuous Verification | Third-party trust should be continuously revalidated because the control plane sits outside the organisation. |
| Recommendation — Continuously verify external trust paths instead of assuming vendor access remains within its original risk boundary. | ||
Key terms
- Third-Party Provenance: The upstream identity chain that shows which external organisation controls an access path. In identity governance, provenance matters because runtime behaviour alone cannot reveal ownership, accountability, or revocation authority when a vendor role reaches your environment through chained assumptions.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
- Vendor-Controlled Identity: A non-human or delegated identity that is owned and operated by an outside organisation rather than by the environment it accesses. The runtime shape may resemble any other machine identity, but the accountability, review cadence, and incident response model must account for the external controller.
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.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on September 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
