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

At a glance

What this is: This analysis argues that third-party access failures are becoming legal, operational, and security liabilities because vendor identities are still not being continuously governed.

Why it matters: IAM, IGA, and PAM teams need to treat external vendor access as a lifecycle and verification problem, not a one-time onboarding issue.

👉 Read Unosecur’s analysis of third-party access risks and zero-trust governance gaps

Context

Third-party access security is the discipline of controlling and continuously verifying access granted to vendors, contractors, and service providers. The article argues that the core failure is not outsourcing itself but the gap between access granted and access continuously governed across the vendor lifecycle.

That gap now creates legal, compliance, and operational exposure in addition to security risk. For IAM and IGA teams, the relevant question is whether external identities are inventoried, reviewed, and deprovisioned with the same discipline applied to internal users and privileged accounts.

The article’s examples, including lawsuits tied to vendor-mediated exposure and a settlement involving third-party cloud access, show that weak third-party governance is no longer a narrow access-control issue. It is a board-level accountability problem with identity at its centre.

Key questions

Q: What breaks when third-party access is not reviewed continuously?

A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed. Without continuous review, teams rely on outdated certifications that do not reflect live permissions. The result is uncontrolled delegated access, especially across SaaS and OAuth-connected systems.

Q: Why does vendor access create regulatory risk even when the vendor caused the incident?

A: Regulators and plaintiffs usually focus on whether the organisation exercised reasonable oversight over third-party access, not only on who executed the intrusion. If external identities can reach sensitive data without strong review, monitoring, and offboarding, the customer organisation still carries accountability for governance failure.

Q: How can security teams tell if contractor access governance is working?

A: Look for whether access ends at the same point the business relationship ends, and whether the revocation is visible across every system the contractor touched. If the team cannot verify complete removal without manual chasing, governance is still fragmented.

Q: How should organisations set up vendor privileged access so third parties can do their jobs without creating unnecessary risk?

A: Start with a written access scope that limits each vendor to the systems, applications, and data they truly need. Pair that with Zero Trust controls, explicit approval before login, and recurring review of privileges. The goal is to balance operational access with continuous control, visibility, and least privilege enforcement across the vendor access lifecycle.

Technical breakdown

Why third-party access becomes a standing trust problem

Third-party access is risky because external identities are often granted broad, persistent privileges to support business operations. That creates a trust model where the organisation must assume the vendor, its devices, and its credentials remain safe after onboarding, even though the article shows that assumption fails in practice. Overprivileged access, stale accounts, and weak visibility all increase the blast radius when a vendor is compromised or misuses access. Zero trust only helps if every vendor request is evaluated as a fresh access decision rather than a continuation of old trust.

Practical implication: treat vendor access as continuously re-authorised access, not as a durable exception.

How third-party identity sprawl creates blind spots

The article points to forgotten accounts, unclear permission scope, and poor credential oversight as common failure modes. In identity terms, that is NHI sprawl across external users, service providers, and support centres, where access exists but ownership and review cadence do not. Once those identities are no longer actively tracked, they become shadow access paths that can persist long after the original business need changed. The governance problem is not only who has access, but whether the organisation can prove it knows where that access lives at any moment.

Practical implication: maintain a live inventory of third-party identities, permissions, and ownership so dormant access can be removed.

How vendor access becomes a compliance and breach multiplier

The article ties third-party failures to GDPR, HIPAA, and other regulatory exposure because data handling responsibility does not disappear when work is outsourced. If a vendor can access personal data, the primary organisation still owns the governance, monitoring, and disclosure burden. That makes third-party access a shared-risk channel where one weak vendor control can trigger legal claims, notification disputes, and reputational damage for the customer organisation. The technical issue is therefore inseparable from accountability: delegated access without delegated oversight is not governance.

Practical implication: align vendor access reviews, monitoring, and contract terms with the data and regulatory exposure carried by each third party.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.

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 has become a governance problem, not just a security problem. The article’s examples show that organisations are now facing lawsuits and regulatory consequences for what vendors did with granted access, not only for direct compromise of their own systems. That shifts the centre of gravity from perimeter defence to lifecycle governance, where entitlement scope, monitoring, and offboarding determine whether outsourced access is defensible. The practitioner conclusion is clear: external identity governance is now part of enterprise risk management.

