Compromised cloud vendor: how a third party becomes the entry point into your IT system

Your security perimeter doesn't stop at your own infrastructure. It extends to every vendor that has access to it.

Third-party risk management has become, for many organizations, the most neglected weak point in their security posture. Third-party risks are no longer just a contractual clause: they weigh directly on the operational resilience of the company that depends on them.

One morning, users report strange behavior on your platform. Data on the move. Exports that weren't triggered. Your security team springs into action, combs through your systems, checks the logs, queries your detection tools. Nothing. Not the slightest trace of intrusion.

You contact your CRM vendor. Their response arrives by the end of the day: "We haven't observed any suspicious activity on our end."

Except two weeks later, you find out that vendor was using a marketing automation tool, a third party of your third party, whose access tokens had been stolen. Your data was exfiltrated through a connection that looked exactly like legitimate traffic. None of your tools could detect it, because the connection came from an authorized system.

This isn't a hypothetical scenario. It's what happened in August 2025, when the UNC6395 group compromised Salesloft Drift and accessed the Salesforce instances of more than 700 organizations. The victims had done nothing wrong. Their vendor had been compromised through another vendor.

"What struck me when I was on the offensive side is that cloud vendors are often the cleanest path to a target. No alert, no abnormal trace. The trust relationship becomes the vulnerability.", explains Vladimir Kolla, co-founder and CTO of Patrowl, former pentester.

Key takeaways

• 30% of data breaches involve a third party in 2025, up from 15% the previous year (Verizon DBIR 2025)

• 97% of organizations experienced at least one supply chain breach in 2025

• The average cost of a third-party-originated breach reaches $4.8M, 8% above the global average

• 62% of TPRM programs still rely on self-reported questionnaires (Gartner 2026)

• DORA and NIS2 require continuous third-party monitoring: the annual questionnaire is no longer sufficient from a regulatory standpoint

The share of breaches going through a third party has doubled in one year. This isn't a gradual trend. It's a shift in attacker tactics. Rather than confront a well-defended target, they look for the vendor that has access to it and is less closely watched. It's faster, quieter, and often more effective.

"When we run a pentest for a client, one of the first things we look at is their cloud vendors. Their subdomains, their exposed APIs, their certificates. That's often where we find the fastest way in.", explains Florent Montel, co-founder and CFO of Patrowl, former pentester.

Think of your house. You have a good lock, an alarm, solid shutters. But you've also given a spare key to the plumber, the caretaker, and the cleaner. If any one of them has their keys stolen, it doesn't matter how good your lock is.

The cloud works exactly the same way.

Whether your cloud service providers operate as software as a service, platform as a service (PaaS), or infrastructure as a service, the principle stays the same: every one of these cloud computing models relies on delegated access, wider or narrower depending on the service level.

A SaaS vendor, a marketing automation tool, an HR platform: each one holds access to your infrastructure. OAuth tokens, API connections, active webhooks with broad permissions. That access is necessary for the service to work. It also represents just as many doors into your IT system that you don't directly control, and therefore just as much cyber risk transferred to a third party, without your data protection suffering any less for it.

When an attacker targets the vendor instead of you, they pick up that access without forcing anything. They walk in through the plumber's door. The traffic they generate looks exactly like legitimate traffic. No SIEM rule catches it, no EDR intercepts it, no alert fires on your side.

What this means in practice:

• A compromised OAuth connection at a vendor grants access to every resource that vendor can reach on your side

• A misconfigured S3 bucket on the vendor's side exposes your data without your detection tools seeing anything

• File transfer software used by your logistics provider can compromise your customer data without any alert ever reaching you

Incident 1: Salesloft Drift, 700 organizations compromised via an OAuth token

In August 2025, the UNC6395 group stole Drift's OAuth tokens, a marketing automation tool integrated with Salesforce. With those tokens, attackers gained direct access to the Salesforce instances of every Drift customer who had authorized the connection.

Result: more than 700 organizations affected. Customer data exfiltrated, business information compromised. No technical exploit, no phishing aimed at the end victims. A trusted connection, hijacked. One of the most extensive data thefts of the year, with none of the affected organizations having made any mistake themselves.

The security teams at the impacted organizations had done nothing wrong. Their vendor had been compromised through one of its own tools. The chain of trust had two links, and the attacker only needed to break one of them.

What this illustrates: your security controls don't apply to the access you've delegated to your vendors.

