Fourth Party Risks During Mergers and Acquisitions

On August 27, 2025, the Google Threat Intelligence Group (GTIG) revealed a widespread data theft targeting Salesforce instances via the Salesloft Drift integration. Attackers gained access to OAuth tokens linked to Drift’s live-chat integration—now part of Salesloft—and used them to extract customer data from connected Salesforce environments at scale.  

Salesloft acquired Drift, a Conversational AI platform, in February 2024, bringing Drift’s integrations, access scopes, and service relationships into its ecosystem. 

Later, experts found that the vulnerability came from trusted access that was passed along through Drift’s tools, like long-lasting tokens that still worked even after the company changed hands. 

That is fourth-party risk in practice.  

Fourth-Party Risk Created by the Supply-Chain Path

Fourth-party risk refers to the indirect exposure your organization inherits from the vendors your third-party providers rely on. These are the sub-processors, SaaS integrations, managed service platforms, and API dependencies that sit one layer deeper in your supply chain.  

Unlike third-party risk, which is visible and contractual, fourth-party risk is often obscured, embedded in support portals, API scopes, and inherited toolchains.  

In M&A deals and integrations, these hidden dependencies multiply quickly. You may unknowingly inherit access tokens, scopes, and service relationships that weren’t part of your original risk assessment. This creates a blind spot in your security posture—one that’s rarely documented, but often exploitable.  

Why Fourth-Party Risk Spikes During M&A

Mergers and acquisitions tend to combine entire digital ecosystems. Each party brings its own vendors, integrations, and inherited access paths, creating a complex web of dependencies rarely visible during initial due diligence.  

Security reviews often confirm that “SOC 2” or “ISO 27001” certifications are in place. However, these attestations typically focus on primary systems and may overlook sub-processors, OAuth-connected apps, and managed service provider (MSP) toolchains —precisely where fourth-party risk tends to hide.  

To make matters worse, integration timelines are increasingly compressed. The window between signing and closing is short, yet it’s when the most sensitive changes occur: tokens are active, logging is minimal, and systems are in transition. These conditions create a perfect storm for exploitation, as seen in the Salesloft–Drift incident, where attackers leveraged OAuth tokens to extract customer data from Salesforce at scale.  

Let’s go through the best practices for mitigating fourth-party risks during mergers, acquisitions, and divestitures.

Best Practices to Reduce Fourth-Party Risk in M&A

1) Map and Govern Tokens, Not Just Vendors

Start with the token story. Before debating architectures, establish who approved each org-wide app, what data it can access, when secrets were last rotated, and how quickly it can be revoked. This keeps attention on the access pathways attackers actually use.

• Export admin-consented apps and scopes across CRM, productivity, and identity platforms.

• Require a revocation/rotation runbook with named owners and a recent drill.

• Freeze new tenant-wide consents until Day-0 guardrails are live.

2) Validate Assurance Scope, Not Just Badges

Your diligence team will likely see SOC 1/SOC 2 reports and feel reassured. Treat those reports as historical snapshots of controls, useful, but not proof that today’s integrations and delegated access are governed the way you need.  

What matters is what the reports cover and whether that coverage matches the trust paths you’re inheriting. Read SOC/ISO documentation to confirm explicit inclusion of integrations, sub-processors, delegated access, and SaaS audit logs routed to your SIEM.  

Then ask for evidence that the same scope is live today.

• Maintain current sub-processor lists, including change-notification terms and the right to audit, where appropriate.

• Verify MSP remote access uses MFA, least privilege, IP allow-listing, and session logging.

3) Stage Day-0 Guardrails Before You Integrate

You don’t need a full rearchitecture to reduce the blast radius before closing the transaction. Temporary controls can help limit the impact of a stale token while teams merge and systems are being inventoried.

• Enforce Identity Provider (IdP)-based access with device trust for CRM and identity admins.

• Block legacy protocols that bypass MFA.

• Centralize SaaS audit logs and alert on OAuth grants, bulk exports, and unusual access.

4) Minimize Data Exposure as You Merge

One of the most effective and often overlooked best practices is to minimize data exposure during mergers and acquisitions. As systems and teams come together, data tends to spread into connectors that were never designed for your new risk profile.

Reducing unnecessary data movement and retention narrows the attacker’s options and simplifies oversight.

Shrink what an attacker could take and how far they can pivot:

• Tighten scopes; remove dormant connectors; enforce retention and deletion in downstream tools.

• If least-privilege operation isn’t feasible, replace or isolate the app until it is.

5) Day-30/90 Integration Priorities (Executive View)

Segment Critical Systems

Move crown-jewel applications behind the IdP with conditional access and avoid broad VPN access. This prevents a single compromised integration from becoming a master key.

Minimize Data Exposure

Convert policy into change: right-size permissions, deprecate unused connectors identified in discovery, and enforce deletion/retention so excess data isn’t spread across tools you don’t control.

Prove Readiness with Drills

One of the ways to manage risk from Fourth parties is to eliminate standing admin, adopt just-in-time elevation, and run a focused tabletop from token theft → SaaS pivot → bulk export → customer/board communication.  

Good IT integration teams capture actual timings for revocation and isolation and turn gaps into Day-30/90 actions with owners and deadlines.

Conclusion

The Salesloft–Drift breach serves as a blueprint for how risk can spread through integrations you didn’t sign up for. Your team should treat fourth-party exposure as a first-class due diligence task, measure it with scope-aware evidence (not badges), and stage your integration so tokens, logs, and admin pathways are controlled from Day 0.  

This approach keeps the deal moving, without inheriting silent pathways into your systems.

Where we can help you execute: X-Centric’s IT Solutions’ Internal Vulnerability Assessment & Risk Prioritization identifies excessive privileges and lateral movement paths within merging environments (prioritized remediation), and our dedicated M&A IT Integration practice supports IT due diligence and Day-0/30/90 execution with minimal disruption to the deal cadence.