Third-party access management still fails on basic identity controls

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Imprivata's blog post: Third-party access management still fails on basic identity controls, with shared accounts, weak MFA, broad permissions, and poor offboarding recurring across vendor access paths.

Why it matters: IAM, PAM, and NHI teams need to treat vendor access as a lifecycle problem, because weak identity control turns legitimate third-party connectivity into a durable breach path.

Context

Third-party access management is the governance problem created when vendors need real access to perform real work, but their identities, sessions, and permissions are often handled with employee-era controls. The result is a control gap between business dependence and identity assurance, especially when access is granted quickly and reviewed slowly.

Imprivata argues that the failure mode is not vendor access itself but the way organisations keep treating it as a static permission set instead of a lifecycle that must be verified, scoped, logged, and retired. That mismatch shows up in shared accounts, broad entitlements, weak MFA, and offboarding that only happens after a problem surfaces.

The article frames this as an operational risk for healthcare, manufacturing, financial services, and similar environments where vendor work is continuous and downtime is costly. In those settings, convenience pressure often overwhelms governance discipline, which is why the same basic identity mistakes keep reappearing.

Key questions

Q: What breaks when third-party access uses shared credentials?

A: Shared credentials break attribution, make monitoring less useful, and complicate incident response because logs cannot reliably map actions to a person. They also increase the chance that one contractor’s access becomes another contractor’s implicit trust path. The control failure is not only security, it is governance.

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 do security teams know whether vendor access is actually governed?

A: They should be able to answer three questions without delay: who has access, what they can reach, and how quickly access can be removed everywhere it exists. If the answers depend on spreadsheets, informal knowledge, or separate tool owners, governance is incomplete. A real control environment can prove scope and revocation end to end.

Q: What is the difference between just-in-time access and zero standing privilege?

A: Just-in-time access is the delivery pattern, while zero standing privilege is the policy goal. JIT grants access when needed and removes it after use. ZSP goes further by eliminating persistent access as the default state. Teams need both, but ZSP is the governance model that makes JIT meaningful.

Technical breakdown

Why shared vendor accounts break accountability

Shared accounts make it impossible to tie an action to a single person, which breaks investigation, certification, and offboarding. In third-party access, a generic vendor login also hides whether the approved worker is still the same person, still employed by the vendor, and still entitled to the system. That is why shared accounts are more than an audit nuisance: they remove identity continuity from the control plane. Once multiple people use the same credential, normal monitoring can show activity but not responsibility, and access reviews lose their meaning because the account no longer maps cleanly to one subject.

Practical implication: require named vendor identities and remove shared logins from any privileged workflow.

Why MFA alone does not secure vendor access

Multifactor authentication blocks some credential theft, but it does not prove that the session belongs to the right human, the right vendor relationship, or the right device state. The article points to token theft and session hijacking as the next step in attacker tradecraft, which means authentication can look normal even when the session is compromised. In practice, this shifts the problem from password strength to session integrity and contextual assurance. For third-party access, the trust decision has to extend beyond initial login and into device posture, location, session behaviour, and relationship status.

Practical implication: pair phishing-resistant MFA with device, location, and session-risk signals for vendor access.

Why standing privilege turns vendor access into breach fuel

Vendor access becomes dangerous when permissions stay broad after the work is done. Standing privilege gives third parties persistent reach into systems they only need briefly, which expands blast radius and makes compromise far more useful to an attacker. Just-in-time access and zero standing privilege reduce that exposure by collapsing the window in which elevated rights exist. The governance issue is not merely overprovisioning at onboarding; it is entitlement persistence after the operational need changes. That is why vendor access models must be time-bounded, task-scoped, and continuously reassessed.

Practical implication: replace persistent vendor privileges with just-in-time elevation and automatic revocation.

Threat narrative

Attacker objective: The attacker aims to convert a legitimate vendor identity into broad enterprise access that is hard to distinguish from normal third-party work.

