Third-party breach patterns show where credential and vendor risk converge

At a glance

What this is: This is SecurityScorecard's analysis of how third-party breaches, credential abuse, and shared infrastructure drive repeatable data-loss patterns across sectors.

Why it matters: It matters because IAM, PAM, and third-party access governance must now account for vendor pathways, stolen credentials, and downstream exposure rather than only direct enterprise access.

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.
• Retail and hospitality companies face the highest relative rates of third-party breaches of any industry, with 52.4% of all breaches in this sector originating from third parties.

👉 Read SecurityScorecard's analysis of third-party breach patterns and enterprise exposure

Context

Third-party breach analysis is really access governance analysis in disguise. When vendors, cloud services, and downstream processors hold valid credentials or privileged pathways into an environment, the organisation inherits risk it does not fully control. That creates an identity problem as much as a supply chain problem, because stolen credentials and delegated access are what let attackers move from one compromise to many.

SecurityScorecard's examples show the same pattern across MOVEit, healthcare, Microsoft 365, and developer-targeted social engineering: attackers look for reusable credentials, overbroad access, and monitoring gaps around non-interactive or indirectly inherited access. For IAM and PAM teams, the lesson is that third-party exposure cannot be treated as a procurement checkbox; it must be governed as a living entitlement surface.

Key questions

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. Third-party relationships often include API keys, service accounts, delegated tokens, and non-interactive sign-ins that are easy to forget and hard to monitor. That creates a persistent exposure surface attackers can replay after a supplier breach.

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. Once an attacker has valid access, they inherit the subject’s trust context and can often blend in with normal activity. That makes credential theft far more efficient than direct exploitation in many environments.

Q: How should security teams measure whether supplier risk monitoring is actually working?

A: Look for evidence that monitoring changes decisions. Effective programmes reduce the time between a new supplier issue and an access or remediation action, and they can show which identities, systems, and relationships were affected. If risk scores are generated but never drive segmentation, revalidation, or ticketed response, the monitoring is informational rather than operational.

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.

Technical breakdown

How third-party breaches turn into credential reuse at scale

Third-party breaches often become enterprise breaches because attackers do not need to invent a new path when credentials, tokens, or inherited access already exist. Once a vendor environment is compromised, stolen credentials can be replayed against downstream services, especially where MFA is absent, non-interactive sign-ins are under-monitored, or passwords are reused across environments. This is why shared infrastructure incidents create outsized blast radius: one credential set can unlock multiple customer estates. The technical issue is not only initial compromise but trust transitivity across connected systems.

Practical implication: Map every third-party access path to the credential type it depends on and remove any standing access that can be replayed outside its intended boundary.

Why non-interactive sign-ins and Basic Authentication remain blind spots

Non-interactive authentication flows are often used by applications, service integrations, and legacy tooling that cannot perform the same user-facing checks as modern interactive logins. That makes them attractive to attackers using stolen credentials, because activity may look legitimate in the wrong log source while bypassing MFA enforcement or alerting tuned only for human sign-ins. Basic Authentication worsens the problem by relying on static secrets with weak contextual controls. The governance gap is not just legacy technology, but incomplete log coverage and weak policy enforcement across sign-in types.

Practical implication: Inventory non-interactive authentication paths separately and enforce policy, logging, and MFA-equivalent controls where the protocol allows it.

How shared vendors create fourth-party exposure and concentration risk

A third-party breach is rarely contained to the first supplier. File transfer platforms, payment processors, managed service providers, and cloud services sit inside a web of downstream dependencies, so one compromise can cascade into fourth-party incidents with no direct relationship between attacker and victim. MOVEit demonstrated this clearly: a single zero-day in a widely used tool enabled broad, simultaneous exploitation across thousands of organisations. The technical pattern is concentration risk, where many organisations depend on the same externally operated control plane or data exchange path.

Practical implication: Classify shared services by blast radius, not just by vendor criticality, and test how quickly you can isolate a compromised supplier without waiting for contractual remediation.

Threat narrative

Attacker objective: The attacker wants scalable access to data and operations through the weakest upstream relationship, so one compromise produces many victims and faster monetisation.

1. Entry begins when attackers exploit a third-party vulnerability, phish developers, or replay stolen credentials against exposed accounts and services.
2. Escalation follows when those credentials reach privileged systems, non-interactive sign-ins, or vendor-linked environments with insufficient MFA and monitoring.
3. Impact comes from lateral movement into customer data, operational disruption, ransomware spread, or large-scale exfiltration across many downstream organisations.

NHI Mgmt Group analysis

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.

