Vendor access gaps are undermining zero trust identity controls

At a glance

What this is: This analysis says zero trust architectures still fail when vendor and contractor access is left outside enterprise-wide privileged access governance.

Why it matters: IAM teams need to treat third-party access as part of the identity perimeter, because continuous verification breaks down when external identities sit outside consistent access control.

By the numbers:

• Only 36% of health IT leaders say their organisations have a privileged access strategy applied consistently enterprise-wide.

Context

Zero trust only works when every identity that can reach a system is subject to the same access rules, verification, and monitoring. When vendor and contractor paths are exempted or handled inconsistently, the programme has a blind spot at the exact point where third-party access enters production systems.

In this article, Imprivata argues that vendor access is often underestimated inside zero trust programmes, even as organisations strengthen MFA, least privilege, credential vaults, and VPN replacement. For identity teams, the issue is not whether zero trust is valid, but whether third-party access has been brought under the same governance model as internal users and privileged administrators.

The practical test is simple: if a vendor can still reach sensitive systems through a separate path, separate process, or separate control standard, zero trust has not been applied uniformly. That makes vendor access governance a core identity security problem rather than a peripheral remote-access issue.

Key questions

Q: What breaks when vendor access sits outside zero trust governance?

A: Zero trust breaks at the boundary where third-party identities are treated as exceptions. The programme can still authenticate users, but it loses consistency if vendor accounts are approved, reviewed, and revoked through weaker or separate processes. That creates hidden trust, wider reach, and slower remediation when access needs to be removed.

Q: Why do third-party breaches keep happening even when MFA is in place?

A: MFA reduces some password-based attacks, but it does not stop token theft, session hijacking, or misuse of an already trusted vendor relationship. If the organisation does not verify device state, session behaviour, and relationship status, a valid login can still be the start of a breach. Strong authentication has to extend beyond the login screen.

Q: How should security teams govern vendor access in a zero trust programme?

A: They should treat vendor access as part of the core identity model, not as a separate remote support exception. That means applying the same authentication, approval, least privilege, and session oversight controls used for internal privileged users, then reviewing whether external access is still justified on a task-by-task basis.

Q: When does remote access become too broad for zero trust?

A: Remote access becomes too broad when it exposes a network path instead of a task path. If a vendor can pivot from one connection into multiple internal resources, the control is still network-centric rather than identity-centric. The safer model is application-level access with continuous re-checks of entitlement.

Technical breakdown

Why vendor access creates a zero trust exception

Zero trust assumes that trust is never implicit and that every request is verified based on identity, context, and policy. Vendor access often breaks that model because third-party accounts are provisioned for temporary operational needs, but are then managed through separate workflows, delegated ownership, or weaker reviews than employee access. That creates an access tier that can drift away from the control baseline. The result is not merely more exposure. It is a parallel trust boundary that may not be covered by the same entitlement, authentication, and session controls as internal identities.

Practical implication: fold vendor and contractor identities into the same policy, review, and session controls used for privileged internal access.

Why privileged access management matters for third parties

Privileged access management limits how high-risk access is granted, used, and removed. For vendors, that means access should be scoped to a named task, an approved system, and a defined time window, rather than held as standing access for convenience. The article’s emphasis on MFA, vaults, and least privilege reflects a common pattern: the more operational exceptions that exist for third parties, the more likely credentials and access paths become reusable beyond the original purpose. In practice, privileged access management is the governance layer that keeps vendor access from becoming permanent infrastructure.

Practical implication: require task-scoped third-party access approvals and remove standing vendor privileges wherever possible.

How remote access tools change the identity control model

Traditional VPN access exposes a broad network path, while modern remote access tools can enforce real-time identity verification and granular authorization at the session or application level. That shift matters because zero trust is not only about authentication at login. It is about re-evaluating access as the user or vendor moves through the environment. The architecture becomes more defensible when policy is tied to the resource being accessed, rather than the network the user lands on. For vendors, that reduces the size of the blast radius if credentials are abused or access is misrouted.