1. Entry begins when attackers obtain valid vendor credentials through phishing, password reuse, credential stuffing, malware, or stolen tokens, then use that legitimate foothold to enter the environment.
2. Credential abuse follows when weak or missing MFA, shared accounts, or hijacked sessions let the attacker operate as a trusted vendor user without triggering obvious login failure signals.
3. Escalation occurs as broad network visibility, static permissions, and lingering access allow the attacker to pivot deeper into systems that the vendor account was never meant to control.
4. Impact is operational disruption, incident response cost, regulatory exposure, customer notification burden, and long-term loss of trust after the vendor path becomes a business outage.

Breaches seen in the wild

• 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.
• 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.

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

Third-party access is still governed as if vendor identities were stable employees, and that assumption is now the core failure. Vendor access is temporary, distributed, and operationally pressured, but many organisations still manage it through static approvals and broad permissions. That mismatch explains why shared accounts, weak MFA, and delayed offboarding keep recurring. The practitioner conclusion is clear: third-party access must be governed as a lifecycle, not a one-time grant.

Vendor accountability collapses when multiple people share one access path. Shared accounts erase the link between subject, action, and revocation, which makes recertification and incident reconstruction unreliable. This is not only a monitoring gap, it is a governance failure because ownership becomes unprovable the moment a credential is reused across a vendor team. The practical conclusion is that named identities are a prerequisite for credible vendor governance.

Ephemeral access debt: third-party privilege is often provisioned fast and retired slow, creating a lasting exposure window that outlives the original business need. That debt accumulates when teams optimise for uptime instead of entitlements, then discover later that the account, session, or trust relationship still exists. The practitioner conclusion is to treat vendor access duration as a control variable, not an administrative afterthought.

Basic identity controls still matter because third-party compromise is usually not exotic. The article’s own examples show that phishing, password reuse, credential stuffing, stolen tokens, and weak MFA remain enough to create serious enterprise impact. The implication for IAM and PAM teams is that the highest-value work is often the least glamorous: inventory, authentication strength, scoped privilege, session visibility, and offboarding discipline.

Third-party access management has become a Zero Standing Privilege use case, not a convenience feature. The business need for fast vendor access does not justify persistent reach into production systems. When access must exist, it should be time-bound, auditable, and tied to a specific task. Practitioners should read this as a signal that vendor governance now belongs in the same control conversation as privileged access and access lifecycle management.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Read next: Just-in-Time Access and Zero Standing Privilege Guide

What this signals

Ephemeral credential trust debt: many organisations still grant vendor access quickly, then leave the trust relationship intact long after the immediate task is done. That creates a standing exposure window that attackers can exploit through stolen credentials, session hijacking, or reused access paths.

Third-party access governance is converging with privileged access management because the control problem is no longer just who can connect, but how long the connection remains valid and how much damage it can do. The organisations that treat vendor identity as a lifecycle will be better positioned to contain compromise without slowing critical operations.

For practitioners

• Maintain a live third-party access inventory Track every vendor, the systems they touch, the business reason for access, and the internal owner who approves and reviews it. If the inventory is incomplete, every other control becomes assumption-based.
• Replace shared vendor logins with named identities Give each external user a unique account tied to a real person and remove generic or team-wide credentials from privileged workflows. That preserves accountability, makes monitoring usable, and turns offboarding into a deterministic process.
• Enforce phishing-resistant MFA plus session checks Use stronger authentication together with device posture, location, and session-risk signals so a normal login does not automatically equal trusted access. This is especially important where token theft and session hijacking are realistic threats.
• Scope vendor rights to the minimum needed Grant only the permissions needed for the task, then remove them automatically when the session or approval window ends. Persistent standing privilege is what makes a compromised vendor account so valuable.
• Automate offboarding and re-approval Trigger deprovisioning when a contract ends, a role changes, or a vendor account has been idle beyond the allowed period. Periodic re-approval should be mandatory, not optional, for every third-party identity.

Key takeaways

• Third-party access fails most often at the identity layer, where shared accounts, weak authentication, and broad permissions turn legitimate vendor work into a breach path.
• The article cites nearly half of organisations as having experienced a breach or attack involving a third-party vendor, which shows the issue is operational, not theoretical.
• Named identities, scoped privilege, and automated offboarding are the controls that most directly reduce vendor access risk and improve accountability.

Key terms

• Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
• 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.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.

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.