Incident 2: Cleo / MOVEit, when one piece of common software hits hundreds of companies at once

The Cl0p group systematized a formidable approach: target a piece of software used by hundreds of organizations to compromise all of them at the same time. With MOVEit in 2023, then Cleo in 2024-2025.

The CVE-2024-50623 and CVE-2024-55956 vulnerabilities in Cleo allowed unauthenticated file uploads and arbitrary shell command execution. Hertz, Kellogg, and Sam's Club weren't using Cleo directly: their logistics providers were. The chain of trust had multiple levels. The attacker only needed to compromise a single link.

This is what's known as Nth-party risk: the risk introduced by your vendors' own vendors. An organization that works with an average of 286 vendors (2025 figure) only knows a fraction of the tools those vendors use themselves. Mapping this risk without dedicated tooling is practically impossible.

What this illustrates: your exposure doesn't stop at your direct vendors. It extends to everything they use to deliver their service to you.

Incident 3: exposed S3 bucket, 10 TB of customer data invisible from your IT system

In 2025, a global automaker left 10 TB of customer data publicly accessible through a misconfigured S3 bucket and hardcoded credentials in configuration files. The stored data wasn't held by the automaker. It was held by a cloud provider managing part of its customer infrastructure.

The automaker's customers had no visibility into this exposure. It didn't show up in any of their security tools. It was discovered by an external researcher scanning public S3 buckets, exactly what an attacker would have done.

What this illustrates: a cloud misconfiguration on the vendor's side is invisible from your own infrastructure. The only way to detect it is to look from the outside, the way an attacker would.

Incident 4: Eurofiber France, one subcontractor, thousands of customers impacted

In November 2025, Eurofiber France, a telecom operator used by numerous large French organizations, was compromised. The attack didn't target any of Eurofiber's customers directly: it targeted the operator itself.

Result: data belonging to SNCF, Orange, SFR, Auchan, Airbus, and several government ministries ended up exposed. A single subcontractor compromised, 3,600 customers impacted in cascade.

None of these organizations had any direct control over this risk. Their own security posture, however solid, changes nothing when the attack surface that gives way belongs to an infrastructure vendor shared by hundreds of customers.

What this illustrates: a customer's size and reputation offer no protection if the flaw lies with the vendor. A shared operator's attack surface effectively becomes that of each of its customers.

Incident 5: Cegedim Santé, the largest medical data leak ever revealed in France

In February 2026, Cegedim Santé's MLM software, used by thousands of medical practices across France, was compromised. The attack didn't target any hospital or clinic: it targeted the SaaS platform connecting all of them.

Result: 15 million patient records exposed, the largest medical data leak ever revealed in the country.

None of the medical practices involved had been negligent. Each had simply made the seemingly reasonable choice of using shared software to manage its patient records. The flaw wasn't anywhere on their end: it was in the shared infrastructure connecting them all.

What this illustrates: a shared vendor, used by a large number of small customers, becomes a high-leverage target for an attacker. The more customers depend on a single vendor, the greater the incentive to target it directly. When that vendor hosts sensitive data such as medical records, the data confidentiality stakes go far beyond an isolated technical incident.

In short: annual questionnaires capture what the vendor knows about itself, at a single point in time. The cloud changes continuously. The two are incompatible.

The logic behind a TPRM questionnaire is simple: you ask your vendor to describe its security posture, it responds, you assess the risks, you rank the criticality level. It's a method designed to evaluate vendor-related risks at a given moment, not to manage risk continuously in an environment that changes every week. The problem is that this logic rests on two assumptions that no longer hold in a cloud environment.

The first: that a vendor's posture is stable over time. A newly deployed instance, an added integration, a token created for a project and then forgotten: in an active cloud environment, the attack surface changes every week. What a vendor declared in January may no longer match what it exposes in June.

The second: that vendors themselves know what they expose. That's not always the case. An S3 bucket misconfigured by a dev team, a subdomain opened for a pilot project, a test API never disabled: these assets exist, are accessible from the internet, and the vendor's security lead may have no idea when filling out your questionnaire.

Gartner documented this in 2026: 62% of organizations still place too much trust in these self-declarations. The result is predictable: 97% suffered a supply chain breach the same year.

"A questionnaire tells you what the vendor believes it exposes. An external scan tells you what it actually exposes. That gap is often where the incident begins.", notes Florent Montel, co-founder and CFO of Patrowl.

