Three Breaches, Three Years. Client Tax Records in a Hacker's Hands. EY Still Won't Name the Platform That Failed.

There is one sentence EY does not want read out loud at a board meeting.

An unauthorized third party sat inside a support platform holding client tax documents for roughly two weeks, and Ernst & Young did not notice until eleven days after the intruder was already gone.

That is the 2026 breach. It is worth stating plainly before the corporate language arrives to soften it, because the corporate language is coming, and it is the whole story.

The timeline comes straight from EY's own regulatory filings and the reporting that followed.

An unauthorized party accessed a third-party IT service management platform between March 28 and April 12, 2026. EY uses that platform so its internal IT staff can support the teams doing tax work for clients. Support tickets submitted through it, EY says, may include documents containing client tax information. During that roughly two-week window, the intruder downloaded multiple documents belonging to an unknown number of EY clients. EY has confirmed the stolen files held personal and financial information used to prepare tax filings.

EY detected the anomalous activity on April 23. That is eleven days after the last recorded unauthorized access. The attacker finished, left, and only then did the alarm go off.

Notification letters were dated July 13. EY filed with the California Attorney General on July 15 and with Vermont regulators the next day, with other states following. The gap between the intrusion ending and the first client being told runs to roughly three months.

State breach filings describe the exposed data in more detail than EY's own notice did. The Vermont filing lists Social Security numbers, financial account codes, and credit and debit account information among the data that may have been affected. EY itself has not disclosed the specific types of information exposed, the name of the compromised platform, or how many people were affected. The firm operates in more than 150 countries, and the global total is not public.

EY has also declined to name the compromised platform. It described the system in its notice only as a third-party information technology service management platform. That is a category, not a name. A firm that spends its professional life demanding specificity from other people's disclosures reached for the vaguest available noun to describe its own.

Then, on July 27, the vagueness stopped being EY's to control.

The ShinyHunters extortion group listed Ernst & Young on its leak site and claimed the breach. The group set what it called a final warning deadline of July 31 and threatened to release the stolen data if EY did not engage.

ShinyHunters told BleepingComputer, which first reported the claim, that it reached EY through a supply-chain compromise and used the stolen credentials to get into EY's Jira, GitHub, and Azure environments. The group would not name the compromised third party or say what it took. BleepingComputer could not verify the claims, and EY has not confirmed that ShinyHunters was behind the attack or that any of those systems were touched. No data has been published as of this writing. These are the group's assertions, not established fact.

But the name ShinyHunters should stop any reader in the education, SaaS, or M&A world cold.

This is the same group behind the Instructure/Canvas intrusion that took down thousands of schools last year, the breach Cloudskope covered as it unfolded. Its 2026 leak-site listings and reported campaigns run through Charter, McGraw Hill, RingCentral, Brinks Home, and Carnival: identity-centric, SSO-focused, vishing the help desk, walking in through a supplier's side door rather than breaking down the fortress wall. We have been tracking this actor since Canvas. The technique that hit a Big Four firm's tax practice is the same technique that hit an ed-tech platform's student records. The target changes. The door does not.

Now hold the 2026 breach next to the two that came before it.

In 2023, EY was among the thousands of organizations swept up in the MOVEit Transfer mass exploitation. Data on tens of thousands of individuals moved through EY's instance of the file-transfer tool. Third-party software. Not a direct hit on EY's core.

In October 2025, researchers found a 4-terabyte SQL Server backup tied to EY's Italian entity sitting unencrypted and publicly accessible on Microsoft Azure. EY's response at the time is worth preserving in full, because it is a museum piece of incident language. The exposure was localized. It was immediately remediated. No client information, personal data, or confidential EY data has been impacted. The issue, EY said, was confined to an acquired entity and unconnected to EY's global systems.

Read that October statement again with April's breach in hand.

No client information impacted. Six months later, client tax records were being downloaded out of a support platform by a party that would go on to extort the firm.

Three incidents. Three years. Every one of them traced not to a sophisticated assault on EY's crown-jewel systems but to something at the edge: a file-transfer vendor, a misconfigured cloud backup, a support-ticket platform. Each time, the structural weakness was the same. Each time, the reassurance was the same. Each time, the data was somebody else's.

That is not bad luck. That is a pattern of conduct.

There is a particular discomfort in critiquing EY's controls, and EY knows it better than anyone, because selling controls is a large part of what EY does.

The firm's advisory arm sells cyber due diligence to private equity buyers. It sells SOC readiness and attestation support to companies trying to prove their controls to customers. It sits in deal rooms as the quality-of-earnings and tax advisor while telling the buy-side which risks are real. When EY signs an audit opinion, it is vouching, in the most formal language the profession has, that an organization's financial controls can be relied upon.

So the standard here is not the standard for a mid-market manufacturer. It is EY's own standard, applied to EY.

By that standard, plenty should have happened and did not.

