Third-party risk management is becoming identity governance

At a glance

What this is: This is a practical explainer on third-party risk management, with the key finding that vendor access becomes a security problem when identity governance is weak.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams all have to govern external identities with the same rigor as internal users, especially where third parties touch sensitive systems and data.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read SecurEnds' guide to third-party risk management and vendor access governance

Context

Third-party risk management is the discipline of identifying, assessing, and monitoring the security, compliance, and operational exposure introduced by external vendors and service providers. In practice, that means treating vendor access as an identity problem, not just a procurement or questionnaire exercise. When a third party can reach internal systems, the real risk sits in entitlement scope, authentication strength, and offboarding discipline.

The article’s core point is that vendor ecosystems expand the attack surface because access is often wider, longer-lived, and less consistently reviewed than teams assume. That is a familiar failure pattern across NHI governance as well: the account may be external, but the control failures are internal. For identity teams, the question is not whether to trust vendors, but how to make that trust revocable, auditable, and time-bounded.

Key questions

Q: How should security teams govern vendor access in third-party risk management?

A: Security teams should govern vendor access as a lifecycle problem. Each third party should have a named owner, a defined business purpose, a minimum permission set, and a clear end date. Access reviews, contract renewals, and termination workflows must all trigger revocation checks so that permissions do not outlive the relationship.

Q: Why do third-party accounts increase identity risk?

A: Third-party accounts increase risk because they often reach sensitive systems without the same day-to-day scrutiny as internal users. If authentication is weak, permissions are broad, or offboarding is incomplete, a vendor identity becomes a durable entry point for attackers and a persistent compliance exposure.

Q: What breaks when vendor offboarding is not tightly controlled?

A: When vendor offboarding is weak, access survives after the business need ends. That leaves dormant accounts, active tokens, and hidden integrations in place, which can be abused later by attackers or former suppliers. The result is standing exposure that no longer matches any approved relationship.

Q: Who is accountable when a third-party vendor keeps access after a contract ends?

A: The organisation that granted the access remains accountable, even if the vendor failed to request removal. Security, procurement, and application owners all share responsibility for making sure revocation happens across every connected system, because retained access is still retained risk.

Technical breakdown

Why vendor access becomes an identity boundary issue

A third party becomes part of the extended identity perimeter the moment it is granted access to internal systems, APIs, or sensitive data. The technical risk is not limited to login events. It includes how the account is provisioned, what it can reach, whether authentication is strong enough for the sensitivity of the access, and whether permissions are still valid after the work ends. This is why vendor risk and identity governance overlap so heavily. If entitlements are broad or persistent, a compromise in the vendor environment can become a direct path into customer systems. The control problem is lifecycle discipline, not just perimeter defense.

Practical implication: Treat every vendor account as a governed identity with explicit ownership, scope, and expiry.

Least privilege and access certification for third parties

Least privilege is the main technical control that constrains third-party blast radius, but it only works when permissions are assigned narrowly and reviewed repeatedly. In vendor environments, rights often drift because integrations expand, projects change, or business owners forget the original purpose of access. Access certification closes that gap by forcing periodic confirmation that the vendor still needs the permissions granted. Without certification, permissions that were appropriate at onboarding can remain in place indefinitely, which turns temporary operational access into standing exposure. This is especially risky where vendors can reach production systems, customer data, or privileged workflows.

Practical implication: Map vendor accounts to concrete business purposes and recertify them on a fixed cadence.

Vendor offboarding is a security control, not an admin task

Offboarding is where third-party governance either proves effective or fails. When a contract ends, a project closes, or a supplier relationship changes, access must be removed everywhere it exists, not just in the primary application. Many incidents begin with abandoned accounts, inherited tokens, cached credentials, or integrations that were never cleaned up. The technical issue is persistence: if access survives longer than the business relationship, it becomes unauthorized by default. That is why identity governance has to track vendor lifecycle events across account creation, approval, review, and deprovisioning. The process must be complete enough to eliminate hidden paths back into the environment.

Practical implication: Tie contract termination and service changes to automated deprovisioning across all connected systems.

Threat narrative

Attacker objective: The attacker aims to use the third party as a trusted foothold into the organisation’s internal environment and sensitive data.

1. Entry occurs when a vendor relationship creates access into internal systems, often through cloud, SaaS, or outsourced service integrations that are broader than the job truly requires.
2. Escalation happens when weak authentication, excessive privileges, or stale access lets an attacker move from the vendor account into connected customer systems or data flows.
3. Impact follows when the compromised third party becomes a supply chain path into confidential data, regulated workloads, or business-critical operations.

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 risk management fails when organisations treat vendor access as a static approval rather than a living identity relationship. The article’s lifecycle emphasis is correct, but the deeper point is that external identities age just like internal ones. If onboarding is visible and offboarding is weak, access becomes detached from the business reason it was granted. Practitioners should read this as a governance failure in the identity lifecycle, not as a procurement deficiency.

