Skip to content
ReportThe 2026 State of TPRMDownload
Coverbase research report

The State of Continuous Monitoring

May 2026Edition 02 | 15 min read | Research report | TPRM, continuous monitoring, vendor risk
Built to alert, not to act: the past, present, and future of continuous monitoring
Continuous monitoring network diagram
01 · executive summary

Built to alert, not to act.

Most organizations that think they have deployed a meaningful continuous monitoring program have actually built a sophisticated alert system. The promise of continuous monitoring in third-party risk management has outrun the reality of how it is practiced. Events fire. Scores change. Breach notifications arrive. And then, in the absence of operational infrastructure to act on any of it, the alerts pile up in dashboards while the underlying risk accumulates.

This report argues continuous monitoring in third-party risk is not primarily a data problem, but rather a structural challenge. Organizations lack response workflows, blast radius visibility, and tiered access models required to convert signals into actions. Drawing on analysis of over 100,000 vendors and applications assessed across the Coverbase platform, alongside detailed case studies from incidents in 2025 and 2026, this report provides a framework for what operational continuous monitoring actually requires.

02 · section 1

The scale of the problem

Third-party risk has become the dominant attack surface

For most of the history of enterprise security, the primary threat model was external: attackers attempting to penetrate defenses built around infrastructure the organization owned and controlled. That model has inverted. The 2025 Verizon Data Breach Investigations Report found that third parties were involved in approximately 30 percent of all reported data breaches, a figure that doubled in a single year. Global losses attributable to supply chain and third-party attacks are projected to reach $60 billion by the end of 2026.

This shift is driven by modern enterprises outsourcing enormous portions of their operational capability to vendors. Data processing, payment infrastructure, identity management, communications, analytics, HR systems, and AI capabilities all flow through third-party products and services. Each of those relationships is a potential entry point for attackers to exploit.

Third-Party Involvement in Data Breaches, 2020 to 2026

The Coverbase data

For financial institutions and enterprises, the Coverbase platform has assessed over 100,000 unique vendors and applications. That figure includes both formal vendor relationships that flow through procurement and the long tail of SaaS and AI tooling that most employees use without explicit IT approval. The data reveals a stark gap between what risk teams believe they are monitoring and what their organizations are actually exposed to.

100,000+Vendors and applications assessed across the Coverbase platform
~30%Of applications surfaced were previously unassessed at the time of discovery (shadow IT)
6 to 9 monthsAverage lag from a vendor's subprocessor change to customer awareness under questionnaire-driven review (vs. minutes when continuously monitored)

Shadow IT distribution across verticals

Across the Coverbase dataset, financial services customers consistently surface a higher proportion of previously unassessed applications than enterprise customers, driven largely by regulated lines of business that have historically governed only a narrow ring of "systems of record" while leaving day-to-day SaaS and AI tooling outside the formal vendor inventory.

The most common categories of unassessed applications, in order of prevalence, are AI and LLM tooling (model APIs, agent frameworks, AI gateways, and embedded AI features inside otherwise approved SaaS), file transfer and document collaboration (managed file transfer, e-signature, document AI), communication and meeting platforms (transcription, scheduling, async video), and developer tooling (CI/CD plugins, observability agents, code assistants).

The pattern is consistent across customer segments: the applications that surface as shadow IT are not exotic; they are the ones individual teams adopt faster than centralized risk programs can assess them.

Anonymized customer scenario

In one representative case, a financial institution with an established questionnaire-based TPRM program had assessed a payroll and HR vendor as low risk based on their most recent annual review. After ingesting the vendor's full subprocessor disclosures, SBOM data, and OAuth scope inventory into Coverbase, the customer discovered that the vendor relied on a fourth-party AI data processing service for resume parsing, which in turn pulled data through a fifth-party model provider with a different data residency posture than the customer's primary vendor relationship had implied.

The exposure had not been captured by any of the questionnaire responses, because the questions had been written against the third-party relationship and not the dependency chain.

Within hours of the dependency being surfaced, the customer sent a targeted evidence request and confirmed the scope of shared data. It then renegotiated the relevant contractual terms before the next assessment cycle.

03 · section 2

The nth-party problem

Why your vendor is not your risk surface

When an organization completes a third-party risk assessment, they are evaluating their direct vendor. Does this company have adequate security controls? The answer, even when true, addresses a fraction of the actual risk. The vendor's services run on a stack: open-source libraries, cloud infrastructure, payment processors, AI model providers, logging tools, authentication middleware, and dozens of other components the vendor has sourced from their own suppliers. Each of those components carries its own risk profile, and the customer has almost no visibility into any of it.