Zero trust fails when third parties are treated as trusted exceptions. The article’s best-practice section correctly points to continuous verification, but the underlying issue is that many organisations still grant vendor access as if trust can be assumed after onboarding. That assumption does not survive a vendor compromise, a forgotten account, or an undisclosed breach. The practitioner conclusion is that vendor identities must be evaluated through the same never-assume model used for any high-risk access path.

Vendor access without lifecycle offboarding is the named failure mode this article exposes. The legal and security problems described here are not caused by outsourcing alone but by access that outlives the business relationship, the monitoring window, or the review cycle. Once access persists after need has changed, accountability becomes ambiguous and recovery becomes slower. The practitioner conclusion is that offboarding, recertification, and ownership assignment are the controls that determine whether third-party access remains governable.

Third-party access is now a test of whether IAM and PAM can operate across organisational boundaries. Contact centres, IT providers, and cloud vendors are not edge cases anymore. They are the places where identity governance meets shared operational responsibility, and that makes entitlement visibility, session control, and evidence capture part of the same control plane. The practitioner conclusion is that identity programmes that stop at the corporate boundary will continue to miss the highest-risk access paths.

Continuous monitoring is the difference between vendor trust and vendor assumption. The article shows that a vendor can remain technically “in scope” while operationally invisible for months. That is exactly where identity programmes fail: access exists, but no one can prove it is still justified, still used appropriately, or still aligned to the contract. The practitioner conclusion is that monitoring must be tied to entitlement review, not treated as a separate security activity.

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.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

External access should be governed as an always-on identity risk, because the practical failure mode is not just compromise but the persistence of permissions after trust has changed. Third-party trust debt: every unmanaged vendor entitlement increases the gap between granted access and defensible access, and that gap is what zero trust is supposed to close.

The governance lesson for IAM and IGA teams is that vendor oversight has to be tied to inventory, recertification, and revocation rather than contract onboarding alone. According to the Ultimate Guide to NHIs, 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

For practitioners

• Inventory every third-party identity and support account Build a single register of vendor users, contractor accounts, support logins, and shared service access so owners, purpose, and system scope are explicit.
• Right-size vendor privileges to the task Remove administrative or broad access from external identities unless the work explicitly requires it, and separate support functions from production data access.
• Certify third-party access on a fixed cadence Review vendor permissions against active contracts, current duties, and data sensitivity so stale access is removed before it becomes a silent exposure path.
• Tie vendor offboarding to identity deprovisioning End access when a contract, engagement, or support relationship ends, and verify that credentials, sessions, and backup accounts are disabled.
• Monitor vendor activity for unusual access patterns Track session activity, privilege changes, and access from unexpected locations so you can detect misuse or compromise before data leaves the environment.

Key takeaways

• Third-party access becomes dangerous when organisations treat vendor identities as durable exceptions instead of continuously governed access paths.
• The article shows that legal and regulatory exposure now follows from weak oversight of external identities, not only from the initial intrusion.
• Recertification, offboarding, and privilege scoping are the controls that determine whether outsourced access remains defensible.

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.
• Vendor identity inventory: A current record of the external identities, accounts, tokens, certificates, and integrations a supplier can use in an environment. It is essential for incident response because teams cannot revoke or validate access they have not explicitly mapped and assigned to an owner.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.

What's in the full article

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

• The article’s seven-category breakdown of third-party identity risks across credentials, visibility, and regulatory obligations
• The step-by-step mitigation checklist covering access limits, monitoring, due diligence, and risk-based vendor prioritisation
• The specific examples of JIT access, PAM logging, and entitlement review cadence used to reduce standing vendor privilege
• The vendor discussion of one-click audit evidence for ISO 27001, SOC 2, GDPR, and HIPAA

👉 Unosecur’s full blog adds the risk taxonomy, mitigation checklist, and vendor-specific examples.

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.