Least privilege for vendors is only meaningful when the organisation can prove the minimum necessary scope at every stage of the relationship. Vendor access often starts narrow and expands silently as integrations, support needs, and operational exceptions accumulate. That creates privilege creep across third-party accounts, which is why certification, scope review, and entitlement ownership must be continuous. The practitioner takeaway is simple: if nobody can explain why the vendor still has a permission, the permission is already a liability.

Vendor offboarding is the control that determines whether third-party trust is temporary or permanent. The article correctly highlights deactivation, but NHIMG’s position is that the real governance issue is residual access after the relationship ends. Abandoned accounts, stale tokens, and surviving integrations are not edge cases, they are the predictable outcome of unmanaged lifecycle handoffs. Security teams should treat offboarding as the final enforcement point for vendor accountability.

Third-party access governance should be measured by revocability, not just approval quality. Approvals can be well documented and still leave an organisation exposed if the access cannot be reviewed, traced, and removed quickly across every connected system. That shifts the operational question from “was access granted properly?” to “can access be reliably withdrawn when the business relationship changes?” Practitioners should prioritize revocation speed and completeness as core governance metrics.

Vendor ecosystems are now a primary identity-security problem, not a sidecar risk domain. Cloud services, SaaS platforms, contractors, and outsourced operations all create identity dependencies that cross security, compliance, and resilience functions. The most mature programmes will stop separating vendor risk from identity governance and will unify them under one entitlement model. That is the only way to reduce supply chain exposure at scale.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• The same study found that enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a deeper governance lens, see The 52 NHI breaches Report for root cause patterns that mirror vendor-access failure modes.

What this signals

Third-party access is increasingly governed through the same lens as non-human identity, because both fail in the same place: lifecycle control. The practical shift for IAM and IGA teams is to stop measuring only onboarding completeness and start measuring revocation certainty, especially where vendors touch production data or shared infrastructure.

Identity blast radius: this is the distance between a vendor’s legitimate task and the amount of enterprise exposure created by its credentials. The more broadly a third-party identity is scoped, the more damage a single compromised account can create, which is why entitlement scope, review cadence, and offboarding completeness need to be managed as one control surface.

The next phase of third-party governance will be operational, not policy-driven. Organisations will need clearer ownership between procurement, security, and system teams, plus evidence that vendor access can be removed everywhere it exists, including cached secrets, dormant accounts, and secondary integrations.

For practitioners

• Build a complete third-party identity inventory Track every vendor, contractor, integration, token, and service account in one place, with owner, purpose, data access, and expiry date recorded for each relationship.
• Tie access to contract lifecycle events Make onboarding, renewal, scope changes, and termination trigger access review and deprovisioning workflows across all systems, not just the primary application.
• Enforce least privilege on external accounts Remove broad permissions from vendor identities, assign only the minimum role required for the stated task, and require business justification for any exception.
• Certify third-party access on a fixed cadence Run recurring access certifications for vendors with production, customer data, or privileged access, and revoke anything the owner cannot rejustify immediately.
• Verify offboarding across all connected systems Check for leftover credentials, dormant accounts, cached secrets, and API connections after a vendor relationship ends, because access often survives in places the contract owner never sees.

Key takeaways

• Third-party risk becomes an identity problem the moment a vendor can reach internal systems or sensitive data.
• The evidence points to lifecycle failure, not just bad initial approval, because vendor access often persists after the business need ends.
• The control that changes outcomes is complete revocation across every connected system, backed by repeated access certification.

Key terms

• Third-party risk management: Third-party risk management is the process of identifying, assessing, and monitoring the exposure created by vendors, contractors, and service providers. In identity terms, it governs who outside the organisation can access systems, data, or workflows, and whether that access remains appropriate over time.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party’s access when a contract ends, a role changes, or a service is no longer needed. It includes deactivating accounts, revoking tokens, removing integrations, and verifying that no residual access remains in connected systems.
• Access certification: Access certification is a periodic review process used to confirm that granted permissions are still necessary and correctly scoped. For third parties, it is a critical governance checkpoint because vendor access tends to persist unless owners actively reapprove, reduce, or remove it.
• Identity blast radius: Identity blast radius is the amount of damage a single account can create if misused or compromised. For third-party identities, it depends on privilege scope, system reach, and how quickly access can be revoked across every connected platform.

Deepen your knowledge

Third-party risk management and vendor identity lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for external accounts and service access, it is worth exploring.

This post draws on content published by SecurEnds: third-party risk management and identity governance for vendor access. Read the original.