In short: the annual questionnaire is no longer just operationally insufficient, it no longer satisfies regulatory requirements.

DORA, in effect since January 2025 for financial entities, requires formalized management of third-party ICT risk. A register of critical vendors, continuous monitoring, tested exit plans, contractually defined audit rights. SaaS vendors handling critical functions or data fall within scope, including customer relationship tools, HR platforms, and collaboration tools.

NIS2 extends these obligations to a broader scope: essential and important entities in energy, transport, healthcare, and digital infrastructure. The digital supply chain is explicitly in scope. An incident at a vendor affecting a covered entity can trigger 24-hour notification obligations and call into question that entity's accountability for managing third-party risk.

For risk and compliance functions, these regulations turn TPRM into an obligation with direct financial consequences. Third-party risk management programs can no longer settle for an annual review. The challenge is no longer just reducing risk, it's proving that monitoring is continuous and documented. Building this requirement into the organization's security strategy, rather than treating it as a one-off constraint, is what makes it possible to sustain this obligation over the long term, particularly for organizations operating in a multi cloud environment with dozens of vendors to monitor simultaneously.

"What we see with our clients under DORA is that the question is no longer 'are we monitoring our vendors' but 'can we prove it to the auditor'. Continuous monitoring is also an answer to that.", notes Nicolas Mattiocco, co-founder and CEO of Patrowl.

The operational answer isn't more questionnaires. It's external visibility into vendors' actual security posture, the same visibility an attacker would have if they scanned their perimeter before targeting them. Implementing this monitoring doesn't require disproportionate IT resources: here are the necessary steps to deploy it.

1. Inventory your vendors by actual access level

Before you can monitor, know what to monitor. List all your cloud vendors and classify them according to what they could reach inside your IT system if compromised, not according to contract value. This first step determines the resources needed at each criticality level.

• Critical level: vendors with direct access to your data or infrastructure (OAuth tokens, API connections, VPN access, customer data hosting)

• High level: vendors with indirect or limited access (collaboration tools, HR platforms, marketing tools)

• Standard level: vendors with no access to your IT system (logistics providers, general services)

A $500-a-month SaaS tool with OAuth tokens into your CRM is more critical than a $500,000 logistics provider with no digital access. Tiering should reflect actual access, not contract value.

2. Map what each critical vendor exposes from the internet

For each critical and high-level vendor, run an external mapping of what it exposes publicly, with no access to its systems, from the outside, exactly as an attacker would.

• Active subdomains: via public SSL certificates (tools: crt.sh, Amass, Subfinder)

• Exposed services: open ports, accessible APIs, admin interfaces (tools: Shodan, Censys)

• SSL certificates: expiration dates, covered domains, wildcard certificates (certificates covering every subdomain of a domain, e.g. *.patrowl.io)

• Technologies in use: identifiable stack via HTTP headers, robots.txt files, published job postings

• Exposed credentials: leaks in public databases (HaveIBeenPwned, DeHashed)

What you find is often surprising: subdomains from pilot projects never shut down, cloud instances created for a test and abandoned, unauthenticated APIs inherited from an old version of the service. Things the vendor itself sometimes no longer realizes it's exposing.

2bis. Map your vendors' own vendors too: the Nth-party risk

Nth-party risk refers to the risk introduced by your direct vendors' own subcontractors. It's the hardest part to control, and often the most exploited.

In the 2025 Cleo attack, Hertz and Kellogg weren't using Cleo directly. Their logistics providers were. The attacker only needed to compromise a single link to reach dozens of companies downstream.

To map this risk:

• Ask your critical vendors for the list of their own subcontractors with access to the data or services they deliver to you

• Identify third-party software embedded in the services you use: file transfer tools, payment platforms, embedded SDKs

• Monitor CVEs published on those third-party tools: a vulnerability in a tool used by your vendor concerns you directly, even if you don't use that tool yourself

• Build in a contractual clause requiring your critical vendors to notify you of any change in subcontractor with access to your data

You can't map the entire chain without dedicated tooling. But identifying the two or three levels closest to your critical data already represents a significant visibility gain.

3. Assess known vulnerabilities on identified assets

Once assets are mapped, cross-reference them against known vulnerability databases to identify critical exposures.

• Active CVEs on detected technologies: web server versions, identifiable frameworks, exposed CMS platforms

