Why do third-party relationships create ongoing identity risk?

Because vendor access can persist after the original business need changes. That creates entitlement drift, where the approved relationship and the live access state no longer match. The longer the gap remains, the harder it becomes to prove who still has access and why.

Why This Matters for Security Teams

Third-party access is not a one-time approval. It is a living trust relationship that can outlast the contract, the project, and sometimes the original owner. That is why it becomes a continuing identity risk: vendors retain credentials, service accounts, API keys, and delegated access long after the business case has changed. NHI governance has shown how common this drift is, especially when visibility is weak and offboarding is inconsistent, as reflected in the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis.

The control problem is bigger than vendor management. If entitlements are not continuously reconciled, access reviews become paper exercises and no one can prove which third party still has operational reach. That is especially dangerous in environments where secrets live in code, CI/CD tools, shared vaults, or unmanaged integrations. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both reinforce the need for continuous access governance, not periodic reassurance.

In practice, many security teams encounter vendor access drift only after an audit finding, a breach, or a disputed offboarding request has already exposed the gap.

How It Works in Practice

Third-party relationships create risk because the identity lifecycle is split across procurement, legal, security, and operations, while the access lifecycle is often owned by only one of those teams. A vendor may be approved for a narrow task, but the underlying NHI can be reused across projects, inherited by a new contractor, or left active because no one owns revocation. Current guidance suggests treating vendor identities as workload identities with explicit expiry, scoped privileges, and continuous validation rather than as durable exceptions.

That means combining policy, technical enforcement, and evidence. Security teams should map each third party to a named business owner, an approved purpose, a defined time limit, and a revocation path. Just-in-time provisioning helps, but it only works when paired with lifecycle controls for secrets, API keys, certificates, and service accounts. The practical goal is to reduce standing access and make every entitlement traceable back to an active need. NHI programs also need evidence of what was actually used, not just what was approved, which is why the incident patterns in The 52 NHI breaches Report matter so much.

• Use contract end dates and technical TTLs that are linked, not separate.
• Review third-party entitlements after scope changes, not only during annual audits.
• Store secrets centrally and rotate them when access is no longer justified.
• Require logging that ties every privileged action to a vendor identity and business purpose.

For implementation alignment, the OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support least privilege, continuous monitoring, and controlled credential lifecycle management. These controls tend to break down when vendor access is embedded in shared automation, because ownership becomes ambiguous and revocation is easy to miss.

Common Variations and Edge Cases

Tighter third-party controls often increase friction for delivery teams, requiring organisations to balance faster onboarding against stronger revocation discipline. That tradeoff is real, especially where vendors support incident response, managed services, or production operations and cannot wait for manual approvals every time they need access.

Best practice is evolving for environments with many short-lived integrations, but there is no universal standard for this yet. Some organisations use blanket vendor roles, while others require per-project identities and JIT credentials. The safer pattern is to avoid shared accounts and prefer per-vendor or per-workload identities with clear expiry, but some legacy platforms still force exceptions. In those cases, the risk is not just excess privilege, but uncertainty about who can act, when, and under whose authority.

Edge cases also appear when a third party is embedded in CI/CD, software supply chains, or support tooling. A vendor may never log in interactively, yet still hold secrets that can be reused by automation or stolen from build systems, as seen in incidents like the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign. In those cases, the boundary between third-party risk and secret sprawl disappears unless identity, secrets, and telemetry are managed together.

When a vendor relationship expands across multiple systems, the access model usually fails first in shared infrastructure and long-lived automation, where no single team can see the full entitlement picture.

Related resources from NHI Mgmt Group

• Why do third-party vendors create so much identity risk?
• Why do third-party vendors create identity and access risk?
• Why do third-party relationships create persistent IAM and NHI risk?
• Why do fragmented workflow tools create identity governance risk?