Your Third-Party Risk Program Is Running on a Clock That Already Ran Out

Third-party involvement reached 48% of all breaches this year, up 60% from last year, which had itself already doubled the year before. The trajectory is not a trend line. It is an indictment.

And yet most organizations are still managing this risk through a third party risk assessment model that relies on point-in-time reviews: annual questionnaires, periodic attestations, SOC 2 reviews, and a governance program built on the assumption that a vendor’s posture at the moment of assessment reflects their posture for the next twelve months. It does not. That assumption is costing organizations, and their boards, in ways that are becoming impossible to rationalize.

The Compliance Posture Is Not a Security Posture

Traditional third-party risk management was designed to maintain compliance in a different threat environment, not to reflect a real-time security posture. Its underlying logic (identify your vendors, categorize them by risk tier, evaluate potential risks tied to vendors, assess them on a schedule, document the results) made sense when breaches were episodic and vendor ecosystems were relatively contained. Neither of those conditions still holds.

Attackers operate continuously. Most TPRM programs operate annually.

Annual reviews leave long gaps that only ongoing monitoring can close. The gap between those two operating tempos is where breaches happen. Annual questionnaires capture intent, not reality. A vendor’s responses in February tell you nothing about the admin account with disabled MFA that their cloud team created in April. A SOC 2 report certifies a point-in-time audit. It does not certify what your vendor’s IaaS environment looks like today.

The DBIR is unusually direct on this point. Many organizations still rely on periodic reviews to manage third party risk. Third-party risk growth, the authors note, “has proven impossible to ignore.” What they don’t say, but the data implies, is that traditional TPRM programs have largely failed to close the gap. Organizations continue to invest in governance infrastructure while the operational realities inside their vendor ecosystems deteriorate undetected.

Three Paths In, and Most Programs Only See One

The DBIR identifies three distinct ways third-party relationships become breach vectors, and they require different defensive responses: these are distinct ways third party vendors create risk exposure.

The first is the software supply chain compromise, where a vulnerability in a vendor’s product gives attackers access to the customer’s environment. The initial access lives in your infrastructure, but the entry point was their code. SolarWinds remains the reference case, but this archetype remains active and underappreciated.

The second is the vendor-as-custodian breach, where attackers target the vendor directly and access the customer’s data in the vendor’s environment. Your exposure is entirely dependent on your vendor’s security posture. The 2024 Snowflake campaign is the defining example: customer data compromised not through the customer’s controls, but through credential abuse against the platform holding their data, creating cybersecurity risks and compliance risk when vendors hold sensitive data.

The third is the vendor-as-pivot, where attackers compromise a vendor and use that access to move laterally into the customer’s own environment. The blast radius crosses organizational boundaries, and detection is complicated by the fact that the initial compromise happened elsewhere.

What makes 2025’s breach landscape particularly important is that these archetypes are no longer operating independently. Several of the year’s most significant campaigns involved attackers compromising more than one third-party provider simultaneously. In the publicly disclosed Salesloft Drift and Salesforce campaign, attackers stole OAuth tokens from one vendor platform and leveraged them against a second to access customer data. Two vendors. One coordinated breach. Multiple victims.

Third-party risk is now ecosystem risk. Most TPRM programs are still managing vendors in isolation. Effective vendor risk management also has to account for interconnected vendors and fourth parties.

What the DBIR Found Inside Vendor Environments

For the first time, this year’s DBIR incorporates data collected from inside actual third-party cloud environments. Not external scans, but internal configuration data from a third-party cyber risk management dataset. The findings are worth examining carefully, especially because they strengthen vendor risk assessment with direct evidence from vendor environments.

The root causes driving the majority of high-profile third-party cloud incidents are not sophisticated, and they often reflect weak security controls inside vendor environments. They are not novel attack techniques or advanced persistent threats operating at nation-state capability. They are:

• Absent or misconfigured multifactor authentication on cloud accounts
• Improper credential rotation
• Failure to enforce least-privilege access for users and service accounts

Thirty-seven percent of organizations had an admin account with MFA disabled on IaaS environments. Not former organizations. Not organizations that hadn’t yet received guidance. Organizations today, after years of industry consensus that MFA is a foundational control.

These findings help identify high risk vendors and expose inherent risk that questionnaires often miss.

The remediation data compounds the concern. Delayed fixes also increase operational risk and the potential for reputational damage when vendors remain exposed. For password weakness and excessive permission misconfigurations, the time to resolve 50% of identified findings reached nearly eight months. Full remediation was achieved by only 31% of affected organizations. For MFA gaps, a control with near-universal industry endorsement, only 23% of third-party organizations fully remediated their exposure. A persistent 32% tail of MFA findings was never resolved at all.

“Compliance snapshots are not operational visibility. The 2026 DBIR now has the data from inside vendor environments to prove it.”

These are not abstract risks. They are open windows with known dimensions and documented timelines, and they are currently present in the vendor ecosystems of organizations that completed their annual TPRM assessments and consider themselves covered.

Service Accounts: The Exposure Most Programs Don't Touch

The DBIR includes a forward-looking observation that security leaders should treat as a near-term operational priority: service accounts and machine identities are the likely frontline of the next major attack surface, particularly as agentic AI systems introduce  forms of automated access  enterprise environments.

