Notifications
Clear all
Topic starter
12/07/2026 12:23 pm
TL;DR: Third-party events accounted for 35.5% of breaches in SecurityScorecard's 2025 Global Third-Party Breach Report, with healthcare, MOVEit-related cascading exposure, and Microsoft 365 password-spraying campaigns showing how credentials, vendor access, and shared infrastructure turn isolated incidents into enterprise-wide risk. The governance lesson is that perimeter-only thinking fails once access is delegated, reused, or inherited across vendors and workloads.
NHIMG editorial — based on content published by SecurityScorecard: real data breach examples and third-party risk patterns
By the numbers:
- Our 2025 Global Third-Party Breach Report found that 35.5% of breaches originated from third-party events, a 6.5% increase from 2023.
- Our data breach report revealed that healthcare was responsible for 242 total breaches, accounting for 24.2% of all security incidents analyzed.
Questions worth separating out
Q: What breaks when third-party access is treated like ordinary employee access?
A: The control model breaks because vendor access usually carries broader blast radius, weaker lifecycle discipline, and more indirect authentication paths than employee access.
Q: Why do stolen credentials remain such an effective attack path?
A: Stolen credentials work because many systems still treat a successful login as enough evidence of legitimacy.
Q: How should security teams measure whether supplier risk monitoring is actually working?
A: Look for evidence that monitoring changes decisions.
Practitioner guidance
- Separate third-party entitlements from direct enterprise access Build a complete inventory of vendor accounts, delegated tokens, API connections, and service integrations so each can be reviewed, limited, and revoked independently.
- Enforce MFA and protocol controls on all cloud sign-in paths Identify non-interactive sign-ins, Basic Authentication use, and legacy authentication exceptions across Microsoft 365 and other SaaS platforms.
- Classify suppliers by blast radius and connectivity Rank vendors by how many systems, customers, or operational workflows they can reach, then shorten revocation paths for the highest-impact relationships.
What's in the full article
SecurityScorecard's full article covers the operational detail this post intentionally leaves for the source:
- Per-industry breach examples, including the MOVEit cascade, healthcare incidents, Microsoft 365 abuse, and retail payment exposures.
- Expanded discussion of how the STRIKE Team traced third-party events into downstream compromise patterns.
- Vendor-managed risk framing that shows how the source team operationalises monitoring and remediation across supplier relationships.
- Additional examples of concentration risk and cross-sector dependency that help teams prioritise the highest-impact suppliers.
👉 Read SecurityScorecard's analysis of third-party breach patterns and enterprise exposure →
Third-party breach patterns and what IAM teams need to fix?
Explore further
12/07/2026 12:36 pm
Third-party breach management is now an identity governance problem, not just a supplier risk problem. The article's central pattern is that attackers move through valid credentials, delegated access, and inherited trust rather than only through software flaws. That means IAM and PAM teams must treat suppliers, SaaS platforms, and service accounts as part of the access graph, not as an external exception. The practitioner conclusion is simple: if you cannot govern the entitlement, you cannot govern the third-party risk.
A question worth separating out:
Q: Who is accountable when third-party cloud access is abused in a data breach?
A: Accountability should sit with the business owner of the identity, not only the platform team. Third-party access must have an owner, a review cadence, and a revocation trigger tied to the business relationship. If those controls do not exist, the organisation is effectively accepting unmanaged identity risk.
👉 Read our full editorial: Third-party breach patterns show where credential and vendor risk converge
