Third-party access management still fails on basic identity controls

At a glance

What this is: This is a third-party access management analysis arguing that common vendor access controls still fail because visibility, authentication, and offboarding are inconsistent.

Why it matters: It matters because vendor access now touches NHI, human, and delegated workflows, so IAM teams need controls that hold when trusted outsiders become operational insiders.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.

👉 Read Imprivata's analysis of third-party access management and breach risk

Context

Third-party access management is the discipline of governing external users, vendors, and service partners that need legitimate access to internal systems. In this article, the primary failure is not access itself but the assumption that vendor identities can be trusted once and then left alone.

That assumption breaks under the pressure of shared accounts, weak MFA, stale approvals, and incomplete offboarding. For IAM and PAM teams, the practical problem is that trusted vendor access often behaves like an unmanaged identity lifecycle, not a controlled exception.

Key questions

Q: How should security teams manage third-party access without creating vendor friction?

A: Start by assigning a single owner for every vendor relationship, then scope access to specific systems, tasks, and expiry dates. Use named identities, strong authentication, and automated revocation so vendors can work quickly without inheriting broad or permanent access. The goal is controlled access paths, not more manual approval steps.

Q: Why do vendor accounts create higher breach risk than internal user accounts?

A: Vendor accounts often combine external connectivity, broad permissions, and weaker lifecycle oversight, which makes them attractive to attackers and hard to govern. If the account is shared, long-lived, or poorly reviewed, a single compromise can become a trusted path into core systems. The risk comes from trust plus weak accountability.

Q: What breaks when third-party access reviews are handled manually?

A: Manual reviews fail when they depend on people remembering contract status, usage history, and offboarding steps. Access can remain active long after the vendor no longer needs it, especially when ownership is split across teams. The failure is not just slow review, but review without reliable revocation.

Q: Who is accountable when a vendor account is used in a breach?

A: Accountability should sit with the internal business owner for the vendor relationship, supported by security and procurement. If no one owns the lifecycle end to end, the organization cannot prove who approved, who reviewed, or who removed access. Frameworks such as NIST CSF and Zero Trust expect clear ownership and controlled access.

Technical breakdown

Why vendor access becomes a standing privilege problem

Vendor access often starts as a narrow exception and then expands into broad connectivity, because urgency pushes teams toward the fastest path. The article shows how VPN access, broad network reach, and lingering permissions can outlive the original business need. When that happens, the vendor user behaves less like a temporary collaborator and more like a standing privileged identity with weak governance. The technical issue is not simply overpermissioning. It is the absence of tight entitlement scope, expiry enforcement, and consistent ownership across the approval chain.

Practical implication: enforce bounded access paths with automatic expiry and explicit business ownership for every third-party entitlement.

How authentication gaps turn legitimate access into breach entry

The article highlights a familiar failure mode. Attackers do not need to break primary authentication if they can obtain valid vendor credentials through phishing, password reuse, credential stuffing, or token theft. Once a session is established, weak or missing MFA, session hijacking, and poor device checks allow the attacker to appear legitimate. In practice, the control failure is not just MFA absence. It is the lack of layered identity assurance that verifies the person, the device, and the session continuously, especially when access comes from outside the enterprise boundary.

Practical implication: pair phishing-resistant MFA with device posture and session-risk checks for all third-party access.

Why offboarding and review are the real lifecycle controls

Third-party access often fails after the initial approval moment, not before it. The article points to stale access that is never revoked, inconsistent re-approval, and relationship changes that are not reflected in entitlements. That creates an unmanaged lifecycle where access can persist after a contract ends or after the vendor user no longer needs it. The mechanism is simple: if reviews are manual, slow, or disconnected from vendor status, the environment accumulates dormant access that remains valid long after accountability has disappeared.

Practical implication: automate deprovisioning triggers and periodic recertification tied to contract status and activity.

Threat narrative

Attacker objective: The attacker aims to turn a trusted third-party identity into a reliable bridge into core enterprise systems and operations.

1. Entry begins when attackers compromise a vendor account through phishing, password reuse, credential stuffing, or malware and inherit legitimate access.
2. Escalation follows when weak or missing MFA, broad permissions, or stolen sessions let the attacker move from normal vendor login to trusted internal access.
3. Impact occurs as the attacker pivots through vendor connections into broader business systems, causing downtime, remediation cost, legal exposure, and loss of trust.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 access is really unmanaged identity lifecycle risk. The article shows that the hardest part is not granting access, but keeping ownership, authentication, review, and offboarding aligned across vendor relationships. When those controls fragment across IT, security, procurement, and the business, the result is not just access sprawl but a lifecycle that no one fully governs. Practitioners should treat vendor access as a governed identity population, not a temporary exception.