Credential replay is the named failure mode that makes these incidents repeat. The article shows how stolen passwords, Basic Authentication, and weak MFA coverage let attackers reuse access across unrelated environments. This is exactly where standing credential exposure and log blind spots converge, because access that persists or is invisible will be abused. The practitioner conclusion is to assume replay is the default attacker tactic and design controls around it.

Concentration risk now belongs in identity architecture reviews. MOVEit and Change Healthcare demonstrate that a single supplier, protocol, or shared service can become a systemic access corridor. For identity programmes, that means vendor segmentation, scoped access, and rapid revocation must be built into third-party onboarding and offboarding, not added after an incident. The practitioner conclusion is to measure blast radius before you approve the connection.

Identity telemetry must distinguish human sign-ins from machine and integration traffic. The Microsoft 365 campaign described in the article exploited non-interactive sign-ins, which many teams do not monitor with the same rigor as user authentication. That creates a governance gap where abuse is visible in the wrong log stream or missed entirely. The practitioner conclusion is to align detection coverage with authentication mode, not with user expectations.

Third-party breach patterns are accelerating because supply chains have become identity supply chains. The article's 6.5% increase in third-party-origin breaches reflects more than vendor concentration. It shows that every connected business process now depends on external entitlements, external secrets, and external monitoring quality. The practitioner conclusion is to audit supply-chain exposure as an identity lifecycle problem as much as a procurement one.

What this signals

Third-party breach response must be built around credential lineage. The practical challenge is no longer whether a supplier was breached, but whether your teams can trace which credentials, integrations, and non-interactive paths were exposed. That requires IAM and third-party risk teams to work from the same entitlement inventory, with monitoring that distinguishes human access from machine and vendor traffic.

Credential replay is now a board-level resilience issue. Once stolen passwords or tokens can be used across SaaS, cloud, and vendor ecosystems, the question becomes how fast you can revoke trust before lateral movement begins. The operating model should assume that supplier compromise will happen and that blast radius reduction is the main containment control.

Our research shows that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which makes supplier-connected secrets and service accounts impossible to ignore. That scale suggests most programmes still lack enough visibility to separate healthy machine access from exploitable persistence. Security teams should treat third-party identity hygiene as part of the same control plane as internal NHI governance.

For practitioners

• 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. Treat vendor access as a distinct control surface rather than an extension of employee IAM.
• 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. Remove or constrain any path that cannot support modern authentication or equivalent compensating controls.
• 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. Use that ranking to drive offboarding speed, segmentation, and contract requirements.
• Monitor for credential replay and account abuse across third parties Correlate password spraying, impossible travel, unusual non-interactive access, and vendor-linked account activity so stolen credentials are detected as a supply-chain issue, not just a user-login anomaly.
• Test incident containment against supplier compromise scenarios Run exercises that assume a shared vendor has already been breached and ask how quickly you can isolate the connection, revoke access, notify stakeholders, and validate whether downstream systems still trust the supplier.

Key takeaways

• Third-party breaches become enterprise-wide incidents when credentials, delegated access, and shared services are not governed as one access graph.
• SecurityScorecard's report shows third-party events now account for 35.5% of breaches, while healthcare, retail, and cloud incidents keep exposing the same replay patterns.
• IAM, PAM, and supplier-risk teams need revocation speed, authentication coverage, and blast-radius mapping before the next vendor compromise becomes a downstream breach.

Key terms

• Third-party breach: A third-party breach occurs when an external supplier, service provider, or connected partner becomes the entry point for compromise. The risk extends beyond the initial vendor because downstream organisations can inherit the exposure through trusted access, shared data flows, or integrated systems.
• Credential replay: Credential replay is the reuse of stolen authentication material to impersonate a legitimate user or system. In human identity programmes, replay risk grows when passwords, OTPs, or weak recovery flows can be captured and used from a separate device or session.
• Concentration risk: Concentration risk is the chance that many organisations depend on the same supplier, platform, or control point, so one compromise creates widespread impact. In cyber security, it is most visible when a widely used service or tool becomes a single failure point for multiple downstream customers.
• Non-interactive sign-in: A sign-in event that occurs without a user actively entering credentials in the moment. These events often represent token refresh, background application use, or service activity. In device code phishing investigations, they are a critical place to look for post-approval token replay and persistence activity.

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.

👉 SecurityScorecard's full article breaks down MOVEit, healthcare, M365, and supply chain breach patterns in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need a stronger control model for machine and supplier access. It is designed for security leaders building repeatable governance across identity, access, and privilege.