Why third-party continuous monitoring has to watch the integration, not just the company

Third-party involvement in breaches reached 48% in the 2026 Verizon Data Breach Investigations Report — a 60% year-over-year increase, following a year in which the figure had already doubled from 15% to 30%. Two consecutive step changes have shifted vendor exposure from a procurement concern to a first-order security problem.

The conventional response is now well-rehearsed: annual questionnaires go stale, so replace them with continuous monitoring. That conclusion is correct. The reasoning behind it is incomplete, and the incompleteness is expensive.

Most programs sold as "continuous monitoring" watch the vendor — external scan data, breach mentions, certification status, and a numeric posture score refreshed daily. But the exposure that actually produces third-party breaches increasingly lives in the connection: the OAuth grant, the API key, the federated identity trust, the service account, the standing query access into your CRM. That surface is inside your tenant. You issued it. No amount of outside-in scanning of the vendor will tell you anything about it.

A third-party continuous monitoring (TPCM) program that only monitors suppliers is monitoring half the problem it doesn't control and ignoring the other half it does.

What a TPCM program actually is

Third-party risk management (TPRM) is the governance wrapper: inventory, tiering, due diligence, contracting, and offboarding. Third-party continuous monitoring is the operational layer within it — the mechanism that keeps risk decisions up to date between formal assessments.

A functioning TPCM program does four things:

1. Maintains a live inventory of relationships and connections. Not a procurement list. A record of which vendors hold data, which hold system access, and — critically — through what technical mechanism that access is granted and by whom it was approved.

2. Ingests external signal about vendor state. Breach disclosures, regulatory actions, exploited vulnerabilities in products the vendor operates, credential exposure, corporate changes (acquisition, insolvency, jurisdiction shift, subcontractor changes).

3. Instrument the connection itself. Authentication events from vendor identities, API call volume and pattern, OAuth grant scope and age, token issuance and rotation, data egress through integrations, and the presence of access paths nobody has reviewed in a year.

4. Routes findings into a decision process. Tiered escalation, defined remediation clocks, contractual triggers, documented risk acceptance, and reporting that reaches the people accountable for it.

The distinguishing feature of "continuous" is not frequency. It is that the program is event-driven — a disclosed incident at a vendor, an unexplained spike in integration traffic, or an expired attestation initiates action, rather than waiting for a review cycle to come around.

Why point-in-time assessment fails structurally

Three failure modes, in ascending order of severity.

Attestations describe a scope you did not choose. A SOC 2 Type II report covers a defined system boundary and observation window, selected by the vendor and agreed with its auditor. It may or may not include the specific product, region, or integration you rely on. It is evidence, and useful evidence — but treating a report as a statement about your exposure conflates the vendor's audit scope with your attack surface.

Vendor remediation clocks are long. The 2026 DBIR found that only 23% of third-party organizations had fully remediated missing or improperly secured MFA on cloud accounts, with the report tracing a substantial share of cloud-based third-party incidents to insecure authentication and inadequate least-privilege enforcement. (Reported — figure as characterized in third-party analyses of the 2026 DBIR; verify against the source report before publication.) An annual reassessment cadence means a finding raised in month one may still be open at the next review, with no intervening visibility.

Detection lag is the whole game. In the 2026 IBM Cost of a Data Breach Report, supply chain compromise was the single largest cost amplifier among the roughly 30 factors analyzed — adding an average of $227,250 to breach cost — was the second most common initial attack vector, and tied for the longest lifecycle at 258 days to identify and contain against a 247-day overall average. (Vendor-published research; conducted with Ponemon Institute, based on 602 breached organizations across 16 countries for incidents between March 2025 and February 2026. Treat the cost figures as directional.)

That 258-day figure is the argument for TPCM stated in its plainest form. These incidents are slow to surface, not because they are technically sophisticated, but because they occur on infrastructure the victim does not monitor, using access the victim authorized.

The case for watching the connection

In August 2025, a threat cluster tracked by Google Threat Intelligence Group as UNC6395 used stolen OAuth tokens associated with the Salesloft Drift chatbot integration to access Salesforce instances belonging to Drift's customers. Over roughly ten days, the actor ran automated queries against standard Salesforce objects and exported data from what Google assessed as more than 700 potentially impacted organizations. The focus was credential harvesting — AWS access keys, Snowflake tokens, and plaintext passwords that customers' own staff had pasted into support cases. Salesforce and Google Workspace platforms were not themselves compromised; the actor operated entirely within the permissions the integration had been granted. (Confirmed — vendor advisories, FBI advisory, and multiple independent incident analyses. Reporting indicates initial access to Salesloft traced back to earlier access to a source-code repository, with subsequent movement into the environment holding the tokens; treat the upstream chain as Reported rather than Confirmed.)

Consider what a conventional monitoring program would have surfaced. Salesloft's external attack surface was unremarkable. Its certifications were current. No posture score would have moved. The compromise reached hundreds of organizations through a credential each had issued itself, often years earlier, frequently approved by a sales operations team rather than security, and carrying a scope far broader than the chatbot function required.

The controls that would have mattered were all on the customer side: an inventory of connected applications and their granted scopes, alerting on anomalous API query volume against CRM objects, token lifetime limits, and a policy against credentials living in support tickets.

This is also why offboarding deserves more attention than it usually gets. The October 2025 NYDFS guidance is unusually specific here, directing covered entities to revoke identity federation mechanisms, OAuth tokens, API integrations, and external storage access on termination — and to address redundant access points on an ongoing basis rather than leaving them until the relationship ends. Residual access from a vendor you stopped paying two years ago is not a governance untidiness. It is an unmonitored, unpatched, unattributed path into your environment.