• Risky configurations: missing security headers, misconfigured CORS (Cross-Origin Resource Sharing: a mechanism controlling which domains can call your APIs), basic authentication on sensitive services

• Expired or soon-to-expire certificates: an expired certificate is a sign of operational neglect, often correlated with other maintenance delays

• Non-standard exposed ports: management services accessible from the internet (port 8443, 9200, 3389, 22 with no IP restriction)

Prioritize CVEs with a CVSS score (a standardized severity index, from 0 to 10) above 7 on directly accessible services. Those are the ones an attacker would exploit first.

4. Check active delegated access within your IT system

External monitoring looks at what your vendors expose from the internet. This step covers the reverse angle: what you've authorized on your own infrastructure's side. Together, the two form the real attack surface. Without one, the other leaves a blind spot.

• Active OAuth tokens: list all third-party applications authorized in your tools (Google Workspace, Microsoft 365, Salesforce, HubSpot) and check that each authorization is still necessary

• Active API keys: identify every API key issued to third parties, their access rights, and their last usage date

• Active webhooks: map outgoing webhooks to third-party endpoints and verify their destination

• VPN access and service accounts: list active third-party access to your network, with last connection date and justification

Don't hesitate to revoke any delegated access that's no longer active or whose vendor no longer has an active contract. Orphaned OAuth tokens and API keys are among the most frequently exploited attack surfaces.

5. Set up continuous monitoring of changes

The initial mapping is a starting point. What matters is detecting changes between two states: a newly opened subdomain, a service appearing on a non-standard port, an expiring certificate.

• Recommended minimum frequency: weekly for critical vendors, monthly for high-level vendors

• Alerts on newly exposed assets: any new subdomain or service detected at a critical vendor should trigger a check

• Alerts on critical CVEs: monitoring new CVEs on technologies identified at your vendors

• Alerts on certificate expiration: 30 days before expiration for critical vendors

An unplanned change in a vendor's exposure is often the first visible signal of an incident in progress, or of operational negligence creating a window of attack.

6. Validate critical exposures with human review

Automated scanners generate noise. A detected CVE isn't necessarily exploitable in the vendor's actual context. Before escalating an alert or contacting a vendor, confirm that the exposure is genuinely critical.

• Confirm actual exploitability: does the CVE apply to the exact version in use? Is the service genuinely accessible from the internet or filtered?

• Assess the potential impact on your IT system: if this service is compromised, what access to your infrastructure does the vendor hold?

• Document every validated finding: detection date, description, criticality level, vendor concerned, potentially impacted access

This human validation step is what separates operational monitoring from a flood of unqualified alerts. It's also what DORA and NIS2 auditors will check.

"A scanner can tell you a port 8443 is open at your vendor. It can't tell you whether that's an unauthenticated admin interface or a filtered internal service. That's where a pentester's eye makes the difference, between an alert that matters and noise that wears out the team.", adds Vladimir Kolla, co-founder and CTO of Patrowl.

7. Feed the result into your TPRM program and your regulatory documentation

External vendor monitoring is only useful if it feeds into a decision-making process.

• Update the vendor register with the results of each monitoring cycle

• Document findings and corrective actions requested from vendors (with deadlines and follow-up)

• Integrate critical alerts into your incident response process: a vendor with an exploitable critical CVE should trigger the same reflexes as an internal incident

• Produce a quarterly report for risk leadership and the executive committee: number of vendors monitored, open findings, resolved findings, trends

A centralized dashboard, updated with each monitoring cycle, makes it possible to see at a glance the risks associated with each critical vendor and to prioritize corrective actions without having to rebuild the picture for every audit.

For organizations under DORA, this reporting forms part of the documentation required to demonstrate active management of third-party ICT risk.

In short: monitor your vendors the way you monitor yourself, from the outside, continuously, with human validation on critical findings, and documentation built into your TPRM program.

TPRM programs that rely on questionnaires and point-in-time audits operate with a structural blind spot: they only see what vendors choose to show them, at the moment of assessment. Between two assessments, they're flying blind.

Patrowl approaches the problem from the outside. By continuously mapping the attack surface of critical vendors with ou EASM solution , with no access to their systems, no questionnaire, no dependence on their good faith, the approach provides visibility into what an attacker would see if they targeted your supply chain.

Exposed subdomains, expiring certificates, misconfigured cloud services, unauthenticated APIs, forgotten instances from old projects. Everything visible from the internet on the vendor's side is identified and tracked in real time. Every critical anomaly is reviewed by a certified pentester before being escalated to your teams. Not automated scoring: human validation.

