Why do third-party accounts increase identity risk?

Why This Matters for Security Teams

Third-party accounts are risky because they extend trust boundaries beyond the organisation’s direct control. A vendor login may be created quickly to unblock delivery, then left with broad access long after the original need has changed. That creates a weak point for persistence, lateral movement, and audit failure. The issue is not only authentication. It is also the lack of strong lifecycle control, visibility, and timely revocation across the partner relationship. The scale of the problem is easy to underestimate. In Ultimate Guide to NHIs, NHI Mgmt Group reports that 92% of organisations expose NHIs to third parties, and 97% of NHIs carry excessive privileges. Those conditions turn a contractor or supplier identity into a standing route into sensitive systems, which is exactly why the OWASP Non-Human Identity Top 10 places identity sprawl, overprivilege, and weak lifecycle governance among the core risks. NIST CSF 2.0 also frames this as an ongoing governance problem, not a one-time access grant, because identity assurance must be maintained throughout the relationship. In practice, many security teams discover the risk only after a vendor credential is reused, forgotten, or exposed, rather than through intentional review.

How It Works in Practice

A third-party account becomes dangerous when its access pattern is broader and less monitored than internal identities. That often happens in three ways: shared admin credentials, service accounts with no clear owner, and exceptions that bypass normal onboarding or approval flows. Once those identities reach production, they can act as durable footholds because offboarding is slow, key rotation is inconsistent, and no one is accountable for the account after the project ends. A practical control model starts with inventory, ownership, and purpose. Security teams need to know who requested the account, which systems it can reach, what secrets it uses, and when it must be revoked. The Top 10 NHI Issues guidance and the 52 NHI Breaches Analysis both show that compromise is rarely caused by a single failure. It is usually the combination of excessive permissions, exposed secrets, and weak revocation. NHI Mgmt Group also notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why access lingers. Operationally, stronger programmes usually combine:

• least privilege with time-bound access approvals;
• separate vendor identities for each supplier and use case;
• regular recertification of access and ownership;
• centralised secrets storage and rotation;
• rapid disablement when contracts, staff, or integrations change.

These controls tend to break down when third parties need emergency production access across multiple business units, because approval paths and ownership are often unclear.

Common Variations and Edge Cases

Tighter third-party access control often increases friction, so organisations must balance speed against assurance. That tradeoff becomes sharper in managed services, system integrator work, and legacy environments where vendors operate across many systems and account types. One common edge case is the “temporary” account that becomes permanent. Another is the shared service credential used by a vendor platform, where no individual can be tied to activity. Current guidance suggests these should be replaced with scoped, named identities or stronger workload identity patterns where possible, but there is no universal standard for every legacy scenario. In some environments, compensating controls such as PAM, JIT elevation, and network segmentation are the realistic path while migration is underway. NIST CSF 2.0 and the NIST Cybersecurity Framework 2.0 both support this layered approach, while The 52 NHI breaches Report illustrates how quickly exposed identities become incident paths when secrets are left valid too long. The main exception is tightly managed machine-to-machine integrations, where a third-party account may be necessary for automation. Even there, the best practice is evolving toward short-lived credentials, explicit scopes, and continuous review rather than permanent standing access.

Related resources from NHI Mgmt Group

• Why do third-party relationships create ongoing identity risk?
• Why do third-party integrations increase identity risk so quickly?
• Why do privileged accounts increase the risk of unlawful personal data disclosure?
• Why do low-code workflow platforms increase identity governance risk around signing?