Notifications
Clear all
Topic starter
19/08/2026 3:54 pm
TL;DR: Third-party and supply chain components appeared in 29% of breaches in Verizon’s 2024 DBIR, while SecurityScorecard and Cyentia found 98% of organisations had at least one third party breached in the prior two years. Sprocket Security argues that annual questionnaires and point-in-time pentests miss the vendor-connected attack paths attackers actually use, making continuous validation the operational gap.
NHIMG editorial — based on content published by Sprocket Security: Third-party attack surface testing and why vendor scope matters
By the numbers:
- 98% of organizations have a relationship with at least one third party that experienced a breach in the past two years.
- 29% of all breaches involved a third-party or supply chain component in Verizon’s 2024 DBIR.
- Only 41% of organizations say they have sufficient information to assess third-party security practices, despite 82% rating third-party risk as a critical priority.
Questions worth separating out
Q: What breaks when vendor access is treated as a separate compliance track?
A: The organisation loses sight of the real attack path.
Q: Why do third-party connections increase lateral movement risk in enterprise environments?
A: Because a vendor link often gives attackers a trusted foothold that bypasses normal perimeter assumptions.
Q: How should security teams judge whether a vendor control actually reduces risk?
A: Security teams should test whether the control changes attacker behaviour in production, not just whether it is enabled in the console.
Practitioner guidance
- Add vendor-connected assets to testing scope Include vendor-facing APIs, portals, integrations, remote admin paths, and inherited M&A infrastructure in the attack surface you actively test and track.
- Map third-party trust edges to identity controls Inventory which vendor accounts, tokens, certificates, and federation links can reach internal systems, then assign ownership for review and revocation.
- Trigger retesting on vendor change events Re-run offensive validation when a vendor adds an integration, expands cloud footprint, or changes access paths rather than waiting for annual cycles.
What's in the full article
Sprocket Security's full article covers the operational detail this post intentionally leaves for the source:
- How to define vendor-facing network segments and API integrations in a penetration testing scope
- How Continuous Offensive Security Testing changes retest triggers when vendor exposure changes
- How the platform maps shadow IT and vendor-connected assets that traditional scoping often misses
- How findings are returned into operational workflows after human validation
👉 Read Sprocket Security's analysis of vendor-connected attack surface testing →
Vendor-connected attack paths: is your testing scope still enough?
Explore further
19/08/2026 4:31 pm
Vendor access is identity governance, even when the vendor owns the account. Once a third party can reach your systems, the problem is no longer purely supply chain hygiene. It becomes access governance, privilege scope, and lifecycle control across identities you do not directly administer. That means IAM and PAM teams must account for external trust edges, not just internal users and service accounts. The practitioner conclusion is simple: if a vendor can touch data, it belongs in identity governance.
A question worth separating out:
Q: Who should be accountable when third-party access is abused?
A: Accountability should sit with the teams that own the access path, the detection logic, and the response workflow. Third-party access is not a special exception to identity governance; it is a high-risk access category that needs explicit ownership, monitoring, and containment rules. Without that clarity, the organisation can see the event but fail to respond decisively.
👉 Read our full editorial: Third-party attack surface testing is now an IAM governance issue
