Why do third-party breaches remain so difficult to reduce?

Why This Matters for Security Teams

Third-party breaches stay hard to reduce because vendor risk is usually treated as a point-in-time assessment instead of an access problem that changes every day. Security teams can rate a supplier’s controls, yet still leave the supplier connected to sensitive systems through old service accounts, broad API scopes, unattended tokens, or inherited trust from past integrations. That gap is exactly where compromise becomes operationally costly.

The practical issue is not whether a vendor completed due diligence. It is whether the vendor still has the minimum access required, whether that access is monitored, and whether it is removed when the business relationship changes. Control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls emphasise least privilege, account management, and continuous monitoring because static trust does not survive real-world vendor churn. In practice, many security teams encounter third-party exposure only after a compromised integration or stale credential has already been abused, rather than through intentional lifecycle governance.

How It Works in Practice

Reducing third-party breach risk means managing vendor access as a living inventory, not a procurement checkbox. The first step is to identify every external party that can reach systems, data, or production workflows, including SaaS providers, contractors, managed service providers, and automation tools. Then map what each one can actually do: read, write, execute, approve, export, or delegate. That map should be tied to business justification, owner accountability, expiry, and review cadence.

In mature programmes, the control focus shifts from “Is the vendor secure?” to “What can the vendor reach right now, and how is that access constrained?” That includes privileged accounts, machine identities, secrets, certificates, OAuth grants, and API keys. The rise of automation makes this harder, not easier. Guidance from the OWASP Non-Human Identity Top 10 is relevant because many third-party connections are effectively non-human identities with standing authority that outlives the original use case. Security teams should treat these identities like any other privileged credential, with rotation, scope reduction, and removal when no longer required.

• Maintain a live inventory of third-party access paths, not just a vendor register.
• Bind every external account or token to an internal owner and a business purpose.
• Use least privilege, short-lived credentials, and approval for scope expansion.
• Review logs for anomalous use, especially after support changes or contract renewals.
• Revoke access on termination, project close, or integration replacement.

Detection matters as much as prevention. Vendors often connect through trusted integrations, so alerts should focus on unusual data access, new geographies, atypical API volume, privilege escalation, and token reuse outside expected windows. Strong programmes also test whether a supplier can still reach systems after a contract ends, because revoked relationships sometimes leave behind orphaned access. These controls tend to break down when procurement owns the relationship, engineering owns the integration, and no single team is accountable for removing dormant access after the business need has changed.

Common Variations and Edge Cases

Tighter third-party controls often increase operational overhead, requiring organisations to balance faster delivery against stronger containment. That tradeoff is real, especially where vendors support production, incident response, or regulated processing. Best practice is evolving, but current guidance suggests that the right answer is not blanket denial. It is segmented access, clear expiry, and stronger verification of what a supplier can actually touch.

Edge cases usually appear where integrations are deeply embedded or partly invisible. Legacy systems may not support short-lived credentials, while some business-critical vendors need broad access during support events. In those environments, compensating controls become necessary: network segmentation, just-in-time elevation, dual approval for high-risk actions, and aggressive logging. There is also a growing intersection with AI-enabled third parties. The Anthropic report on the first AI-orchestrated cyber espionage campaign shows why autonomous or semi-autonomous tooling from third parties deserves the same access scrutiny as human operators. Where AI agents can call tools or act through delegated credentials, the real control question is provenance, scope, and revocation, not just vendor reputation.

There is no universal standard for this yet, but the direction of travel is clear: third-party risk becomes reducible only when access is continuously governed, not merely reviewed. For identity-heavy environments, that means treating vendors, scripts, and AI agents as part of the same delegated trust chain.

Related resources from NHI Mgmt Group

• How can organisations reduce blast radius after a third-party integration compromise?
• How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
• How can organisations reduce risk from third-party OAuth integrations?
• How do organisations reduce risk from third-party machine identities?