What the Equifax indictment changed for banks, and what it did not
The Justice Department charged four Chinese military officers over the 2017 Equifax breach. For banks, the indictment settled who did it and changed nothing that mattered operationally: the data stayed exposed, the entry point stayed ordinary and accountability stayed with the data holder.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On February 10, 2020, the US Department of Justice announced an indictment charging four members of China’s People’s Liberation Army with hacking into Equifax in 2017. The breach had exposed personal information, including names, Social Security numbers and dates of birth, for roughly 147 million Americans. Prosecutors said the attackers exploited a known, unpatched vulnerability in the Apache Struts web framework on an Equifax online dispute portal. They then moved through the network and took data over a period of weeks. The defendants were believed to be in China and were unlikely ever to face trial in the United States. Equifax had already reached a settlement in 2019 with the Federal Trade Commission, the Consumer Financial Protection Bureau and the states.
Indictments of foreign intelligence officers are rarely about arrests. They are statements of attribution and deterrence. For a bank’s security and fraud leaders, the Equifax indictment is best read by separating what it changed from what it did not. Three things stayed exactly as they were: the stolen data remained in someone else’s hands, the entry point remained an ordinary unpatched system, and accountability remained with the firm that held the data. One thing did change: the likely motive looked like intelligence collection rather than quick fraud. Those four parts lead to different actions.
Unchanged: the data is out for good
Social Security numbers and dates of birth do not expire. Once a large share of the adult population’s identifying data is exposed, any process that treats knowledge of that data as proof of identity is weakened permanently. That includes account opening that relies on matching a name, date of birth and Social Security number, and call center verification built on questions whose answers can be found or bought.
For banks and credit unions, static identifiers are claims, not proof. Identity proofing has to combine several independent signals. Typical ones are verification of a government document, checks that the device and network look normal, and behavioral signals during the application. Possession of a channel the institution already trusts, such as a known phone number or a banking app, adds another. Knowledge-based questions can remain one weak signal among several. They should never decide the outcome alone.
The same applies after onboarding. Account recovery, change of address, adding a payee, raising a transfer limit and resetting a password are all moments where a fraudster with stolen identifiers can take over a genuine account. Institutions that strengthen onboarding but leave recovery flows dependent on personal data have moved the weak point rather than removed it. A practical review lists every customer journey that changes contact details or credentials, records which signals each relies on, and flags any that a person holding stolen identifiers could complete.
Unchanged: the entry point was a known flaw
The indictment confirmed the published account: attackers came in through a vulnerability for which a fix was available. A sophisticated state actor used an ordinary door. That is uncomfortable for any institution that assumes nation-state attackers require nation-state defenses.
Equifax’s own account, and later congressional reviews, also pointed to failures that let the intrusion run for weeks. An expired certificate on a network monitoring device meant encrypted traffic was not being inspected, and sensitive data was reachable from the compromised application. Neither is exotic.
A bank can ask three plain questions about each internet-facing application. Is it patched within a defined window? What data can it reach, and does it need that access? Would anyone notice if that data left in bulk? The third question is often the weakest. Alerting on unusual query volumes and large outbound transfers from application servers is a modest control that would have shortened many breaches.
The second question deserves equal attention. A customer-facing web application rarely needs direct access to a full table of Social Security numbers. Placing sensitive data behind a service that returns only what each transaction requires, and limiting the database accounts that applications use, means a compromised front end yields far less. These are design decisions that cost little when a system is built and a great deal when it is retrofitted. Security architecture reviews for new customer applications should ask what the application can reach, not only whether it is patched.
Unchanged: accountability stays with the data holder
Naming a foreign military unit did not shift responsibility for protecting the data. Regulators, courts and customers judged Equifax on its controls, not on the identity of the attacker. Financial institutions should assume the same. Under the Gramm-Leach-Bliley Act and the safeguards rules that implement it, institutions are responsible for protecting customer information regardless of who attacks them.
Attribution can matter in one place: insurance. Policies may contain war or state-actor exclusions whose application to a cyberattack is contested. Risk and legal teams should review that language with brokers and counsel before an incident, and understand what evidence an insurer might cite. That review does not reduce regulatory scrutiny. It reduces financial surprise.
Changed: the likely motive
The Equifax data was not seen circulating in criminal markets in the way stolen data usually is. An intelligence motive suggests a different use: building profiles of people of interest, such as those with security clearances or in sensitive roles, by combining financial data with other stolen datasets.
That is relevant to banks that serve government employees, defense contractors and senior executives, and to the controls around their own staff data. Customer records for those groups deserve tighter access controls and closer monitoring of who queries them. Human resources and payroll data about a bank’s own employees is valuable for the same reason. Data minimization, access monitoring and alerting on bulk queries protect against both the fraudster and the intelligence collector, and they cost the same either way.
With hindsight
None of the four defendants has been tried in the United States. The case sits alongside the Office of Personnel Management and Anthem breaches as large thefts of Americans’ personal data attributed to Chinese state actors. Together they point to deliberate collection at scale.
The identity proofing argument strengthened over time. Synthetic identity fraud, built partly on real Social Security numbers, grew into a major concern for lenders. The Social Security Administration began its electronic Consent Based SSN Verification service in June 2020, letting financial institutions confirm, with consent, that a name, number and date of birth match. NIST’s revised digital identity guidelines, finalized in 2025, kept knowledge-based questions out of identity proofing. Within months of the indictment, pandemic relief and unemployment fraud showed at scale what stolen static identifiers could do against processes that trusted them.