The Ceva Logistics Breach Shows Why Your Vendor's Vendor Is Your Problem

None of the companies whose customers just had their data exposed were the ones that got hacked. That’s the part of the Ceva Logistics breach worth sitting with longer than the list of affected brands. A cyberattack that began July 29 against a shipping and logistics company most consumers have never heard of is now rippling through a bank, a football club, an eyewear retailer, a major online retailer, and Valve’s Steam hardware business, and every one of them is explaining to customers that their data was exposed by a partner’s partner, not by their own systems.

What happened

Ceva Logistics is a France-headquartered contract logistics and shipping company that operates warehouses across Europe on behalf of other businesses, the kind of vendor most of its clients’ customers never interact with directly or even know exists. According to reporting, the attack began on July 29 and has affected at least eight of Ceva’s European warehouses. On August 1, Ceva confirmed to affected customers that a cyber intrusion was impacting part of its European contract logistics operations and said its security team had activated response protocols, with the investigation still ongoing as of the most recent reporting.

The practical effect showed up downstream. Companies that route their shipping and warehousing through Ceva started notifying their own customers that data had been exposed, because the information needed to fulfill an order, name, address, phone number, email, sometimes order details, lives with the logistics provider actually handling the box.

Who’s been affected so far

Reporting names several companies whose customer data was exposed through the Ceva breach, despite none of them being the party that was actually compromised:

Company	What they do	What was reportedly exposed
Bol	Dutch online retail giant	Customer shipping details via its warehousing partner Ceva
ING	Banking group	Customer shipping information
Ajax	Football club	Customer/fan shipping information
Ace & Tate	Eyewear retailer	Customer shipping details
Valve (Steam)	Gaming platform, hardware sales	Names, addresses, phone numbers, Steam-linked emails, hardware type and price ordered

That’s a retailer, a bank, a sports club, and a gaming platform, four businesses with almost nothing in common except a shared shipping vendor. That’s exactly the pattern that makes third-party breaches harder to reason about than a direct one: the blast radius doesn’t follow industry lines, it follows the vendor relationship graph, which most companies don’t map with the same rigor they map their own infrastructure.

Why this is a fourth-party problem, not a vendor problem

Most security programs think in terms of vendor risk: who do we contract with, what access do they have, did we review their SOC 2 report. That model assumes the risk stops at your direct vendors. The Ceva breach is a clean example of why it doesn’t. Bol’s relationship is with Ceva. Ceva’s security posture, patch cadence, and internal access controls are things Bol has limited visibility into and essentially no control over, and yet a failure there becomes Bol’s customer notification problem within days.

Your company
  -> Vendor (e.g. a logistics or fulfillment partner)
       -> Vendor's own subprocessors, warehouses, regional partners
            -> A breach here is invisible to you until it's already happened

This is the same structural gap we’ve written about for AI vendor contracts: the risk that actually materializes often sits one or two hops past the relationship you directly negotiated and can audit. A vendor security questionnaire covers the company you signed a contract with. It rarely reaches the subprocessors that company relies on, and those subprocessors are where a lot of real exposure lives.

What to actually do about it

If you run a business that ships physical goods, handles customer data through a logistics or fulfillment partner, or otherwise depends on a vendor that in turn depends on other vendors, a few concrete steps are worth taking now rather than after your own version of this incident:

1. Map subprocessors, not just direct vendors. Ask every vendor with access to customer data which third parties they rely on to deliver the service, and get that in writing, not just in a sales conversation.
2. Put a real breach-notification clock in vendor contracts. A clause that says “reasonable time” is not a clause. Specify a number of hours or days, and make it enforceable.
3. Build an incident response runbook for the scenario where you find out from a vendor’s disclosure, not your own monitoring. That’s a fundamentally different starting position, you’re reacting to someone else’s timeline and someone else’s forensics, and your plan should say explicitly who owns customer notification in that case.
4. Ask what data actually needs to flow to a fulfillment partner. Ceva needed names, addresses, and enough order detail to ship a package. It’s worth periodically checking whether the data flowing to any given vendor is the minimum required for the service, since every field you send is a field they can lose.

If you’re building or auditing an incident response process and want a second set of eyes on where the actual exposure sits in your vendor chain, that’s exactly the kind of review our team does alongside infrastructure and security work.

The takeaway

The companies that had to notify customers this week did nothing wrong in the conventional sense, they picked a large, established logistics provider and trusted it to secure the data flowing through it. That trust wasn’t unreasonable, and it also wasn’t sufficient. If your incident response plan only accounts for a breach of your own systems, the Ceva Logistics story is a reminder to extend it one hop further, because that’s exactly where this one landed.