Third-Party Compromise

Expanded Definition

Third-party compromise describes a path of intrusion that enters through an external supplier, SaaS platform, contractor, or integration rather than a direct attack on the target itself. In NHI security, the concern is not only vendor breach exposure, but the delegated trust that lets a third party authenticate, call APIs, manage secrets, or move laterally with the target’s permissions. This makes the term broader than simple vendor risk, because the compromise may involve service accounts, tokens, certificates, CI/CD access, or agentic workflows that have been granted persistent authority.

Definitions vary across vendors on whether the event must begin with an actual vendor breach or can include abuse of over-privileged third-party access. NHI Management Group treats both as operationally relevant when external identity relationships become the entry point into the environment. The OWASP Non-Human Identity Top 10 frames this as an identity control problem, not just a procurement issue, because trust expansion is often invisible until access is abused. The most common misapplication is treating third-party compromise as a one-time vendor incident, which occurs when teams fail to examine the standing access, secret exposure, and downstream blast radius attached to the third party.

Examples and Use Cases

Implementing third-party risk controls rigorously often introduces tighter onboarding, more frequent access reviews, and faster offboarding expectations, requiring organisations to weigh operational convenience against reduced blast radius.

• A SaaS integration receives a long-lived API key, and the vendor’s environment is later compromised, allowing the attacker to reuse that key against production endpoints.
• A contractor’s CI/CD account is phished, exposing build secrets that were never rotated after project completion.
• An AI coding tool or automation agent is granted broad repository and deployment permissions, then becomes the path for secret theft or malicious commits, a pattern increasingly discussed in the Shai Hulud npm malware campaign.
• A supplier with privileged support access is not removed after a service contract ends, leaving dormant credentials available for abuse.
• A package ecosystem or third-party action is subverted, echoing the Reviewdog GitHub Action supply chain attack and similar supply chain pathways.

These scenarios align with the exposure patterns documented in the 52 NHI Breaches Analysis, where compromised non-human identities repeatedly enabled access beyond the original trust boundary. External guidance such as the OWASP Non-Human Identity Top 10 is useful for mapping those access paths back to identity control failures.

Why It Matters in NHI Security

Third-party compromise is dangerous because it turns delegated access into an attacker’s shortcut. When service accounts, API keys, certificates, or automation tokens are shared with external parties, the target inherits the vendor’s security posture without inheriting its controls. That is why NHI Management Group reports that 92% of organisations expose NHIs to third parties, a scale that makes supply chain abuse a routine concern rather than an edge case. The risk is amplified when secrets are stored outside managed vaults, when access is not tied to explicit business justification, or when revocation is delayed after a contract ends.

Practitioners should also treat third-party compromise as a governance failure, not only a technical incident. If a supplier can act with broad or persistent authority, then one external breach can bypass compensating controls inside the enterprise. Frameworks such as the OWASP Non-Human Identity Top 10 and the NHI security research published by NHI Management Group both point to the same operational conclusion: external access must be continuously scoped, rotated, and revoked. Organisations typically encounter the full cost only after a vendor incident exposes dormant credentials or a downstream system is abused, at which point third-party compromise becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How can organisations reduce blast radius after a third-party integration compromise?
• Who is accountable when a third-party identity compromise leads to customer exposure?
• Who is accountable when third-party trust relationships are exploited in a supply chain compromise?
• What breaks when a supplier compromise is treated as a normal third-party issue?