What the Equifax indictment changed for banks, and what it did not
In 2020, the US charged four Chinese military officers over the Equifax breach. Knowing who did it settled an old question. For banks, it changed little that matters day to day: the data stays exposed, the door was ordinary, and the blame stays home.
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.
Two-minute summaryThe dek and the first sentence of each section, quoted from the article
In 2020, the US charged four Chinese military officers over the Equifax breach. Knowing who did it settled an old question. For banks, it changed little that matters day to day: the data stays exposed, the door was ordinary, and the blame stays home.
- The week On February 10, 2020, the US Department of Justice announced an indictment charging four members of China’s People’s Liberation Army, the country’s armed forces, with hacking into Equifax in 2017.
- A short primer: how data is stolen and how it is used The moving parts are few, and they need no technical training to follow.
- Unchanged: the data is out for good Social Security numbers and dates of birth do not expire.
- 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.
- Unchanged: accountability stays with the data holder Naming a foreign military unit did not shift responsibility for protecting the data.
- Changed: the likely motive The Equifax data was not seen circulating in criminal markets in the way stolen data usually is.
- The institution that took Equifax seriously Getting there is a sequence, not a single project.
- Where stolen personal data could still reach a bank’s customers Several more checks belong on the same list: a complete inventory of the systems the public can reach over the internet; a record of what sensitive data each main customer-facing application can reach, and whether it needs all of it; evidence that monitoring tools, certificates included, are still working; and review of who looks up the records of cleared, government and executive customers, and of how access to employees’ HR and payroll data is controlled.
- With hindsight The indictment did what indictments of this kind usually do: it named people and put a public marker down.
The week
On February 10, 2020, the US Department of Justice announced an indictment charging four members of China’s People’s Liberation Army, the country’s armed forces, with hacking into Equifax in 2017. Equifax is one of the three big credit bureaus: companies that keep a running file on almost every adult’s borrowing and repayment history, which lenders consult before approving a card, a loan or a mortgage. That makes a credit bureau an unusually rich target.
The 2017 breach had exposed personal information, including names, Social Security numbers and dates of birth, for roughly 147 million people. That is not a list of customers who chose to do business with Equifax. It is, in practice, a large share of the American adult population.
The indictment was returned by a federal grand jury in Atlanta and announced by Attorney General William Barr. It named four men alleged to be members of the People’s Liberation Army’s 54th Research Institute and charged them on nine counts. The charges included conspiracy to commit computer fraud, conspiracy to commit economic espionage and conspiracy to commit wire fraud. The espionage charge reflected a detail that got less attention: prosecutors alleged the attackers also took Equifax’s own trade secrets, such as its database designs, along with the personal data.
Prosecutors described how the attackers got in. They exploited a known, unpatched vulnerability in the Apache Struts web framework on an Equifax online dispute portal, the website consumers use to challenge errors on their credit reports. A web framework is the ready-made scaffolding that developers build websites on. A vulnerability is a flaw in that scaffolding that lets an outsider do something they should not. “Known” and “unpatched” are the uncomfortable words here: a flaw had been publicly identified and a fix, or patch, was available, but it had not been applied to that system.
The timeline made the point sharper. The Apache Struts flaw had been disclosed, with a fix, in March 2017. According to the Federal Trade Commission’s later complaint, Equifax’s security team ordered the patch applied within 48 hours, but nobody followed up to confirm that it had been. The attackers got in during May, and Equifax did not detect them until late July. The company disclosed the breach in September 2017. Its chief executive, chief information officer and chief security officer had all left within weeks of that announcement.
Once inside, the attackers did not grab what they could and run. They moved through the network and took data over a period of weeks, in a way that suggested patience and planning. The indictment described thousands of database queries to learn how Equifax’s data was organized, and stolen data broken into small compressed files. It also described traffic routed through servers in many countries to hide its origin, and logs wiped to cover the attackers’ tracks.
The case also fitted a pattern. In 2014, the Justice Department had indicted five officers of a different PLA unit for hacking American companies, the first criminal charges it had brought against known state actors for hacking. In late 2018 it had launched a program focused on Chinese economic espionage. Naming foreign officers in public had become a regular tool of US policy.
The indictment was unlikely to put anyone in a courtroom. The defendants were believed to be in China and were unlikely ever to face trial in the United States. Indictments like this one are largely a public statement: we know who you are, and we are saying so.
The business consequences for Equifax had already arrived. In July 2019 the company had reached a settlement with the Federal Trade Commission, the Consumer Financial Protection Bureau and 50 states and territories, worth at least $575 million and potentially up to $700 million. It included money for consumers, a civil penalty, and a required information security program with independent assessments every two years. So by the time the attackers were named, the regulators, the courts and the public had already judged the company on what it did and failed to do, not on who had broken in.
Consumers had gained some tools in the meantime. A 2018 federal law made credit freezes free at all three national bureaus from September of that year, so anyone could lock their credit file against new accounts at no charge. Under the 2019 settlement, every US consumer became entitled to six additional free Equifax credit reports a year for seven years, starting in January 2020, the month before the indictment. The settlement also offered free credit monitoring to people whose data had been exposed. Neither measure protected existing accounts, which is where much of the later fraud would land.
For anyone running a bank, a credit union or any business that holds personal data, the week was a prompt to check that every door is actually locked. Some of the most capable attackers in the world had come in through an ordinary unlocked one.
Indictments of foreign intelligence officers are rarely about arrests. They are statements of attribution, meaning a formal claim about who carried out an attack, and of deterrence, meaning a signal that such attacks have consequences. Nobody expected the four named officers to appear in an American courtroom.
For a bank’s leadership, 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 points lead to different actions, and each lands on a different part of the organization: fraud and customer operations, technology, legal and risk, and the teams that guard sensitive records. After a short primer, the sections below take the three unchanged points and the one change in that order. They then describe how an institution that absorbed all four tends to look, and what its leaders can ask.
A short primer: how data is stolen and how it is used
The moving parts are few, and they need no technical training to follow.
Personal identifiers. A Social Security number, a date of birth and a full name are what the industry calls static identifiers. They are “static” because they never change. Your password can be reset tomorrow; your date of birth cannot. For decades, many organizations have treated knowing these facts as proof that you are who you say you are. That worked tolerably when the facts were hard to find. It stops working once they have been stolen in bulk.
Identity proofing. This is the process of checking that a new customer is a real person and is the person they claim to be, usually at account opening. It is the bank’s equivalent of an airport passport desk.
Authentication. This is the check that happens later, every time an existing customer logs in, calls in or asks for a change. If identity proofing is the passport desk, authentication is the boarding-pass scan at the gate.
Knowledge-based verification. These are the familiar questions about which streets you have lived on or the amount of your last car payment, often built from credit bureau data. Their weakness is obvious once said aloud: if the answers come from the same kind of data that was stolen, a criminal holding the stolen data can answer them too.
Patching. Software is never perfect. When a flaw is discovered, the maker publishes a correction, called a patch, and every organization using that software is supposed to install it. In a large company with thousands of systems, keeping up is a constant, unglamorous job that is never quite finished.
Exfiltration and segmentation. Exfiltration is the security term for data leaving an organization without permission. Segmentation is the practice of dividing a network so that a system in one part cannot freely reach systems in another. A well-segmented network is like a building with locked internal doors: getting through the front door does not open every office.
Attribution. This is the process of deciding who carried out an attack. Governments attribute attacks using intelligence, forensic evidence and, sometimes, information that cannot be made public. A criminal indictment is one of the most formal ways of stating an attribution, because it must be backed by evidence a prosecutor is prepared to put before a court.
With those terms in hand, the four points become easier to see.
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. Learning who took the data does not change the fact that it is out.
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.
There is a twist that makes this harder. Banking rules themselves require institutions to collect these identifiers. The customer identification program rules under the USA PATRIOT Act require a bank to obtain a name, date of birth, address and an identification number before opening an account. For a US person, that number is usually a Social Security number. The same rules require the bank to verify identity through documents or other methods, on a risk basis. Collecting the identifiers is mandatory. Treating them as sufficient proof is a choice.
How stolen identifiers are used
Stolen identifiers feed several distinct kinds of fraud, and each hits a different control:
- New account fraud uses a real person’s identifiers to open a card, loan or deposit account in their name.
- Synthetic identity fraud combines a real Social Security number with invented details to create a person who does not exist, then builds credit slowly before borrowing heavily and disappearing.
- Account takeover uses identifiers to convince a call center or a recovery process to hand control of a real account to the fraudster.
- Phone number takeover uses identifiers to persuade a mobile carrier to move a victim’s number to a new device, so that text message codes go to the fraudster.
The last of these shows how one institution’s weakness becomes another’s. A bank that relies on text message codes inherits the identity checks of every mobile carrier its customers use.
What stronger identity proofing looks like
Identity proofing has to combine several independent signals, so that defeating one is not enough. Typical ones are:
- Verification of a government document, such as checking a driver’s license or passport for signs of tampering and matching it to a live photo of the applicant.
- Checks that the device and network look normal, for example that the phone or laptop is not one seen in hundreds of other applications, and that the connection is not routed through services commonly used to hide location.
- Behavioral signals during the application, such as whether the person types their own name naturally or pastes it in, which tends to differ between genuine applicants and people working from a stolen list.
- Possession of a channel the institution already trusts, such as a known phone number or a banking app that the customer has used before.
Knowledge-based questions can remain one weak signal among several. They should never decide the outcome alone.
Consumer credit freezes do not close the gap either. A freeze stops a lender from pulling the consumer’s file at the bureaus, which blocks much new credit fraud. It does nothing to protect an existing account, and deposit accounts are often opened after checks against other databases. Institutions should not treat a rise in freezes among their customers as a substitute for their own controls.
The trade-offs of stronger proofing
Stronger proofing has costs that a sceptical executive should weigh honestly. Each extra check adds friction, and some genuine applicants abandon the process. Document checks can fail people who lack a current driver’s license or passport, who are disproportionately older, younger or lower income. Device checks can flag legitimate customers who share a computer or use a privacy service. An institution that tightens proofing without measuring these effects can lose good customers and create fair lending questions.
The answer is to measure both sides. Useful measures include fraud losses by channel, the share of applicants sent to additional checks, the share who then abandon, and the share of flagged applicants later found to be genuine. Offering a fallback, such as verification in a branch, keeps the door open for people the automated checks cannot handle.
The less visible risk: after the account is open
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. Criminals call this account takeover, and it is often more lucrative than opening a fake account, because the real account already has money and a history.
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. At a typical regional bank, that review might turn up something like this: online password reset requires a code sent to the customer’s phone, which is good; but the call center will change the phone number on file for anyone who can recite the account holder’s Social Security number, date of birth and address. The second process undoes the first. Finding that kind of gap is the whole point of the exercise.
The call center as a control point
Phone channels deserve separate attention because they rely on people making judgment calls under time pressure. Several controls help without making service unbearable. Agents can call the customer back on the number already on file, rather than acting on a number the caller provides. A change to a phone number or email can trigger a notice to the old contact details, so the real customer learns of it. A short holding period after any contact change can block high-risk actions, such as adding a payee or raising a limit, until the change has had time to surface. Each control has a cost in customer patience, and each can be applied more strictly to higher-risk requests than to routine ones.
How the exposure differs by institution
The rules and the risk both vary by type of firm. Banks, credit unions and other creditors must run identity theft prevention programs under the Red Flags rules that followed the Fair and Accurate Credit Transactions Act. Broker-dealers and investment advisers registered with the SEC have their own version, Regulation S-ID. The underlying expectation is the same: identify the warning signs of identity theft in each type of account and respond to them.
The attack paths differ more. A credit union with a small member service team often relies on phone calls and personal recognition, which works until a fraudster with the right details calls a new employee. A regional bank has more channels to cover, each with its own vendor. A broker-dealer’s exposure is often the transfer of an entire account to another firm after a takeover, which can move a customer’s savings in one step. Each should test the recovery path that matters most to its own customers first.
Smaller institutions rarely build these controls themselves. Their onboarding, online banking and call center tools usually come from a core processor or a specialist vendor. The review then becomes a vendor question: which signals does the vendor’s process rely on, and can the institution change the settings or only accept the defaults.
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. In practice, even the most capable attackers prefer the cheapest route that works.
Equifax’s account to the Government Accountability Office, the investigative arm of Congress, also pointed to failures that let the intrusion run for weeks. Two stand out, and neither is exotic.
First, an expired certificate on a network monitoring device meant encrypted traffic was not being inspected. A little explanation helps here. Much of the data moving across a company’s network is encrypted, scrambled so that outsiders cannot read it. Security teams use monitoring tools that can unscramble and inspect that traffic to spot anything suspicious leaving the building. Those tools rely on digital certificates, which carry an expiry date. When the certificate expired, the inspection stopped, and nobody noticed that the post was empty.
Second, sensitive data was reachable from the compromised application. The dispute website could get to far more information than it needed to do its job.
The FTC’s complaint added two more details. Equifax’s security team had ordered the Struts patch, but nobody verified that it had been applied to the dispute portal. And once inside, the attackers found administrative credentials stored in plain text, which helped them reach other databases. Both are process failures rather than technology failures. An order to patch is not evidence of a patch, and a password file left in the open turns one compromised system into many.
Three tests for every internet-facing system
A bank can test each internet-facing application, meaning anything that customers or the public can reach over the internet, on three points: whether it is patched within a defined window, what data it can reach and whether it needs that access, and whether anyone would notice if that data left in bulk.
The third test 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. A server that normally sends out a few megabytes an hour and suddenly sends out gigabytes is behaving in a way it never has before, and somebody should get a phone call.
The second test 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.
A website for handling credit report disputes does not need the whole customer database behind it. If an attacker takes over the front end, the damage should then be limited to what the front end can reach. 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 as well as whether it is patched.
Patching as a measured process
Most banks have a patching policy. Fewer can show that it works for the systems that matter most. A useful program starts with a complete inventory of internet-facing systems, including those run by vendors and those set up by business units without central IT. It sets a deadline for critical fixes on those systems, measured in days rather than weeks. It verifies installation by scanning afterwards, rather than accepting a ticket marked complete. And it records every exception, with a compensating control and an owner, so that a system which cannot be patched quickly is at least watched more closely.
Examiners and auditors increasingly ask for exactly that evidence: the inventory, the deadlines, the scan results and the exceptions. Federal banking examiners have long expected patch management as part of an information security program, and the FTC’s 2019 order required Equifax to build one with independent assessments. A bank that can produce the four pieces of evidence on request is in a far stronger position than one that can describe its policy.
Testing that detection still works
The expired certificate at Equifax shows that a control can fail without anyone noticing. Detection needs its own tests. A security team can keep an inventory of the certificates its monitoring tools depend on, with alerts well before each expires. It can also run planned tests, in which a harmless but unusual transfer is staged from an application server to confirm that the alert fires and reaches a person. A control that has not been tested in the past quarter should be reported as unverified rather than as working.
Doors nobody knows about
The strongest objection to this section is that patching only closes known doors. Attackers also use flaws that nobody has disclosed yet, and no patching program can stop those. The other two tests carry so much weight for that reason. Limiting what each application can reach, and noticing when data leaves in bulk, reduce the damage whether the attacker came in through a known flaw or an unknown one. Patching shrinks the number of open doors. Segmentation and monitoring decide how much can be carried out through the ones that remain.
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. “A very capable adversary did this” is not a defense.
Which rules apply to whom
The Gramm-Leach-Bliley Act applies across financial services, but the detailed rules depend on the type of institution, and leaders should know which ones bind them:
- Banks follow the interagency guidelines on safeguarding customer information issued by the federal banking agencies.
- Federally insured credit unions follow the National Credit Union Administration’s security program rule and its guidelines.
- Non-bank financial institutions within the FTC’s jurisdiction, such as many mortgage brokers, finance companies and some fintechs, follow the FTC’s Safeguards Rule.
- Broker-dealers and SEC-registered investment advisers follow Regulation S-P.
State rules add to these. Financial firms licensed in New York, for example, are subject to the state’s cybersecurity regulation, which took effect in 2017. Counsel should confirm which combination applies, because a holding company can contain entities under several regimes at once.
That has a practical consequence for how boards hear about security. A report that dwells on how sophisticated attackers have become can create a comforting sense that some losses are unavoidable. The more useful report says which basic controls are in place, which are not, and how quickly gaps are closed.
The Equifax settlement shows what regulators expect a board to own. The FTC’s order required the company to designate a person responsible for its security program, run annual risk assessments and test its safeguards. It also had to oversee service providers that handle personal data and obtain annual certifications from the board or a board committee. Those are reasonable expectations for any institution holding customer data, whether or not it is under an order.
What a useful board report contains
A board report built on this section would carry a handful of measures. It would show the share of internet-facing systems patched within the deadline, the number and age of exceptions, and the results of the latest test that bulk-data alerts still work. It would show the share of account recovery journeys that require something more than personal data, and open findings from independent assessments. Each measure should come with a trend, because direction matters more than any single quarter’s figure.
Accountability extends to vendors
Responsibility also follows data into vendors. Many banks rely on credit bureaus, core processors and fintech partners that hold or process their customers’ information. In 2023 the federal banking agencies issued joint guidance on managing risks from third-party relationships, which expects banks to scale due diligence and monitoring to the risk each relationship carries. A vendor’s breach of a bank’s customer data is still the bank’s problem in the eyes of its customers and supervisors.
Where attribution can matter: insurance
Attribution can matter in one place: insurance. Policies may contain war or state-actor exclusions whose application to a cyberattack is contested. Some insurance policies do not pay out for acts of war, and there is genuine disagreement about whether a cyberattack carried out by a foreign military counts.
Risk and legal teams should review that language with brokers and counsel before an incident, and understand what evidence an insurer might cite. A government indictment naming military officers is exactly the kind of document that could appear in such a dispute.
The question was live in early 2020. Two large companies hit by the 2017 NotPetya attack, which the US and UK governments had attributed to Russia’s military, were in litigation with insurers that had cited war exclusions to deny property claims. Those cases turned on how far traditional war wording could reach a cyberattack. An institution reading its own policy in light of the Equifax indictment was asking the same question before it had to.
That review does not reduce regulatory scrutiny, but it does reduce financial surprise, because the institution learns what its policy covers before it has to make a claim.
Changed: the likely motive
The Equifax data was not seen circulating in criminal markets in the way stolen data usually is. Ordinary criminals tend to sell or use stolen data quickly, because its value to them falls over time. Data that simply disappears suggests a different buyer.
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. A person’s debts, payment troubles and financial history can be useful to a foreign intelligence service looking for people who might be pressured or recruited.
The Equifax case was not isolated. The Office of Personnel Management breach, disclosed in 2015, exposed background investigation records for millions of people who had applied for security clearances. In 2019, the Justice Department charged a Chinese national over the Anthem health insurance breach. Financial records, clearance files and health data each tell an intelligence service something different. Combined, they can describe a person’s finances, history, contacts and health.
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. Employee files hold addresses, salaries, family details and sometimes health information, and a bank’s staff includes people with access to money, systems and sensitive clients.
Banks already have programs that can carry this work. Insider risk and fraud teams monitor unusual access by employees. Executive protection teams look after senior leaders. Treating the bank’s own staff data, and the records of its most sensitive customers, as assets that a foreign service might want links those programs to the information security team. Few institutions had made that link formal in 2020.
Watching who looks at sensitive records
Monitoring access to sensitive records works best when it is specific. An institution can tag the records of customers in sensitive roles, such as senior government officials, defense contractors and its own executives. It can then alert when a tagged record is viewed without a related service request, or by an employee outside the team that normally handles it. Periodic reviews of who has access, signed off by business managers, keep the list of authorized viewers short. The trade-off is friction for service staff, which is why the tagging should be narrow and the alerts tuned before they go live.
What attribution does give a security team
Attribution is not useless to defenders. Knowing that a particular state group is interested in financial data, and how it tends to operate, helps a security operations team decide which techniques to look for first. Public indictments and government advisories often describe those techniques in detail, such as routing traffic through many countries, splitting data into small files and wiping logs. A team that turns those descriptions into specific detection rules gets real value from attribution. The value lies in the techniques, not the names.
The encouraging part is that the defenses do not change with the motive. Data minimization, which means holding and exposing only the data a process truly needs, access monitoring and alerting on bulk queries protect against both the fraudster and the intelligence collector, and they cost the same either way.
Holding less
The simplest way to reduce what an attacker of any kind can take is to hold less. Retention schedules that delete personal data once it is no longer needed shrink the prize. The trade-off is that financial institutions have record-keeping duties of their own. Customer identification records, for example, must be kept for five years after an account is closed. A retention schedule should therefore be drafted with compliance and counsel, so that data is kept as long as the law requires and no longer, and so that copies in reporting and test systems are deleted on the same schedule as the originals.
The institution that took Equifax seriously
A well-run institution after Equifax tends to look like this:
- It treats personal identifiers as claims, not proof, in onboarding and in every later moment when an account can be changed.
- It knows its internet-facing systems, patches them within a defined window, and can show the board how often that window is missed.
- It limits what each application can reach, so that a breach of one system does not hand over everything.
- It watches for data leaving in bulk, and someone is responsible for acting on the alert.
- It has read its insurance policy with counsel and brokers before needing it.
- It gives extra protection to its most sensitive records, customer and employee alike.
Getting there is a sequence, not a single project. A practical order runs like this:
- First quarter. Inventory internet-facing systems, map which customer journeys can change contact details or credentials, and confirm that bulk-data alerts reach a named person who acts on them.
- Within six months. Close the weakest recovery paths, set and measure patch deadlines for internet-facing systems, and review insurance wording with brokers and counsel.
- Within a year. Reduce what each customer-facing application can reach, tighten access to the most sensitive customer and employee records, and report all of these measures to the board on a regular schedule.
The early steps are mostly about knowing where things stand. They cost little and make every later decision better informed. The later steps involve architecture and vendor changes, which take budget and time, and are easier to justify once the early steps have shown where the gaps are.
The ways institutions fall short are just as recognizable:
- Fixing the front door only. Investing heavily in onboarding checks while leaving phone-based account recovery relying on personal data.
- Measuring patching by averages. An average patch time can look healthy while a handful of critical, public-facing systems lag for months. The exceptions are where attackers go.
- Monitoring that nobody watches. Tools that generate alerts no one reviews, or that silently stop working, like the expired certificate that halted inspection at Equifax.
- Believing the threat story excuses the outcome. Assuming that a sophisticated attacker will soften the response of regulators or customers.
- Granting broad access for convenience. Letting applications connect to whole databases because it was quicker during the original build.
- Treating an order as a result. Accepting that a patch was ordered, or a control was approved, without checking that it is in place.
Where stolen personal data could still reach a bank’s customers
These need no technical knowledge to ask, and the answers will say a great deal:
- Which customer journeys let someone change a phone number, email address, password or payee, and could a person holding stolen personal data complete any of them?
- Where do we rely on knowledge-based questions as the deciding check, and what else do we look at there?
- What is our target time to install critical patches on internet-facing systems, and which ones are currently past it?
- If a large volume of customer data left one of our servers tonight, who would be alerted, and how quickly?
- Does our cyber insurance contain a war or state-actor exclusion, and what would an insurer need to show to rely on it?
Several more checks belong on the same list: a complete inventory of the systems the public can reach over the internet; a record of what sensitive data each main customer-facing application can reach, and whether it needs all of it; evidence that monitoring tools, certificates included, are still working; and review of who looks up the records of cleared, government and executive customers, and of how access to employees’ HR and payroll data is controlled.
The Equifax indictment was a moment of public clarity about who was responsible. For any organization holding personal data, the more useful clarity is internal: knowing exactly where the doors are, which ones are locked, and who will notice when one opens.
With hindsight
The indictment did what indictments of this kind usually do: it named people and put a public marker down. None of the four defendants has been tried in the United States.
The broader program it belonged to changed shape. In February 2022, the Justice Department ended the China Initiative as a named program after criticism of some of its cases, while saying it would continue to pursue threats from China. Indictments naming state hackers continued under the department’s general approach to national security cases.
The case now sits alongside the Office of Personnel Management and Anthem breaches as large thefts of Americans’ personal data attributed to Chinese state actors. The Office of Personnel Management holds records on federal employees, including people with security clearances; Anthem is one of the country’s largest health insurers. Read together, these cases point to deliberate collection at scale: financial records, government personnel files and health insurance data, each valuable on its own and far more valuable combined.
The argument about identity proofing strengthened over time. Synthetic identity fraud, built partly on real Social Security numbers, grew into a major concern for lenders. In a synthetic identity, a criminal combines a real Social Security number with a made-up name and date of birth, then patiently builds a credit history for a person who does not exist. Because part of the identity is real, simple matching checks can be fooled.
Government and standards bodies moved in the direction the original article argued for. The Social Security Administration began rolling out its electronic Consent Based SSN Verification service to an initial group of users in June 2020. It lets financial institutions confirm, with the customer’s consent, that a name, number and date of birth actually match in the government’s own records, which makes stitched-together identities harder to pass off.
NIST, the federal agency that publishes widely followed technical standards, finalized revised digital identity guidelines in 2025. They bar knowledge-based verification from being used to verify identity during proofing. The familiar question about which addresses you have lived at is no longer considered acceptable proof under those guidelines.
The known-flaw argument also held up. In December 2021, a flaw in Log4j, another widely used piece of Apache open-source software, set off a scramble across every sector as organizations tried to find where it was running. The federal Cyber Safety Review Board later concluded that the flaw would remain a risk for years. In November 2021, the Cybersecurity and Infrastructure Security Agency had begun publishing a catalog of vulnerabilities known to be exploited, with deadlines for federal agencies to fix them. Many private firms adopted it as a way to rank their own patching. Both developments rest on the same insight as the Equifax case: attackers favor flaws that are public and unfixed.
Regulators tightened the accountability side. The federal banking agencies’ rule requiring banks to notify their regulator of significant computer-security incidents within 36 hours took effect in 2022. The NCUA adopted a 72-hour reporting rule for credit unions in 2023. The FTC’s amended Safeguards Rule, with more specific requirements such as multi-factor authentication and encryption, became largely enforceable in June 2023. The SEC adopted cybersecurity disclosure rules for public companies in 2023 and amended Regulation S-P in 2024 to require incident response programs and customer notification. New York amended its cybersecurity regulation in late 2023. Each of them applied regardless of who the attacker was.
The insurance question moved too. Lloyd’s of London required its market to include clear exclusions for state-backed cyberattacks in standalone cyber policies from March 2023. In the NotPetya litigation, a New Jersey appeals court held in 2023 that a traditional war exclusion did not bar Merck’s claim, and the parties later settled. Institutions that reviewed their policies after the Equifax indictment were better placed to understand the newer wording when it arrived.
The sharpest test came quickly. Within months of the indictment, pandemic relief and unemployment fraud showed at scale what stolen static identifiers could do against processes that trusted them. Programs designed to pay out quickly met criminals who already held the data needed to pass basic checks. GAO estimated in 2023 that fraud in pandemic unemployment insurance programs was likely between $100 billion and $135 billion.
The supply of stolen identifiers kept growing. In 2024, a background-check data broker, National Public Data, was reported to have exposed records containing Social Security numbers on a very large scale. Each breach of this kind adds to the stock of static data in criminal hands and weakens further any process that still treats that data as proof.
The original argument has aged well. Who stole the data turned out to matter far less than the simple fact that it was stolen, and that it will stay stolen. Every process that still treats personal facts as a password is carrying a risk that the indictment did nothing to reduce.
Spotted an error? Tell us and we will check it and correct the article where needed.