Consider a hypothetical. Your payroll vendor uses AWS. AWS uses a third-party DDoS protection service.

That service had a CVE that remained unpatched for 14 months, and they never bothered to tell AWS, let alone you. You assessed your payroll vendor last March. None of this was visible.

This is the nth-party problem. The real risk surface is not the vendor you assess. It is the full dependency graph that underlies the service you pay for. In most enterprise vendor relationships, that graph extends at least three or four layers deep, involves dozens of distinct companies, and changes continuously as vendors update their stacks. A questionnaire completed today is obsolete the moment the vendor upgrades their logging library.

Figure 2.1: nth-party dependency graph
04 · section 3

Three incidents that show what continuous monitoring must catch

The following incidents each illustrate a different dimension of the monitoring and response problem. The incidents documented in this report are not anomalies. They are the natural outcomes of a system where vendor assessments happen annually, nth-party dependencies are invisible, and response workflows do not exist.

Each case study below sets out the capabilities that would have enabled earlier detection and a meaningful response.

LiteLLM / TeamPCP supply chain attack (March 2026)
case study 1

LiteLLM / TeamPCP supply chain attack (March 2026)

what happened

The TeamPCP threat actor group first compromised Trivy, a widely used open-source security scanner embedded in LiteLLM's CI/CD pipeline. Using access to Trivy, they exfiltrated LiteLLM's PyPI publishing credentials and published two malicious versions of the library (v1.82.7 and v1.82.8) containing an infostealer payload. LiteLLM is installed approximately 15 to 20 million times per week, and roughly 40% to 50% of installs were unpinned and pulling the latest version automatically. Mercor, a $10B AI recruiting company working with OpenAI and Anthropic, confirmed a breach tied directly to the compromised dependency.

pre-incident detection

SBOM monitoring on LiteLLM would have flagged the version change within minutes of publication. OAuth scope monitoring on vendor integrations using LiteLLM would have identified which vendors in the portfolio were using the library as a dependency. A continuously maintained vendor living profile for any vendor using AI gateway tooling should have included LiteLLM as a tracked dependency.

immediate response

Every vendor using LiteLLM needed to be contacted immediately. Organizations needed to know which vendors were running unpinned versions, which had already pulled the malicious release, and whether any of those vendors handled PII, credentials, or financial data. That analysis is impossible without pre-built dependency mapping.

lesson

Supply chain attacks do not announce themselves. The organizations best placed to respond were those that had already mapped which vendors used LiteLLM before the compromise occurred. Continuous monitoring is the only way to maintain that map in real time.

Oracle Cloud SSO / LDAP breach (March 2025)
case study 2

Oracle Cloud SSO / LDAP breach (March 2025)

what happened

A threat actor claimed to have exploited an LDAP injection vulnerability in Oracle Cloud Infrastructure's SSO system and exfiltrated credentials for 15,000 organizations. The breach reportedly went undetected for months. When Oracle finally disclosed the incident, affected organizations had no way to determine which of their vendors were using Oracle Cloud SSO, which vendor accounts had been compromised, and what downstream data flows were at risk.

pre-incident detection

Identity stack monitoring would have identified which vendors in the portfolio were using Oracle Cloud SSO as an authentication layer. OAuth scope tracking would have shown which vendor integrations were relying on Oracle-issued tokens. A continuously maintained vendor living profile should have included Oracle Cloud SSO as a tracked dependency for any vendor using Oracle infrastructure.

immediate response

Weekly scans are useless in a credential breach scenario. By the time the next scan runs, exfiltrated credentials have already been used to access downstream systems. Organizations needed to know immediately which vendors were affected, which data flows were at risk, and which regulatory notification obligations were triggered.

lesson

Post-breach disclosure is not a detection strategy. Organizations that had pre-mapped their vendor dependency exposure to Oracle Cloud SSO could respond within hours. Organizations without that map faced weeks of reconstructing it after the fact.

GoAnywhere MFT critical vulnerability (2025)
case study 3

GoAnywhere MFT critical vulnerability (2025)

what happened

A critical vulnerability in GoAnywhere MFT, a managed file transfer solution widely used to move financial records, HR files, legal documents, and PII between enterprise systems, received a CVSS score of 10.0. Security researchers explicitly drew the parallel to the MOVEit breach of 2023, noting the identical structure: one flaw in a widely shared infrastructure component triggers a simultaneous chain reaction of exposures across hundreds or thousands of downstream organizations.

pre-incident detection

Organizations whose vendors use GoAnywhere as a file transfer layer should have been alerted at the moment CVE publication occurred. A continuously maintained vendor technology profile, built from SBOM data, DNS signals, and disclosed DPAs, would have identified which vendors in the portfolio relied on GoAnywhere infrastructure for data exchange.

