Third-party access risks expose the gaps in zero-trust governance

At a glance

What this is: This is an analysis of how third-party access risks turn vendor identities into legal, compliance, and breach exposure.

Why it matters: It matters because IAM, PAM, and lifecycle controls must cover external users with the same discipline as internal identities, or vendor access becomes a weak point across NHI, autonomous, and human programmes.

By the numbers:

• In September 2024, AT&T agreed to pay $13 million to settle a Federal Communications Commission investigation into a January 2023 data breach involving a third-party cloud vendor.

👉 Read Unosecur's analysis of third-party access risks and Zero Trust mitigation

Context

Third-party access risk is the governance problem that appears when an outside vendor is granted access to data, systems, or customer workflows and the organisation loses reliable control over what that vendor can do, for how long, and under what oversight. In identity terms, the issue is not only trust in the vendor, but whether access, certification, and offboarding controls are actually enforcing that trust boundary.

This article uses lawsuits against Adidas America and the University of Chicago Medical Center to show how vendor access failures become legal and regulatory events, not just technical incidents. The common pattern is stale oversight: organisations granted access, then failed to keep visibility, prove accountability, or revoke privilege with enough discipline.

For IAM and security teams, the key lesson is that third-party identities should be governed as first-class identities. That means clear entitlement boundaries, stronger lifecycle controls, and continuous monitoring that can stand up to breach disclosure, audit, and litigation scrutiny.

Key questions

Q: What breaks when third-party access is not tightly governed?

A: When third-party access is loosely governed, organisations lose control over who can reach sensitive data, which permissions are still needed, and whether old accounts remain active after the work is done. That creates a path from legitimate support access to unauthorized exposure, legal liability, and difficult incident reconstruction. The problem is usually lifecycle failure, not just bad authentication.

Q: Why do vendor identities create so much risk in cloud and support environments?

A: Vendor identities create risk because they often need broad, cross-system access to do real work, but that access is hard to verify continuously once the relationship begins. If entitlements are too wide or monitoring is too weak, one compromised external account can expose customer data, privileged workflows, or regulated records far beyond the original task.

Q: How do security teams know whether third-party access is actually under control?

A: Security teams know third-party access is under control when every external identity has a named owner, a narrow purpose, a review history, and a documented offboarding path. If any of those elements is missing, the organisation cannot prove that access is still justified. Auditability is the clearest sign that the programme is working.

Q: Who is accountable when a vendor breach exposes customer data?

A: Accountability usually sits with the organisation that granted the access, because regulators, customers, and courts look at whether oversight, monitoring, and revocation were adequate. The vendor may be the technical point of compromise, but the primary organisation is still responsible for proving that access was managed, reviewed, and removed when it should have been.

Technical breakdown

Why third-party access becomes a trust-boundary failure

Third-party access becomes dangerous when the vendor is treated as a one-time onboarding decision instead of an identity that must remain continuously governed. The technical failure is usually not a single credential, but a chain of over-entitlement, weak segregation, and incomplete monitoring across contact centres, cloud services, and support tooling. In practice, this creates a trust boundary that exists on paper but not in operational control. Zero Trust only works here when every request is evaluated, every entitlement is bounded, and every session is visible.

Practical implication: define external access as continuously verified identity, not as a static exception.

How overprivileged vendor credentials widen blast radius

Third-party identities often accumulate more privilege than the task requires, especially when vendors need broad access to support customers, resolve incidents, or move quickly during operations. Once those credentials are shared, reused, or left active after a contract changes, the blast radius expands from a single function to records, systems, and workflows far beyond the original purpose. This is why vendor access problems so often look like entitlement problems first and breach problems second.

Practical implication: scope vendor access by task and environment, then remove anything that cannot be justified at review time.

Why lifecycle controls matter after the contract ends

Third-party access does not end when the service relationship is assumed to end. If deprovisioning is slow, manual, or dependent on business teams remembering to notify security, dormant accounts can survive long after the vendor relationship changed. That creates zombie access, which is especially dangerous in regulated environments because the organisation can no longer demonstrate who still has access or why. Lifecycle governance is therefore the control layer that turns vendor oversight from policy into enforceable identity hygiene.

Practical implication: tie vendor offboarding to contract termination, not to informal operational handoff.

Threat narrative

Attacker objective: The attacker aims to use trusted vendor access to reach sensitive customer data while avoiding immediate suspicion inside the primary organisation.

1. Entry occurs through a third-party contact center or cloud vendor that already has legitimate access into customer-facing or support workflows.
2. Escalation happens when the vendor’s credentials or permissions are broader than necessary, allowing access to sensitive records or deeper systems.
3. Impact follows when exposed data, including personal and medical information, is retained, copied, or disclosed without effective detection or containment.

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 now a lifecycle problem, not a vendor-management side issue. The lawsuits discussed in this post show what happens when external identities are granted access but not governed with the same discipline as internal accounts. Entitlement scope, monitoring, and offboarding are all part of the same control chain. The practitioner takeaway is simple: if a vendor can still reach data after the business thinks the relationship changed, the lifecycle failed.