Service accounts are routinely over-privileged relative to their actual function, which increases vendor risk when they are lightly monitored. They are frequently excluded from the MFA requirements that govern human users. Their compromise often goes undetected longer than credential-based attacks against human accounts.

In a third-party context, this creates a specific and underappreciated risk: service accounts established during vendor onboarding to facilitate integrations should be part of the due diligence process because they carry implicit trust that is rarely reviewed, rarely constrained, and rarely revoked. They represent the intersection of ecosystem risk, identity risk, and the emerging AI attack surface. Most TPRM programs don’t have a field for them on the questionnaire. They should also be included in risk mitigation plans, especially for high risk integrations.

AI Compresses the Timeline. Your Vendor's Remediation Clock Does Not.

In April 2026, the Cloud Security Alliance published an expedited strategy briefing (cited directly in this year’s DBIR) titled “The AI Vulnerability Storm: Building a Mythos-Ready Security Program.” The briefing was convened in direct response to demonstrated AI capability in vulnerability discovery and exploit development, and it brought together 250 CISOs, former directors of CISA and NSA, and security researchers from SANS, Google, and Harvard Kennedy School.

The central argument: AI has materially compressed the time between vulnerability disclosure and exploitation. And security organizations have not yet matched that speed operationally. Continuous monitoring is now necessary to assess third party risk as remediation windows shrink.

The DBIR had already documented the gap on the defensive side. Only 26% of CISA Known Exploited Vulnerabilities are fully remediated, down from 38% the previous year. Third-party cloud misconfigurations take up to eight months to resolve at the median, increasing regulatory compliance pressure under stricter regulatory requirements. These numbers existed before AI-accelerated exploitation was a practical reality at scale.

“AI compresses the time between exposure and exploitation. Eight-month remediation windows are not a risk tolerance. They are an invitation.”

The CSA briefing’s guidance for organizations centers on the same fundamentals the DBIR has flagged for years: compress remediation timelines, harden authentication and segmentation controls, and treat vulnerability management as a permanent operational function rather than a periodic project. The difference is that in an environment where AI can identify and exploit configuration weaknesses at scale and speed, the tolerance for slow remediation, anywhere in your vendor ecosystem, has effectively reached zero.

Your vendor submitted a clean assessment in Q1. Their cloud admin account still doesn’t have MFA enforced. That gap is no longer a future audit issue; it is a live risk mitigation failure.

Third-Party Risk Management Is an Operational Discipline. Or It Is Not Working.

The path forward is not a longer questionnaire or a more granular risk tier taxonomy. The data is clear on what is actually required:

Continuous visibility over point-in-time assessment. The DBIR’s new dataset from inside vendor cloud environments is significant precisely because it reflects current state, not attested state. A risk assessment model based on point-in-time reviews cannot support ongoing signals. One-time assessments cannot capture an 8-month remediation tail. The operational model for TPRM needs to produce ongoing signals, not annual snapshots.

Authentication and authorization enforced as vendor requirements, not vendor self-attestation. The Snowflake campaign produced a measurable behavioral shift: only 14% of Snowflake customers had MFA-disabled admin accounts in the aftermath, compared to 37% in the broader IaaS population. That is what contractual and operational pressure produces. Organizations should build this into the vendor assessment process, especially for vendors with higher risk profiles. They should not require a direct breach to get there.

Service and machine accounts treated as first-class risk objects. They need inventory, least-privilege enforcement, monitoring, and lifecycle management, including across vendor boundaries. Service-account governance should also be part of a formal party risk management program. The agentic AI environment the DBIR references is not a future concern. The accounts that will be exploited are being provisioned today.

VulnOps and TPRM as permanent operational functions. The CSA briefing introduces the concept of “VulnOps”: vulnerability management as a standing organizational capability, not a project cadence. The same reframing applies to third-party risk. It is not an audit cycle. It is an operations center problem. Senior management should treat this as part of managing risk across critical vendor relationships.

Internal and external stakeholders need shared visibility to align third-party oversight with business objectives.

The Question to Take to Your Next Board Meeting

The 2026 DBIR confirms that third parties are now present in nearly half of all breaches, that the contributing factors are known and remediable, and that the window between exposure and exploitation is narrowing under AI-driven offensive capability.

Many organizations that will manage this effectively now treat this work as vendor risk management tied directly to business operations, not as a governance exercise or a static inventory problem. They are the ones that made a deliberate decision, ideally before a breach forced it, to treat third-party risk as what it actually is: an ongoing security operations problem embedded in every significant vendor relationship they hold. This is especially critical for financial institutions and other heavily regulated sectors.

“Vendor trust without verification creates systemic exposure. The 2026 data is no longer ambiguous about this.”

Annual questionnaires, attestation letters, and point-in-time audits are not without value. But if they are the primary mechanism through which an organization manages its third-party exposure, they are insufficient. An effective diligence process and due diligence reduce compliance risk, reputational risk, and strategic risk across vendor relationships. The data now says so at scale.

The question is not whether your party risk management TPRM approach is compliant. The question is whether it can support a structured third party risk assessment or party risk assessment on an ongoing basis.

Natural disasters and other disruptions can also affect third-party business operations, reinforcing the need for broader risk mitigation in these programs.

Lisa Hayashi is CMO at iCOUNTER. The 2026 Verizon DBIR and the CSA Mythos-Ready Security Program briefing are both publicly available and worth reading in full.