immediate response

On breach notification, organizations needed to immediately identify every data flow that touched a vendor using GoAnywhere, understand what data types were in transit, and determine regulatory notification obligations. None of that analysis is possible in real time without pre-built data on vendor technology stacks and data flow maps.

lesson

Concentrated risk in shared infrastructure components is not a novel problem. It will repeat with a different product name. The organizations that respond fastest are those that have pre-mapped their vendor dependency exposure to commonly used infrastructure components before the CVE is published.

05 · section 4

Legacy security categories fall short

The collapse of the perimeter model

Traditional enterprise security was organized around a clear mental model: inside the network is trusted; outside is not. The cloud-first, SaaS-first enterprise has made this model structurally irrelevant. Payroll data lives in Workday. Customer data lives in Salesforce. Identity is managed in Okta. The perimeter did not shift. It dissolved.

The security industry has spent the better part of a decade building categories designed to address this dissolution. None of them were designed with third-party relationships as the primary unit of risk, which means none of them extend naturally to cover the vendor ecosystem where the exposure now lives.

Security categories and their insufficiency

security categoryFirewall / IDS / IPS (1990s-2000s)
built for, blind to

Defined trust by network location. Irrelevant once business logic moved outside the network. Cannot see data flows to vendor environments.

security categoryDLP: data loss prevention
built for, blind to

Attempted to monitor data at the boundary. Cannot follow data once it arrives in a vendor environment. Treats egress as the problem; the problem is what happens after egress.

security categoryCASB: cloud access security broker
built for, blind to

Added visibility into which cloud services employees connect to. Enforces policy on data in transit. Does not provide visibility into what vendors do with data after it arrives.

security categoryCSPM: cloud security posture management
built for, blind to

Continuous monitoring of cloud infrastructure configuration. Requires authorized access to the infrastructure being monitored. Cannot extend to vendor cloud environments.

security categorySSPM: SaaS security posture management
built for, blind to

Application-layer posture monitoring using access organizations already hold. Monitors your tenant, not your vendor's security practices. Covers shadow IT in your environment, not the vendor's stack.

security categoryAttack Surface Management / Security Ratings
built for, blind to

Outside-in signal aggregation at scale. Useful for portfolio triage. Poor predictive value for breach. Cannot see what vendors are doing with your data internally.

security categoryVulnerability Management
built for, blind to

Systematic tracking and remediation of known CVEs in controlled infrastructure. Does not extend to vendor environments. Cannot enforce patch timelines on third parties.

06 · section 5

What continuous monitoring actually requires

The signal continuum

Tier 1 · Observable

Publicly observable signals

Publicly observable data: domain health, SSL certificate changes, exposed services, breach news, published CVEs, dark web mentions, BGP routing anomalies, IP reputation scores, security ratings. These signals are universally available, require no vendor cooperation, and scale to thousands of vendors simultaneously.

There's an obvious limitation here: outside-in signals are poor predictors of breach.

The majority of significant vendor incidents in recent years would not have been preventable from the outside-in layer alone. A security score does not reveal an internal authentication endpoint left unpatched for years. Outside-in monitoring is necessary but not sufficient.

Tier 2 · Disclosed

Everything vendors share with you

Everything vendors share with you. SOC 2 reports, penetration test summaries, DPA subprocessor annexes, questionnaire responses, incident notifications, and, increasingly, SBOM data.

Higher quality than Tier 1, but imperfect due to its self-reported nature. The critical insight for this tier is that its value is maximized when the data is structured and machine-readable rather than PDF artifacts reviewed once per year.

A SOC 2 report that has been parsed into structured control evidence and mapped to your specific use case is substantially more useful than the same report sitting in a shared drive.

Tier 3 · Integrated

Verified through your own access

What you can observe and verify through your own access.

SSO authentication logs, browsing user access patterns, integration platform event streams (Zapier, Workato, Tray), real-time monitoring on vendor API endpoints, anomaly detection on access patterns. In the future: continuous verification of subprocessors.

This tier does not depend on vendor cooperation or trust. It shows what vendors are doing with your data in real time.

Signal quality vs. coverage matrix: three signal tiers diagram
07 · section 6

Where the market is heading

The convergence of TPRM, SSPM, and identity governance

TPRM, SaaS security posture management, cloud access security brokering, and identity governance are all circling the same underlying problem from different angles: do you know what your third parties are doing with the access and data you have given them, and can you re-confirm the answer whenever you want?

These categories will converge. The question for TPRM practitioners is whether they want to be absorbed into the broader security tooling stack (losing the business context, procurement workflow, and regulatory framing that make TPRM distinctive) or whether the TPRM category expands its technical surface area to absorb adjacent signal classes before convergence happens from the security side.