Zero Trust for third parties fails when the organisation still trusts the onboarding event. The article’s examples show that access is often granted once and then assumed to remain acceptable until something breaks. That is a control gap, not a philosophy gap. The implication for teams is that external identity policy must be evaluated at the session and entitlement level, not at the procurement stage.

Vendor access without lifecycle offboarding is the failure mode this article exposes most clearly. Stale permissions, delayed revocation, and incomplete visibility allow vendor access to outlive the business relationship that justified it. That is why lawsuits increasingly focus on oversight rather than the vendor’s presence alone. Practitioners need to treat offboarding proof as a control objective, not an administrative afterthought.

Third-party identity sprawl creates identity blast radius outside the organisation’s direct control. When support centres, cloud vendors, and service providers are all in the access path, one weak link can expand exposure across multiple systems and legal obligations. The governance implication is broader than breach response. Security teams need a defensible model for who is accountable when external identities touch regulated data.

The market is moving toward continuous entitlement review and evidence-driven access governance. The pattern in this article rewards organisations that can prove what access existed, who approved it, and when it was removed. Static recertification is not enough when vendors operate in fast-moving service environments. The practitioner conclusion is that third-party identity governance must be auditable by design, not reconstructed after an incident.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, 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, including 46% that confirmed one and 26% that suspected one.
• For a broader breach lens, see 52 NHI Breaches Analysis for root-cause patterns that turn access oversight into incident exposure.

What this signals

Third-party access is converging with broader NHI governance pressure. The same control weaknesses that let vendor identities drift out of scope also affect service accounts, API keys, and other non-human identities. With two-thirds of enterprises already reporting a successful cyberattack from compromised non-human identities, the operational lesson is that external access reviews cannot remain a separate process from machine identity governance.

Identity blast radius is becoming the more useful design metric. The real question is no longer whether a vendor is trusted, but how far one compromised external identity can move before controls detect it. That shifts the programme conversation toward entitlement breadth, session visibility, and offboarding latency rather than simple onboarding checks.

Third-party governance now needs evidence that survives audit, litigation, and breach disclosure. The organisations that can show continuous access review, revocation timing, and accountability mapping will have a much stronger position when external access fails.

For practitioners

• Map every third-party identity to a named business owner Require each vendor account, service desk user, and support role to have a documented internal owner who can approve access, challenge exceptions, and validate removal when the relationship changes.
• Bind third-party access to task scope and expiry Issue vendor permissions only for the specific support function, environment, and duration required. Recheck whether the access still matches the contract and operational need before renewal.
• Certify external access on a fixed review cadence Review third-party entitlements with the same rigour used for privileged internal access, including dormant accounts, broad group membership, and delegated admin rights.
• Tie offboarding to contract termination evidence Do not wait for a manual security ticket to remove access. Build revocation into procurement closure, service exit, and vendor offboarding checklists so that privileges are removed immediately when the relationship ends.
• Monitor vendor sessions for data and lateral movement signals Watch for unusual file access, repeated authentication attempts, and movement into systems outside the vendor’s normal support scope, then isolate the account if the behaviour diverges from approved use.

Key takeaways

• Third-party access failures are not isolated vendor issues. They are identity governance failures that become legal, regulatory, and operational problems once oversight breaks down.
• The evidence in this article points to the same pattern repeatedly: access is granted broadly, monitored weakly, and revoked too late to prevent exposure.
• Practitioners should treat external identity lifecycle, entitlement review, and offboarding proof as core controls, not supporting documentation.

Key terms

• Third-Party Identity: A third-party identity is an account, credential, or access path used by a vendor, contractor, or external support provider to operate inside your environment. It must be governed like any other identity because its permissions can reach regulated data, internal systems, and privileged workflows.
• Identity Blast Radius: Identity blast radius is the amount of damage a single identity can cause if it is compromised or misused. In third-party contexts, it expands quickly when access is broad, poorly monitored, or left active after the work has ended, making containment and revocation critical.
• Vendor Offboarding: Vendor offboarding is the process of removing access, closing accounts, and confirming that external identities no longer retain entry into your environment after a contract or service relationship ends. Effective offboarding is evidence-based, tied to business termination, and designed to prevent dormant access from lingering.
• Zero Trust For External Access: Zero Trust for external access is the practice of verifying every vendor request instead of treating an outside party as trusted because it was previously onboarded. The model relies on continuous checks, narrow entitlements, and session-level controls rather than one-time approval.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• A category-by-category breakdown of third-party identity risk types, including how each one maps to access, compliance, and supply-chain exposure.
• The vendor-facing mitigation patterns behind just-in-time access, entitlement review, and continuous monitoring in live environments.
• The practical control examples tied to IT service providers, contact centres, and outsourced support workflows.
• The article's own Zero Trust framing and implementation emphasis for external identities.

👉 Unosecur's full blog covers the risk categories, case examples, and mitigation practices in more operational detail.

Deepen your knowledge

NHI governance, identity lifecycle management, and machine identity security 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 governance maturity, it is worth exploring.