Why do third-party vendors create identity and access risk?

Why This Matters for Security Teams

Third-party access is not just a procurement issue. It is an identity problem because vendors often receive direct entitlements into production systems, data stores, CI/CD pipelines, and APIs. That means their credentials, service accounts, and tokens become part of the organisation’s attack surface, even when the relationship is contractually narrow. The risk is amplified when access is long-lived, over-scoped, or shared across teams and environments. Current guidance from the OWASP Non-Human Identity Top 10 and NIST’s NIST Cybersecurity Framework 2.0 both point to the same operational reality: access must be measurable, limited, and revocable. NHIMG research shows why this matters at scale, with 92% of organisations exposing NHIs to third parties in the Ultimate Guide to NHIs. In practice, many security teams only discover the problem when a vendor credential survives an offboarding event or gets abused during a supply chain incident, rather than through intentional governance.

Third-party vendors often sit inside the trust boundary without being treated like internal identities, which creates a gap between contract language and actual access control. A vendor may need only one API, but receive persistent credentials that can reach multiple services, logs, and data paths. Once that happens, the organisation has inherited another lifecycle to manage: issuance, scoping, monitoring, rotation, and revocation. NHIMG’s 52 NHI Breaches Analysis shows how quickly weak identity hygiene becomes incident material, while the Top 10 NHI Issues makes clear that visibility and lifecycle control remain common failure points.

• Over-scoped vendor roles create lateral movement paths beyond the original business need.
• Persistent tokens and API keys remain usable long after a contract changes or ends.
• Shared or manually rotated secrets make attribution and containment difficult.
• Lack of telemetry means abnormal vendor activity is detected too late.

Security teams should map every vendor entitlement to a named owner, a specific business purpose, and a revocation path that works under incident conditions. In practice, controls tend to break down when vendors integrate through legacy service accounts because the access is embedded in pipelines and application code.

How It Works in Practice

The practical risk comes from how third parties are usually onboarded: a business owner asks for access, a vendor is given a role or token, and the credential is left in place to avoid disrupting operations. That pattern is efficient, but it is also how durable risk accumulates. Best practice is evolving toward least privilege, just-in-time access, and short-lived secrets, so the vendor can complete a task without carrying standing access indefinitely. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and slow rotation compound exposure, while the The 52 NHI breaches Report shows the downstream impact when these identities are compromised.

Operationally, strong vendor access governance usually includes:

• Separate identities for each vendor and each environment.
• Short TTL credentials, automatically revoked after the task or session ends.
• Policy-based approval tied to business purpose, not blanket RBAC alone.
• Continuous logging for token use, privilege escalation, and unusual API calls.
• Formal offboarding that removes access from applications, vaults, CI/CD, and backups.

For implementation, the most defensible models align with OWASP Non-Human Identity Top 10 and the access governance principles in NIST Cybersecurity Framework 2.0. Where possible, organisations should prefer workload identity over shared secrets so that the vendor’s system proves what it is, rather than relying only on a static password or API key. These controls tend to break down when vendors are embedded in CI/CD or code repositories because secrets are copied, reused, and difficult to inventory.

Common Variations and Edge Cases

Tighter vendor control often increases operational overhead, requiring organisations to balance speed of delivery against revocation certainty. That tradeoff becomes harder in regulated environments, managed service relationships, and software supply chain integrations where access must remain available for support but should not become permanent. There is no universal standard for this yet, but current guidance suggests treating vendor access as ephemeral wherever the workflow allows it.

Some vendors need machine-to-machine access, not human sign-in. In those cases, the identity should be a workload identity with narrowly scoped secrets and strong telemetry, not a shared administrative account. Other cases involve emergency support, where JIT elevation may be justified, but the elevation should be time-bound, logged, and tied to an approved incident or change ticket. This is where governance matters: vendors should not hold standing privilege merely because the business has not yet defined a better operating model.

For organisations building more mature controls, the practical next step is to inventory third-party NHIs, rank them by blast radius, and apply Ultimate Guide to NHIs lifecycle controls first to the highest-risk connections. The gap is often not policy intent, but the inability to remove access quickly when a vendor leaves, changes scope, or becomes compromised.

Related resources from NHI Mgmt Group

• Who should own third-party access risk in a banking GRC programme?
• Why do third-party integrations increase identity risk so quickly?
• Why do third-party relationships complicate identity and access management?
• Why do third-party vendors create so much identity risk?