One. The support platform should never have held the tax documents in the first place. Attaching a client's Social Security number and financial account details to an IT support ticket is a workflow failure before it is a security failure. Sensitive client data belongs in systems built and scoped to hold it, not in the ticketing tool the help desk uses to reset passwords. The single most damaging fact in this breach is not that the platform was compromised. It is that the platform was worth compromising, because EY put the crown jewels in the junk drawer.

Two. The third party should have been inside the attestation boundary. EY sells the idea that a vendor handling regulated data is an extension of your own attack surface. That is correct. It is also the exact principle EY did not apply to its own IT service management vendor. If a SOC 2 or internal control assessment of EY's tax practice did not include this platform in scope, the assessment had a hole shaped precisely like the breach that came through it.

Three. Detection should not have lagged the intrusion by two weeks. An adversary spent fourteen days downloading documents from a system holding regulated client data, and the monitoring did not fire until they were finished. For a firm that advises clients on threat detection maturity, an eleven-day-after-the-fact discovery is the kind of finding EY's own consultants would flag as a material deficiency.

Four. The disclosure should have named the platform. Withholding the vendor's name does not protect clients. It protects EY, and only briefly, because ShinyHunters was always going to fill the silence. When a breached firm declines to name the compromised system, every other customer of that same vendor is denied the one fact they need to check their own exposure. Specificity is not a courtesy. It is the entire function of a breach notice.

Five. The reassurance in October 2025 should have been earned, not asserted. No client data impacted is a claim that ages badly when it is issued before the investigation is complete and repeated as a talking point. A firm that instructs its clients to under-promise on incident calls broke its own rule in public.

Six. The count should be knowable by now. More than three months after detection, EY still cannot, or will not, say how many people were affected. The forensic work that produces that number is the same work EY sells to clients as incident response readiness. Either the number is not known, which is a capability problem, or it is known and withheld, which is a candor problem. There is no comfortable third option.

None of these six requires exotic technology. Every one of them is a governance question, and governance is supposed to be the home field.

The place this actually matters is not the security press. It is the M&A diligence process and the boardroom.

Ernst & Young is not a peripheral vendor to private equity. It is frequently the center of the room. EY performs quality-of-earnings work, structures the tax treatment of deals, advises on carve-outs, and audits portfolio companies once they are held. The documents that flow through those engagements are the most sensitive a company produces: tax filings, financial account structures, the personal data of executives and owners.

The breach that ShinyHunters is now trying to monetize hit the platform supporting EY's tax practice. The data class is client tax documents. If your fund, your management company, or one of your portfolio companies has done tax work with EY, the honest position today is not reassurance. It is a live question: was our data in one of those support tickets?

EY has not given you the number, the names, or the platform. So the burden falls to you to ask.

For a deal team mid-process, the implication is sharper still. Diligence assumes the advisors in the room are a safe pair of hands for the data they are handed. That assumption is not automatically true this week. A buy-side team relying on EY for tax or QoE work on a live transaction should know whether the data it is feeding into the engagement touches the compromised environment, and should document that it asked.

This is where the attestation gap becomes concrete. An attestation, a SOC 2 report, a clean audit opinion, tells you that a defined set of controls operated over a defined boundary during a defined window. It does not tell you the boundary was drawn in the right place. EY's support-ticket platform is the perfect illustration: a system almost certainly outside the boundary of whatever attestations covered EY's client-facing work, holding data that was squarely inside the risk. The certificate was clean. The data still walked out. That distance, between what the paper certifies and what an attacker can actually reach, is the gap that keeps closing deals from being safe deals.

For a board, the incident is a governance exercise with the names filled in. Here are the questions worth putting on the record.

Which of our advisors and auditors hold our regulated data, and in which systems? Are those systems inside the scope of the attestations we accept from them, or merely adjacent to it? When did we last confirm that our most sensitive third-party engagements have monitoring that would catch a two-week exfiltration in less than two weeks? If our primary audit or tax firm suffered this exact incident, what is our notification and containment path, and have we ever tested it? And the uncomfortable one: do we treat a clean attestation from a brand-name firm as the end of diligence, or the beginning of it?

There is a larger point underneath all of this, and it is the one the notification-recap coverage keeps missing.

When an accounting firm is breached, the firm is not the victim. The clients are. EY will absorb the litigation, the regulatory attention, the reputational bruise, and it will continue booking tens of billions in annual revenue. The people whose Social Security numbers and financial account details are now sitting in ShinyHunters' inventory did not choose that platform, did not attach their own tax documents to a support ticket, and did not get told for three months. They trusted the brand. The brand outsourced the risk to a vendor it will not name and then outsourced the consequences to them.

That is the model. A firm that certifies trust for a living turned out to be, three times over, a conduit for its collapse.

Reporting: EY's breach notifications to the California and Vermont attorneys general; BleepingComputer (Lawrence Abrams), which first reported the ShinyHunters claim; and coverage by Cybersecurity News and Cybernews. The intrusion method and the claimed access to EY's Jira, GitHub, and Azure environments are ShinyHunters' assertions to BleepingComputer and remain unverified by EY.