The regulatory picture

Third-party oversight has moved from best practice to explicit obligation across most regulated sectors. The requirements are real, but they share a characteristic worth naming: almost none of them say "continuous." They say periodic, ongoing, or risk-based. The compliance floor sits meaningfully below the risk floor.

Four observations for practitioners.

You cannot delegate the obligation. NYDFS states this directly, noting it has observed entities outsourcing cybersecurity compliance responsibilities to providers without adequate oversight or verification, and reiterating that compliance responsibility cannot be delegated to an affiliate or a vendor. DORA takes the same position: using a third party does not transfer regulatory accountability.

The SEC rule creates a disclosure dependency you don't control. Item 1.05 addresses incidents involving third parties that materially affect the registrant, and the adopting release indicates that companies generally need only disclose information available to them through ordinary channels with providers — they are not required to conduct additional inquiries. That is a low investigative bar, but it means your four-day clock is effectively gated by how fast and how completely a vendor tells you what happened. Contractual notification terms and monitoring that lets you form an independent view are the only things that make that timeline survivable.

Supervisory expectations are outrunning the rule text. The NYDFS industry letter is explicitly non-binding and creates no new requirements — but it details what examiners will look for, and calls for what the Department describes as a "continuously adaptive approach" to third-party governance. Guidance of that specificity tends to become the practical examination benchmark.

Two of these are unsettled. The HIPAA Security Rule NPRM remains proposed; the comment period closed 7 March 2025, no final rule has issued, and the target date for final action has slipped repeatedly. Separately, the SEC's 2023 cybersecurity disclosure rules remain in effect but are under active pressure to be rescinded, including an April 2026 joint comment letter from five banking trade associations seeking rescission or narrowing of Item 106 and Item 1.05. (Both items require re-verification immediately before publication.)

What to build

Tier by connection type, not by contract value. A $12,000/year chatbot with a broad OAuth grant into your CRM outranks a $2M facilities contract. Ask what the vendor can reach, not what you pay them.

Inventory integrations as first-class assets. Every OAuth grant, API key, service account, and federation trust — with granted scope, issuing owner, business justification, issue date, and last-used date. Anything without a named owner is a finding.

Separate attestation from evidence. A certification tells you that a program existed within a scope at a point in time. Evidence tells you a control operated. Ask for the latter in your highest-tier relationships: patching timelines for internet-facing systems, MFA enforcement coverage for privileged and service accounts, and confirmation that previously identified deficiencies have actually been closed.

Instrument what you can see. Authentication events from vendor-associated identities, integration API volume and query patterns, and egress through connectors are all in your logs today. The Drift campaign was visible in Salesforce event data; what was missing was anyone watching it.

Define triggers, not just cadence. A disclosed incident at a provider, an exploited vulnerability in a product they operate, an ownership change, or a lapsed attestation should each start a defined workflow with an owner and a clock.

Treat offboarding as a security control. Revoke federation, tokens, and API access upon termination; certify data destruction; and continuously sweep for residual access rather than at contract end.

Report it where it counts. Material or unresolved third-party risk belongs in the enterprise risk register and in front of the board — not buried in a vendor management spreadsheet.

Why Organizations Choose Zaxtron

Organizations face increasingly sophisticated ransomware campaigns that exploit unpatched systems, stolen credentials, exposed remote access, and third-party weaknesses. To stay protected, they need actionable intelligence, not just alerts, to identify and reduce cyber risks before disruption occurs. Zaxtron provides Cybersecurity Risk Management, AI Risk Management, and Cyber Threat Intelligence services that deliver continuous visibility and risk-based insights. By combining attack surface intelligence, vulnerability data, threat and breach intelligence, and third-party risk analysis, Zaxtron offers a complete view of cyber exposure. This helps security leaders respond to threats, improve vendor security, and make informed decisions. Contact Zaxtron to strengthen cyber resilience today.

Editorial notes

On the central statistic. The 48% figure is from the 2026 DBIR (19th edition, incidents from 1 Nov 2024 – 31 Oct 2025) and is confirmed in Verizon's own press release. Note that "third-party involvement" is a broad definitional category — it includes running vulnerable third-party software, not only vendor compromise. That breadth is defensible but should not be silently converted into "48% of breaches came from vendor compromise." The post as written avoids that elision.

Sourcing risks flagged inline. The 23% MFA remediation figure and the 258-day / $227,250 IBM figures came through secondary analyses. Both should be checked against the primary reports before publication. The IBM report is vendor-published and is labeled as such in the text.

AI framing was deliberately minimized. The 2026 DBIR places heavy emphasis on AI acceleration. That framing was not adopted here because the third-party findings stand independently of it, and the Drift case is a conventional token-theft operation. If a reviewer requests AI coverage, the honest angle is exposure surface — AI chatbots and copilots are high-scope integrations — not attacker capability.

Time-sensitive claims. HIPAA NPRM status and SEC Item 1.05 status both require re-verification at publication. If the post sits in the queue more than four to six weeks, re-check both.

Attribution precision. UNC6395 is a Google Threat Intelligence Group cluster designation. At least one source assesses the Chinese state association; however, that assessment is not broadly corroborated and has been omitted. The upstream access chain into Salesloft is characterized as Reported, not Confirmed.

Softenable positions. The opening line ("isn't what breached you") is deliberately assertive. If legal or brand prefers, it can be softened to "isn't the whole story" without damaging the argument. The claim that posture scores would not have moved for Salesloft is an assessment, not a verified fact — phrased accordingly.