Q1 2025 cyber risk coverage shows third-party exposure widening

At a glance

What this is: SecurityScorecard’s Q1 2025 press coverage roundup highlights growing attention on third-party breaches, software supply chain attacks, and cyber risk governance.

Why it matters: It matters because organisations relying on vendors, service providers, and downstream software dependencies need to treat third-party exposure as a governed security control problem, not a reporting exercise.

By the numbers:

• Breach coverage in Q1 2025 spanned North America, EMEA, and APAC press mentions.

Context

Third-party exposure becomes a governance problem when organisations can no longer separate their own controls from the controls of suppliers, partners, and downstream software dependencies. In this case, the article is a press and coverage roundup, but the security signal is broader: risk now accumulates across external relationships, including machine and non-human identities that operate beyond the direct boundary of the enterprise. That makes third-party oversight a control issue, not just a procurement issue.

SecurityScorecard’s coverage summary sits in the intersection of supply chain security, cyber risk governance, and identity-adjacent trust boundaries. The article touches vendor-driven exposure, software supply chain attacks, and third-party compromise patterns, all of which show why practitioners need inventory, accountability, and control ownership that extend beyond internal users and endpoints.

Key questions

Q: What fails when healthcare organisations rely on periodic vendor reviews for third-party access?

A: Periodic reviews miss the reality that healthcare vendor access, credentials, and support arrangements change continuously. By the time a questionnaire is completed, the vendor’s posture or access scope may already be different. In practice, that creates an exposure window where authenticated third parties can retain access longer than the business need justifies.

Q: Why do over-trusted integrations increase breach impact so quickly?

A: Because the integration inherits downstream access that often exceeds the task it was meant to perform. When one token, app, or service connection can reach multiple systems, attackers do not need to breach each target separately. They only need to capture the trusted bridge and use it as an access multiplier.

Q: What are the signs that third-party trust is out of control?

A: Common warning signs include unmanaged external accounts, long-lived tokens, unclear ownership of vendor-issued credentials, and inconsistent offboarding when suppliers change. If security teams cannot show which third parties can authenticate to sensitive systems and why, trust has moved beyond governance into assumption.

Q: How do organisations govern third-party NHI access safely?

A: They should treat vendor-linked tokens, service accounts and integrations as governed dependencies with an owner, a scope and a removal date. The access should be monitored continuously and revoked when the business relationship, environment or integration purpose changes. Without that discipline, vendor access becomes persistent trust rather than controlled access.

Technical breakdown

Why third-party exposure becomes a control boundary problem

Third-party risk becomes harder to govern when access, data exchange, and operational dependencies sit outside the organisation’s direct administration. In practice, the risk is not only that a supplier is compromised, but that the enterprise inherits the supplier’s exposure through accounts, integrations, software updates, support workflows, and shared credentials. That creates a boundary problem for IAM, PAM, and NHI governance because the effective trust perimeter now includes external entities that may not follow the same lifecycle, review, or offboarding discipline. Security teams need to understand that the weakest visible control is often not the only one that matters.

Practical implication: Treat external access paths and dependency chains as part of the governed trust boundary, not as a separate vendor-management spreadsheet.

How software supply chain attacks reshape identity assumptions

Software supply chain attacks often succeed because organisations trust code, build systems, and artefact distribution paths more than they verify them. When attackers compromise a third-party package, signing key, CI/CD runner, or update channel, they can inherit legitimacy at scale and move through environments without having to defeat each target individually. That matters for identity security because build and release systems increasingly behave like machine identities with authority to authenticate, sign, deploy, and update. The result is a trust cascade: one external compromise can create many internal ones, especially where service accounts, tokens, and automation privileges are already broad.

Practical implication: Map build and release tooling to the same trust and privilege controls used for high-risk machine identities.

What third-party breach governance needs beyond periodic review

Periodic vendor assessment is too slow for the pace of modern third-party compromise. Governance now has to include continuous visibility into who has access, what machine identities exist, where credentials are reused, and how external relationships are changed or revoked. That is especially true where third parties touch cloud workloads, developer pipelines, or customer support systems, because those paths often expose both human and non-human identities. The governance gap is not only poor visibility. It is the assumption that supplier exposure can be measured once and managed later.

Practical implication: Build continuous third-party access and credential governance into assurance, not annual review cycles.

Threat narrative

Attacker objective: The attacker objective is to turn one trusted external relationship into scalable access, theft, or disruption across multiple downstream organisations.