Standing privilege is the named failure mode this article exposes. The access model is designed for short-lived, task-specific vendor work, but in practice it often becomes persistent network reach with weak expiry discipline. That assumption fails when operational pressure causes teams to approve now and fix later, leaving access in place for months or years. The implication is that privilege duration, not just privilege level, is part of the risk boundary.

Shared vendor accounts destroy accountability before they weaken security. A shared login does more than complicate monitoring. It erases the link between person, task, and approval, which makes offboarding, investigation, and re-certification unreliable. Once a vendor team is operating through generic credentials, the organization no longer has a meaningful identity lifecycle to govern. Practitioners should treat shared accounts as a governance failure, not merely a control gap.

Session theft has made login-centric trust obsolete for third parties. The article correctly notes that attackers increasingly bypass passwords and work inside valid sessions. That means authentication success is no longer proof of legitimacy, especially for vendors working from unmanaged devices or external networks. IAM teams need to stop equating successful login with safe access and start governing the session as the real unit of trust.

Vendor access without lifecycle offboarding: The article's most durable lesson is that access outlives the business need when revocation depends on memory, manual follow-up, or inter-team handoffs. That is why periodic review alone is insufficient if entitlement removal is not triggered by contract end, inactivity, or ownership change. Practitioners should read this as a failure of offboarding design, not just policy enforcement.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to Oasis Security & ESG.
• This aligns with the broader breach pattern in 52 NHI Breaches Analysis, where credential exposure and access persistence repeatedly drive impact.

What this signals

Vendor access is converging with NHI governance. As third parties increasingly authenticate through tokens, session-based access, and delegated tooling, the old boundary between human external users and non-human access is thinning. IAM programmes should expect vendor access reviews, PAM controls, and workload identity governance to converge around the same lifecycle questions: who owns it, how long does it live, and how is it revoked?

Identity blast radius is now the metric that matters. When a vendor account can move from legitimate login to broad business disruption, the issue is not only whether access exists but how far it can travel once trusted. That is why teams should align their control model to Zero Trust, using NIST Cybersecurity Framework 2.0 alongside NHI lifecycle practices to reduce propagation paths.

With the 2024 ESG data showing 72% of organisations have experienced or suspect they have experienced an NHI breach, the governance gap is already large enough to justify tighter review cadence and better offboarding discipline. The practical signal is simple: if your vendor access can outlive the vendor relationship, your identity programme is carrying residual risk you do not fully see.

For practitioners

• Map every vendor identity to a named business owner Create a living inventory of each third-party user, what systems they can reach, and which internal owner approves that access. Remove approval paths that depend on email threads or service desk history.
• Replace shared vendor logins with unique named accounts Require a distinct identity for each external worker so approvals, logs, and offboarding remain traceable. Shared credentials should be retired because they make investigation and entitlement review unreliable.
• Enforce phishing-resistant MFA and session checks Combine strong MFA with device posture, conditional access, and session monitoring so valid credentials are not enough on their own. Treat token theft and session hijacking as first-class vendor access threats.
• Automate vendor offboarding and re-approval triggers Tie deprovisioning to contract end, inactivity, and relationship changes, then require periodic re-authorization for any remaining access. This stops vendor privileges from surviving after the business need has ended.

Key takeaways

• Third-party access becomes a breach path when ownership, authentication, and offboarding are not tightly linked to the business relationship.
• The evidence points to a persistent exposure pattern, with nearly half of organisations reporting third-party vendor breaches and many still relying on weak lifecycle controls.
• Practitioners should focus on named identities, phishing-resistant authentication, and automated revocation so vendor access cannot outlive its purpose.

Key terms

• Third-party access management: Third-party access management is the discipline of governing external users and vendor systems that need access to internal resources. It combines identity proofing, scoped entitlements, authentication, monitoring, and offboarding so outside parties can do their jobs without creating unmanaged trust.
• Standing privilege: Standing privilege is access that remains active beyond the moment it is needed. In vendor environments, it usually appears as persistent network reach, broad permissions, or dormant accounts that are left in place after the original task is complete, creating unnecessary exposure and weak accountability.
• Named identity: A named identity is a unique account tied to one person or one clearly governed non-human actor. It preserves accountability across approvals, logs, reviews, and offboarding. Shared logins remove that lineage and make it difficult to prove who accessed what, when, and under whose authority.
• Session hijacking: Session hijacking is the theft or reuse of an authenticated session so the attacker acts as a legitimate user without re-entering credentials. For vendor access, this matters because successful login no longer proves legitimacy if the session itself can be taken over and used for trusted internal access.

Deepen your knowledge

Third-party access management, identity assurance, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still treats vendor access as an exception, this course is a practical next step.

This post draws on content published by Imprivata: third-party access management, breach lessons, and best practices for reducing vendor access risk. Read the original.