In practice, Patrowl's Risk Insights module can be applied to a critical vendor's external perimeter the same way it's applied to your own attack surface: a dedicated organization is created for that vendor, and monitoring covers its certificates, DNS security, exposed services, mail security, and SSL/TLS strength. On the cloud storage front, for example, the module detects precisely the type of exposure that caused the exposed S3 bucket incident described above: public read permissions, write access left open, or full control mistakenly granted on an AWS S3, Google Cloud Storage, or Azure Blob Storage bucket. Each finding is rated by severity and paired with prioritized remediation, turning a technical alert into a concrete action for the vendor in question.

For organizations under DORA or NIS2, this continuous monitoring also produces the documented trail regulators require to demonstrate active third-party risk management.

"The ROI of external visibility into your vendors is simple: either you spend on monitoring, or you spend on handling the incident. The second option costs an average of $4.8 million, and your reputation.", concludes Florent Montel, co-founder and CFO of Patrowl.

Do you know what an attacker would see of your critical cloud vendors in 15 minutes?

For a long time, securing your IT system meant securing what you own. Your servers, your applications, your networks. The perimeter had a clear shape.

The cloud has changed that shape. Today, part of your IT system runs at vendors you don't administer. Critical data passes through tools your teams never deployed. Trusted connections were opened for projects that have since changed.

The result: your real perimeter is wider than you think. And the part you can't see is precisely the part attackers look for first. Implementing a cloud security approach that explicitly includes your vendors is no longer a differentiating option, it's a baseline requirement.

The question isn't whether your vendors will be targeted. It's whether you'll know before they become an entry point into your IT system, and whether you'll have a window to act.

What is TPRM in cybersecurity?

TPRM (Third Party Risk Management) refers to the processes used to identify, assess, and monitor cyber risks introduced by vendors and service providers. In 2025, the share of breaches involving a third party doubled to 30% according to Verizon. DORA and NIS2 have turned it into a formalized regulatory obligation with continuous monitoring requirements.

How can a compromised cloud vendor affect my organization?

Through the access it holds on your infrastructure: OAuth tokens, API connections, webhooks, VPN access. When that access is used from the vendor's compromised environment, the traffic appears legitimate in your logs. That's what happened with Salesloft Drift in 2025: 700 organizations impacted with no alert on the client side. A vendor can also act as a vector through the software it uses itself to deliver its service to you.

Why isn't classic TPRM enough against cloud threats?

Because it captures a frozen state. A vendor can answer its questionnaire perfectly in January and have a misconfigured service exposed in March. In a continuously changing cloud environment, the only relevant answer is continuous external monitoring. 62% of organizations still place too much trust in self-declarations according to Gartner 2026, with the results we're now seeing.

What regulatory obligations govern cloud vendor risk in France?

DORA (in effect since January 2025) requires financial entities to continuously monitor critical ICT vendors, maintain formalized registers, and hold contractually defined audit rights. NIS2 extends these obligations to a broader scope including the digital supply chain. In both cases, the annual questionnaire no longer satisfies the requirements: monitoring must be continuous and documented.

What is Nth-party risk and why is it hard to manage?

Nth-party risk refers to the risk introduced by your vendors' own vendors. In the 2025 Cleo attack, Hertz and Kellogg weren't using Cleo directly: their service providers were. The attacker only needed to compromise a single link to reach dozens of companies. Mapping this risk without dedicated tooling is practically impossible: an organization with an average of 286 vendors only knows a fraction of the tools those vendors use themselves.

How does Patrowl help manage cloud vendor risk?

Patrowl continuously maps the external attack surface of your critical vendors, with no access to their systems and no questionnaire. The approach identifies what an attacker would see from the internet on the vendor's side: exposed assets, expired certificates, misconfigured services, unauthenticated APIs. Every critical anomaly is validated by a pentester before being escalated to your teams. Continuous monitoring also meets DORA and NIS2 documentation requirements.

Verizon Data Breach Investigations Report 2025 · SecurityScorecard Global Third-Party Breach Report 2025 · CybelAngel "Every Vendor is a Vector" 2026 · Gartner Predicts 2026 · Reco AI "AI & Cloud Security Breaches 2025" · ANSSI Panorama de la cybermenace 2025 · IBM Cost of a Data Breach 2025