The living vendor profile as the end state

The direction of the market is away from periodic assessments and toward persistent, continuously updated vendor records. A living vendor profile aggregates all evidence classes into a single risk posture that updates in real time and automatically triggers workflows when posture changes.

In this model, the assessment is not an event that happens annually. It is a state that is maintained continuously. Triggering events, such as a new CVE, a change to the vendor's subprocessor list, or an anomalous access pattern on its OAuth connection, would cause the profile to update automatically and route the change to the appropriate response queue.

Regulation

The shift toward continuous evidence requirements in regulatory frameworks is already in progress. DORA in the European Union requires financial entities to implement ICT third-party risk management programs with continuous monitoring components and specific contractual requirements for vendor access and audit rights. SEC cybersecurity disclosure rules require material incident reporting on timelines that assume real-time awareness of vendor breaches. OCC, FDIC, and Federal Reserve guidance issued in 2023 requires banks to govern third-party relationships across the entire lifecycle, not just at onboarding.

Organizations that build operational continuous monitoring infrastructure today are building toward expectations that are likely to become examiner requirements in their regulatory environment within three to five years. The organizations that delay are not avoiding cost. They are deferring it, with interest, to a future moment when compliance pressure will force the investment under worse conditions and shorter timelines.

The self-audit model and network effects

The most significant structural evolution in the market will be the shift from customer-driven assessment to vendor-driven evidence provision. In the current model, customers assess vendors. In the emerging model, vendors maintain living evidence portfolios, pre-populated with control evidence, SBOM data, certifications, and access logs, that customers can query rather than request.

This creates network effects: the more customers assess a vendor through a shared platform, the stronger the vendor's incentive to maintain high-quality evidence in that platform, because doing so reduces the assessment burden across their entire customer base simultaneously. Vendors who invest in high-quality evidence infrastructure will be rewarded with lower-friction onboarding and stronger commercial trust at lower operational cost.

Living vendor profile workflow diagram
08 · section 7

Recommendations for TPRM practitioners

1

Immediate actions

  • Audit your existing vendor portfolio. Compare it against the incident patterns in Section 3. Identify which vendors in your tier-1 and tier-2 portfolio use AI gateway libraries, managed file transfer infrastructure, or legacy cloud authentication systems. These are the highest-probability exposure points in your portfolio today.

  • Map your access-based signal sources. Catalog every OAuth grant, SSO connection, and API integration between your systems and your vendors. This inventory is the foundation of Tier 3 monitoring and is almost certainly more complete than your formal vendor risk register.

  • Build one response playbook before you need it. Choose the most likely cross-portfolio event type in your industry and build the complete response workflow in advance. Identify vendor contacts, pre-draft evidence requests, and document the escalation path.

2

Program investments for 12 to 24 months

  • Invest in living vendor profiles, not periodic assessments. The unit of effort should shift from completing assessments to maintaining profiles. Evidence that was collected for one assessment should persist, depreciate on a defined schedule, and automatically trigger refresh requests when it expires.

  • Connect your risk tiering to your alerting infrastructure. The triage logic that determines which alerts require immediate response versus weekly review should be automated and driven by your vendor risk tier and data sensitivity classification, not by a human triaging an inbox.

  • Push for SBOM disclosure in vendor contracts. For tier-1 vendors (those processing your most sensitive data or operating your most critical integrations), add contractual requirements for SBOM provision on a defined schedule, with notification obligations when dependency versions change materially.

3

Strategic positioning

  • Engage your vendors as partners, not subjects. Vendors who understand that transparency reduces their assessment burden will invest in evidence quality. Calibrate your program to reward transparency.

  • Prepare for regulatory convergence now. Build the infrastructure today, under conditions you control, rather than in response to a regulatory examination finding on an arbitrary deadline.

Conclusion

The promise of continuous monitoring in third-party risk management has never been more important, and the gap between that promise and actual practice has never been more consequential.

The signals needed to close this gap already exist. Closing it does not require more data. It requires building the operational infrastructure to convert those signals into actions: response campaigns that fire automatically, blast radius maps that answer the exposure question in minutes rather than days, and vendor evidence libraries that accumulate rather than reset with each assessment cycle.

The organizations that invest in this infrastructure today are not just building compliance programs. They are building a competitive advantage in an environment where third-party breaches are becoming the primary mode of enterprise compromise. The question is not whether to build this capability. It is whether to build it before the next incident or after.

Third-party incident briefing: a monthly analysis series

Each edition examines a real-world incident through the lens of third-party risk: what happened, who was affected, and what it means for how we monitor vendor relationships.