Valve–CEVA Data Breach: Minimize Data Shared with Vendors

Valve says a cyberattack against its European shipping partner, CEVA Logistics, likely exposed delivery information belonging to Steam hardware customers. The incident is a useful example of both sides of third-party data sharing: a supplier can become another breach path, but limiting what it receives can keep account credentials and payment data outside that path.

The practical lesson is not that every vendor transfer belongs in a secret-sharing tool. Shipping records need an operational system. Passwords, API keys, recovery codes and temporary access material do not belong in those records, tickets or ordinary email threads. They need a separate, short-lived delivery path and a clear revocation plan.

What Valve has confirmed

In a customer notice and a direct statement reported by PC Gamer, Valve said the attack affected CEVA between July 29 and August 1, 2026. Valve learned on August 7 that information about some European Steam hardware customers was likely compromised and began notifying customers it could reasonably assume were at risk.

Valve said the delivery-related data may include a customer's name, street address, postal code, city, country, phone number, email address, and the type and price of the product ordered. CEVA retained this information for up to 90 days to support delivery, returns and order problems.

Valve also drew an important boundary around the incident. It said CEVA did not receive payment information, passwords, Steam Guard codes or unrelated Steam account information. On the evidence available, those data categories should not be described as compromised through this vendor.

What remains unknown

The public reporting reviewed for this article does not establish the initial access method, the total number of affected Valve customers, the complete data set taken from CEVA or an attacker attribution. CEVA's investigation was still in progress, and Valve said it was seeking the full scope of what was taken and how.

That uncertainty matters. A customer notification supports saying the incident and risk are confirmed; it does not support inventing a victim count, labeling the event as ransomware or claiming that every listed field was taken for every notified customer.

Delivery data can power convincing phishing

Names, addresses, contact details and exact purchase information are not login credentials, but they can make a fraudulent message look credible. Valve warned customers to expect email, SMS or telephone messages that reference a hardware order, quote a real address, request a redelivery or customs fee, or direct the customer to a fake sign-in page.

An attacker does not need the real password when the surrounding data can persuade the victim to enter it into a convincing copy of a trusted site. The safe response is to ignore links and payment requests in unexpected delivery messages and open the retailer or carrier through a known official address instead.

Minimize the supplier's breach radius before the incident

Map each transferred field to a business purpose. A supplier should receive only the data needed for its task. Document why each field is necessary, who can access it and which system remains the source of truth.
Set a deletion event, not an indefinite promise. Tie retention to delivery, the returns window or another measurable condition. Confirm how backups, exports, support cases and subcontractors follow the same schedule.
Keep secrets out of operational records. Do not place passwords, private keys, recovery codes or reusable API tokens in shipping notes, CRM fields, shared spreadsheets or ticket comments.
Use narrow vendor identities. Prefer named accounts, least privilege, short sessions and access that can be revoked without interrupting unrelated business processes.
Prepare for a supplier notification. Know which credentials must be rotated, which integrations can be disabled and how affected people will be warned through a verified channel.
Test the boundary. Ask whether a compromise of the supplier would expose only the intended operational data or also unlock internal accounts and recovery paths.

A separate path for credentials and recovery material

Sometimes a vendor engineer needs a temporary database password, deployment token, SSH key or recovery value. Sending it in the same email, chat or ticket that holds the operational context creates a durable copy and makes one compromised system sufficient to recover both the instructions and the secret.

For an approved ad-hoc transfer, an expiring encrypted one-time link can reduce plaintext copies in conversation history. Verify the recipient through a separate channel, set an expiry that matches the work window, confirm receipt, and rotate or revoke the value after use. For live transfers that should not leave a stored secret payload, a browser-to-browser mode can further reduce server-side storage, subject to endpoint and browser trust.

Secretus supports these narrow secret handoffs, but it is not a privileged access management system, a replacement for managed service identities or a general customer-record platform. It cannot protect a secret copied after viewing, a compromised recipient device, or an account that was already taken over. The transfer control must sit inside a broader identity, logging and revocation process.

Questions to ask every data-handling vendor

Which exact fields do you receive, and why is each one necessary?
How long does each copy remain in production, backups and support systems?
Which subcontractors and integrations can read or export the data?
Are credentials or recovery materials ever accepted in tickets or chat?
How quickly can we revoke access and rotate shared secrets?
What evidence will you provide after deletion or an incident?

The Valve notice shows why these questions should be answered before a breach. The supplier relationship created exposure to delivery data, while the decision not to provide passwords, payment details or Steam Guard codes preserved a meaningful boundary. Good data minimization does not prevent every incident; it limits what one incident can reach.