1. Entry begins when attackers abuse a trusted third party, supply chain dependency, or external access path to gain legitimate-looking foothold.
2. Credential access or execution follows through stolen tokens, compromised build tooling, malicious packages, or shared support workflows that carry inherited trust.
3. Escalation and propagation occur as the attacker moves through connected systems, reusing privileged integrations and automation paths across customers or environments.
4. Impact is broader exposure of data, services, or operational integrity, with the initial third-party compromise multiplying across downstream targets.

Breaches seen in the wild

• JumpCloud breach 2023: North Korean hackers breached JumpCloud and abused its device commands framework against a few customers; all admin API keys were reset.
• Mimecast certificate compromise 2021: SolarWinds attackers stole a Mimecast certificate that authenticated to Microsoft 365 Exchange and used it against a few customer tenants.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party risk is now an identity governance problem, not a vendor questionnaire problem. The article’s coverage pattern shows that external relationships are increasingly the route through which organisations inherit exposure. That means the relevant control question is who can authenticate, delegate, sign, or update on your behalf, and under what lifecycle controls. Practitioners should treat third-party access as governed identity infrastructure, not as a procurement appendix.

Software supply chain exposure creates a trust cascade that conventional perimeter thinking cannot absorb. Once a build system, package source, or signing path is trusted, compromise at that layer can fan out to many downstream environments. This is where NHI governance, secure build controls, and credential lifecycle discipline intersect directly. A single compromised automation path can behave like a high-privilege machine identity with enterprise-wide reach, so the control focus must move upstream.

Vendor-driven exposure is becoming a board-level metric because the blast radius is external by design. Enterprises can no longer assume that risk stays inside owned infrastructure when so many business functions depend on partners, SaaS providers, and outsourced software delivery. The result is a broader accountability problem: third-party governance has to show who owns revocation, who reviews trust changes, and who can prove that external access is still justified.

Third-party breach coverage is a signal that security ratings alone are insufficient as governance evidence. Ratings can help prioritise attention, but they do not prove that external identities are inventoried, scoped, or offboarded correctly. Practitioners need governance models that connect supplier assessments to access scope, credential age, and dependency criticality. Otherwise, the organisation has visibility without control.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.

What this signals

Third-party exposure is becoming the practical test of identity governance maturity. When suppliers, developers, and automation platforms can authenticate into the same environments as internal staff, the organisation is no longer managing a clean perimeter. It is managing a trust graph, and trust graphs fail when ownership, revocation, and visibility are inconsistent.

Machine identities are the hidden amplifier in third-party risk. External access is no longer only about human vendor users. Support tokens, API keys, certificates, CI/CD runners, and delegated service accounts expand the attack surface and create paths that are easy to forget but hard to contain.

Security teams should prepare for third-party assurance to become more evidence-driven. Governance conversations will increasingly require proof of credential scope, rotation, and offboarding rather than ratings alone. That shift aligns with OWASP Non-Human Identities Top 10 and with broader access control discipline across enterprise security.

For practitioners

• Inventory external trust paths Catalogue suppliers, SaaS integrations, build systems, and support channels that can authenticate or act on behalf of the organisation, including machine identities and delegated credentials.
• Reconcile third-party access with identity lifecycle Tie every external account, token, certificate, and API key to an owner, expiry date, and offboarding trigger so that access is removed when the business relationship changes.
• Review build and release trust controls Validate which third-party packages, signing keys, CI/CD runners, and deployment services can affect production, and restrict them to the minimum privilege needed for the workflow.
• Link vendor assurance to operational evidence Move beyond scorecards by requiring proof of active credential rotation, access reviews, and dependency changes for suppliers that can reach sensitive data or production systems.

Key takeaways

• Third-party breach coverage in Q1 2025 shows that external exposure is now a recurring security governance issue, not an occasional supplier exception.
• The article’s themes connect vendor risk, software supply chain compromise, and nation-state activity into one pattern of inherited trust.
• Practitioners need continuous external access governance, stronger machine identity oversight, and evidence-based supplier assurance rather than periodic reviews.

Key terms

• Third Party Risk: Third party risk is the chance that an outside organization, supplier, contractor, or service provider will create harm for your business. It includes security, privacy, operational, legal, and compliance exposure caused by access to data, systems, or processes. In identity terms, it often arises from shared credentials, integrations, and delegated trust.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real-world third-party and automation risk.