Ernst & Young began notifying clients this week of a breach affecting a third-party IT support platform used by EY personnel for tax-related work.
An unauthorized party accessed EY's IT service management platform from March 28 to April 12, 2026. EY uses the platform so internal IT staff can support teams handling client tax engagements. Support tickets submitted through that platform often include document attachments containing client tax filings. EY detected anomalous activity on April 23 and began an investigation. The company has since filed breach notifications with the California and Texas attorneys general, naming at least 1,366 affected individuals in those two states.
BleepingComputer reported that the ShinyHunters extortion group has claimed responsibility, adding EY to its dark web leak site with a July 31, 2026 deadline. The group alleges it obtained EY credentials through a supply-chain compromise of the vendor operating the ITSM platform, then used those credentials to access client documents. ShinyHunters also claims those credentials opened EY's Jira, GitHub, and Microsoft Azure environments. EY has not confirmed that ShinyHunters was the responsible party or that internal systems beyond the ITSM platform were affected. Exposed data potentially includes names, home addresses, Social Security numbers, bank account numbers, payment card data, and other information used in preparing tax filings. Affected clients are being offered 24 months of identity monitoring through Experian.
Two things are worth pulling out of the reporting.
What scanners would have missed
The breach did not originate inside EY's own code. No SAST tool scanning EY's repositories would have reached the vendor's platform. No DAST tool crawling EY's external endpoints would have mapped the ITSM system as part of EY's attack surface. The attack surface was a third-party SaaS tool, operated by a separate organization, carrying EY client data.
This is the failure mode that CVSS-based scanning cannot see. A scanner assigns a severity score to a vulnerability it can observe in your own environment. It has no model of which third-party tools hold your data, who can authenticate into them, or what happens to your clients' documents if a vendor credential is compromised.
Four gaps that standard tooling cannot close:
- SAST has no visibility into vendor codebases or vendor infrastructure.
- DAST crawls your perimeter, not the vendor's authentication flow.
- SCA maps your dependencies, not the data sensitivity of what flows through a trusted partner's system.
- CVSS scores do not reflect the blast radius of a federated trust relationship.
The EY incident is a data-classification and trust-boundary problem. That is why no standard scanner would have flagged it.
What Sekura would have shown
Sekura's Phase 5, exploit-chain analysis, is where this kind of multi-hop attack path becomes visible.
The chain here had three links: the vendor's credential store was the entry point; EY's ITSM instance was the pivot; client tax documents were the payload. A scanner evaluating any single link in isolation would not produce that picture.
Sekura's exploit-chain agent would have started by mapping the full trust graph: which external platforms have authenticated access to client data, what credential is needed to read document attachments, and how many clients are exposed if that credential is compromised. From that mapping, it would have synthesized a finding showing the data reachable with one compromised vendor login. Not a "medium: exposed support portal" label. A precise statement of blast radius: bulk client SSNs and financial data accessible through a single federated credential.
I think the hardest part of this class of problem is that it requires treating your vendors' access to your data with the same rigor you apply to your own code. Most security programs do not do that.
The bigger pattern
This is a third-party supply-chain breach. The victim is a Big 4 firm, the data is among the most sensitive a professional services organization handles, and the entry point was a support ticket system with no CVE attached to it.
Supply-chain breaches follow a consistent structure: a trusted vendor holds data that belongs to the customer, the vendor's security controls do not match the data's sensitivity, and the customer has no direct visibility into the vendor's access model. The EY incident fits that structure.
We are in a period where sensitive data has accumulated inside SaaS workflows that were designed for operational convenience. The access control requirements of the data those workflows now carry were not the original design constraint. That gap is where supply-chain attacks find purchase.
If you want to see what proof-first looks like on your own third-party attack surface, book a POC.