Practical implication: replace broad network access with application-level access decisions that re-check identity and entitlement continuously.

Breaches seen in the wild

• 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.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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

NHI Mgmt Group analysis

Vendor access is where zero trust programmes most often break at the governance boundary. The article shows a familiar pattern: organisations adopt continuous verification in principle, but then leave third-party access on a different operating model. That is not a tooling gap alone. It is a governance exception that weakens the identity perimeter and makes the programme less credible to auditors, security operations, and business owners. The practitioner conclusion is that zero trust must be measured by third-party coverage, not internal-user coverage alone.

Privileged access strategy is the control plane that turns zero trust into a usable operating model for vendors. Without it, third-party access becomes a mix of shared processes, manual approvals, and inconsistent revocation. That creates audit friction and increases the chance that access outlives the task. A disciplined privileged access model is therefore not an adjunct to zero trust, but the part that determines whether vendor access is truly constrained. Practitioners should treat third-party privilege as a core design input, not an exception case.

Continuous verification loses meaning when access pathways are not equally governed. The article highlights MFA, credential vaults, least privilege, and VPN replacement as interim measures, but the deeper point is that the programme must standardise how identities enter and operate inside the environment. If a vendor identity is authenticated strongly but authorised loosely, the architecture still carries hidden trust. The field should stop describing this as a remote-access issue and start describing it as identity governance debt.

Third-party access is now a zero trust maturity test, not a side control. Organisations that cannot consistently govern vendors, contractors, and fourth parties have not finished the identity boundary work that zero trust demands. That failure has direct implications for recertification, offboarding, and privileged session control because those processes must cover external identities with the same discipline as employee access. The practitioner conclusion is that maturity should be judged by lifecycle consistency across every identity class.

Identity blast radius is the right concept for understanding vendor exposure in zero trust. Vendor access is not dangerous simply because it exists. It becomes dangerous when one over-permissioned third-party path can reach too many systems too quickly. That is an architectural and governance problem, not just an authentication problem. Practitioners should map vendor access by blast radius, then remove the pathways that let one external identity behave like many internal ones.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Privileged Access Management Guide

What this signals

Third-party access is the missing layer in many zero trust programmes: organisations often authenticate users well but still leave vendor identities outside the same entitlement and offboarding discipline. That means the weakest part of the architecture is frequently not login, but lifecycle control over external access.

Identity blast radius is the right lens for external access governance: once a vendor account can reach too many systems, zero trust has lost its containment value even if authentication remains strong. Practitioners should measure how far a third-party identity can move, not just whether it can sign in.

For practitioners

• Standardise third-party access governance Bring vendors and contractors into the same approval, entitlement, review, and offboarding process used for internal privileged users so access is not managed through a separate exception path.
• Eliminate standing vendor privilege Replace persistent third-party access with task-scoped access windows and remove privileges as soon as the operational need ends.
• Require strong identity verification for remote access Use MFA and real-time identity checks for all external access paths, especially where vendors previously entered through VPN-based or broad network routes.
• Constrain vendor session reach Limit external identities to the specific systems and actions needed for the task so one vendor account cannot spread across the environment.

Key takeaways

• Vendor access is a zero trust governance problem when third-party identities are handled through separate approval and review paths.
• The article cites a major consistency gap, with only 36% of health IT leaders saying privileged access is applied enterprise-wide.
• Practitioners should extend privileged access, lifecycle controls, and session restrictions to vendors before calling the programme zero trust.

Key terms

• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Privileged Access: Privileged access is any elevated entitlement that can change systems, data, or security settings. When privilege is excessive or poorly scoped, a single compromised identity can create outsized blast radius across environments.
• Identity Perimeter: The identity perimeter is the access boundary defined by who or what is requesting entry, not by where the request comes from. In zero trust, it is the point where authentication, authorization, and risk context decide whether a caller can proceed.
• 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.

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.