What Happened: The Equifax 2017 Data Breach Timeline
In September 2017, Equifax, one of the three major U.S. credit reporting agencies, disclosed a data breach that exposed the personal information of approximately 147 million people. The compromised data included names, Social Security numbers, dates of birth, addresses, and in some cases driver’s license numbers. A smaller subset of records also included credit card numbers.
The breach itself began months before the public disclosure. Attackers gained access to Equifax’s systems in mid-May 2017 and remained inside the network, quietly extracting data, for over two months before the intrusion was detected. Equifax publicly announced the breach on September 7, 2017.
This incident remains one of the most studied breaches in cybersecurity history because it was not the result of a novel or sophisticated attack technique. It was the result of a known vulnerability with an available patch that was not applied.
The Root Cause: An Unpatched Apache Struts Vulnerability (CVE-2017-5638)
The point of entry was a vulnerability in Apache Struts, an open-source framework used to build web applications, which Equifax used to power an online dispute portal. The specific flaw, tracked as CVE-2017-5638, allowed attackers to execute remote code on affected servers by sending a specially crafted request.
The critical detail is timing. Apache disclosed this vulnerability and released a patch in March 2017. Equifax’s own internal processes were supposed to identify and remediate vulnerabilities like this one. A scan intended to find systems affected by the flaw failed to detect the vulnerable server. As a result, the patch was never applied, and the vulnerable system remained exposed to the internet for months, until attackers found and exploited it in May.
This is the core lesson of the Equifax breach: a known vulnerability, with a known fix, went unpatched due to a breakdown in vulnerability management, not because attackers used something new or unknown.
Why the Breach Went Undetected for 76 Days
A patch failure explains how attackers got in. It does not explain why they were able to stay inside the network for roughly 76 days without being caught. Several compounding failures allowed that to happen.
An Expired SSL Certificate Blinded Traffic Inspection
Equifax used a device designed to inspect encrypted traffic for signs of malicious activity. That device relied on a digital certificate to decrypt and inspect traffic, and the certificate had expired roughly ten months before the breach was detected. With the certificate expired, encrypted traffic passing through that inspection point was not being examined, which meant the tool that should have flagged suspicious outbound data transfers was effectively blind during the entire period attackers were exfiltrating data.
Network Segmentation Was Insufficient
Once inside, attackers were able to move from the initially compromised web application to other systems and databases containing sensitive consumer data. This lateral movement suggests that the compromised system was not adequately isolated from the databases holding the most sensitive information.
Sensitive Data Was Not Adequately Protected at Rest
Investigators found that some databases containing sensitive personal information were not encrypted, and access controls did not sufficiently limit which systems or accounts could reach the most sensitive tables.
Each of these gaps compounded the initial patching failure. Even after the intrusion began, there were multiple points where better controls could have detected or limited the damage.
The Human and Organizational Factors Behind the Breach
Public congressional testimony following the breach highlighted organizational issues beyond any single technical control:
- The vulnerability scan that should have identified the unpatched Struts instance did not do so, and there was no effective process to independently verify that critical patches were actually applied after being assigned.
- Responsibility for patching was distributed across teams without a clear, enforced deadline-and-verification process for critical vulnerabilities.
- Security monitoring tools existed but were not maintained (as shown by the expired certificate), reducing their effectiveness to zero for an extended period without anyone noticing.
This is a common pattern in major breaches: the failure is rarely a single missing tool. It is usually a combination of a known gap, a broken verification process, and a monitoring capability that quietly stopped working without triggering an alert of its own.
The Aftermath of the Equifax Breach
The breach resulted in significant consequences for Equifax, including leadership departures — the CEO, Chief Information Officer, and Chief Security Officer all left the company in the aftermath — congressional hearings, regulatory scrutiny, and a large settlement with U.S. regulators and affected consumers. It remains a frequently cited case study in cybersecurity training precisely because the failure points are well documented and instructive.
Lessons Learned: Controls That Would Have Prevented or Limited This Breach
1. A Verified Patch Management Process for Critical Vulnerabilities
Having a patching policy is not enough. Equifax needed a process that confirmed, independently of the team responsible for applying the patch, that critical vulnerabilities were actually remediated within a defined window. A patch that is assigned but not verified is not a control — it’s a plan that may or may not have happened.
2. Accurate and Complete Asset Inventory for Vulnerability Scanning
The scan that should have caught the vulnerable Struts instance did not detect it. Vulnerability management is only as good as the inventory it scans against. Organizations need a reliable, up-to-date map of internet-facing applications and the components (including open-source frameworks) they depend on.
3. Maintenance of Security Monitoring Infrastructure
An expired certificate rendering an inspection tool blind for ten months is a monitoring failure, not just a certificate failure. Security tools need their own health checks: automated alerts when certificates are approaching expiration, and periodic validation that monitoring tools are actually inspecting the traffic or logs they’re supposed to.
4. Network Segmentation Between Public-Facing Applications and Sensitive Data Stores
A public-facing web application should not have a direct, unrestricted path to databases containing sensitive consumer records. Proper segmentation limits how far an attacker can move after an initial compromise, turning a single exploited server into a contained incident rather than a company-wide breach.
5. Encryption of Sensitive Data at Rest, Paired With Strict Access Controls
Even if attackers reach a database, encrypted data with tightly controlled access is far harder to extract usefully. Least-privilege access limits which systems and accounts can even reach the most sensitive tables in the first place, and strict access controls remain one of the most underused lines of defense after a perimeter is breached.
6. Outbound Traffic Monitoring and Anomaly Detection
Data was exfiltrated over more than two months. Monitoring for unusual volumes of outbound traffic, especially from a system that does not typically transfer large amounts of data externally, could have surfaced the intrusion far sooner than it was actually detected.
Key Takeaway: Lessons Learned from the Equifax Breach
The Equifax breach is not a story about a sophisticated attacker outsmarting cutting-edge defenses. It is a story about a known vulnerability, a patch that existed but wasn’t verified as applied, and a monitoring tool that had quietly stopped working. Each of these, on its own, is a common and fixable gap. Together, they turned a single unpatched web application into the exposure of 147 million people’s personal data.
For any organization, the practical lesson is the same: treat patch verification, monitoring tool health, and network segmentation as measurable, audited controls — not assumptions. A control that isn’t checked is not a control you can rely on.