SURIQ
The most sensitive data a company holds rarely leaks from the system built to guard it. It leaks from the tooling wrapped around that system. Ernst & Young, one of the four large global accounting firms, is now telling clients that attackers reached client tax filings and financial records not through its audit or tax platforms, but through a third-party IT support system its own technicians used. The documents were sitting in support tickets. That single detail is the story, and it is one most defenders have not priced into their threat model.
EY began notifying affected individuals this month. According to its breach notification and reporting by BleepingComputer and Security Affairs, an unauthorized party had access to the platform between March 28 and April 12, 2026, and EY detected the activity on April 23. The notification letters are dated July 13. The firm says the exposed documents held personal and financial data used to prepare tax filings, including information tied to individuals' investment holdings with EY's institutional clients. Reporting on the state breach filings indicates the exposed data may include Social Security numbers and financial account details. EY has not named the vendor, has not said how the platform was accessed, and says no group has claimed the theft.
The ticket queue is a copy of everything you protect
An IT service management platform, the software behind a support ticket, does not have a sensitivity level of its own. It inherits the sensitivity of whatever gets attached to a ticket. A technician troubleshooting a failed export attaches the export. Someone debugging a filing attaches the filing. The platform becomes a quiet second copy of the exact records the primary system spends its whole budget defending, and that copy is governed by help-desk rules, not data-protection rules.
Two things make this worse than it sounds. Attachments outlive their tickets: the incident closes, the file stays. And the access model is inverted, because support staff and their tooling are given broad read access across many customers' cases by design. So the place with the least data governance holds a wide, long-lived slice of the most regulated data you have. Very few teams apply the retention limits, upload controls, or access reviews to their ticketing system that they apply to the system of record. That gap is the attack surface.
This is the Okta support-system breach again
We have seen this exact shape before. In late 2023, Okta disclosed that an attacker read files inside its customer support case management system over roughly three weeks, affecting 134 customers. Some of those files were browser session recordings that contained live session tokens, and the attacker used them to hijack the accounts of five customers. Okta traced the root cause to service-account credentials that ended up saved in an employee's personal Google profile. The breach was the support system, not the identity platform everyone actually worried about.
The pattern is not limited to help desks. It is the same failure that put customer data at risk when a connected app handed over Salesforce records without the core being touched, and when a poisoned vendor script stole from Polymarket users while its servers stayed clean. The breach keeps arriving through the peripheral relationship, the tool or the vendor bolted onto the system of record, because that is where the data governance thins out and the monitoring stops.
Why the breach ran for weeks before anyone noticed
Look at the clock on the EY incident. Access ran from March 28 to April 12. EY caught it on April 23, eleven days after the intruder had already left. Clients were notified starting July 13, about eleven weeks after detection. The exfiltration window closed before detection even began.
That late detection is structural, not a lapse. When the breached system is a third-party service you do not run, your telemetry ends at the sign-in boundary. You see your users authenticate to the vendor. You do not see the vendor-side admin actions, the bulk downloads, the API tokens, or the anomalous access that actually constitute the breach, because those logs live in the vendor's tenant. Okta's own postmortem cited a two-week logging gap for the same reason. If the only signals you hold stop at the login page, the breach is invisible to you until the vendor tells you, and vendors are slow.
The fix is to stop treating a critical SaaS platform as a black box. Where the vendor exposes an audit or admin activity log, pull it into monitoring you control and alert on the events that matter: a service account downloading in bulk, access from a new location, a spike in case exports. A SIEM is worth little on a system whose logs you never ingest. Treat vendor audit logs as a feed to collect, not a report to request after the fact. The same logic is why data-theft extortion that never encrypts anything is caught by watching access and movement, not by waiting for a ransom note.
Keep the sensitive file out of the ticket
Detection is the second line. The first is not letting the regulated document reach the ticket queue at all. Decide what is allowed to be attached to a support case, and enforce it at the point of upload rather than trying to purge it later, because retroactive cleanup never catches everything and the exposure window here was only two weeks. Redact or reference sensitive records instead of pasting them in. Set a hard retention limit so attachments do not survive the ticket that needed them. Review who and what can read across cases, and cut the standing broad access that support tooling defaults to.
If you are on the other side of this, a client whose data sits inside a vendor's support system, you have almost no visibility into their breach and no way to detect it yourself. The one control you own is what you send. Assume anything you attach to a vendor's support ticket may be read by whoever next compromises that vendor, and scope it accordingly. EY's clients did not choose the ticketing platform that exposed them. That is the uncomfortable part, and it is the reason minimizing what you hand over is the only durable answer.