TL;DR
In November 2013, attackers phished login credentials from Fazio Mechanical Services, a company that serviced refrigeration and air conditioning equipment for Target stores. They used that supplier's access as the entry point to Target's network, ultimately exposing about 40 million payment cards and 70 million customer records.
It was not a thermostat hack. Fazio's connection to Target was used for electronic billing, contract submission, and project management, according to a statement from company owner Ross Fazio. The real failure was that a low-value supplier account could reach a high-value environment.
The same root cause dominates breaches today. Verizon's 2025 Data Breach Investigations Report found third-party involvement in breaches doubled year over year to 30%, and IBM's 2025 Cost of a Data Breach report puts supply-chain compromises at $4.91 million and 267 days to contain, the slowest vector it tracks.
What actually happened in the 2013 Target data breach?
Attackers stole network credentials belonging to a third-party contractor, used them to reach Target's internal systems, and installed memory-scraping malware on point-of-sale (POS) terminals across the retailer's U.S. stores. The intrusion began around November 15, 2013 and was publicly confirmed on December 19, 2013.
The initial credential theft came from a phishing email sent to Fazio Mechanical Services, a refrigeration and air conditioning contractor based in Sharpsburg, Pennsylvania. The email delivered Citadel, a password-stealing tool in the Zeus malware family, according to reporting by Brian Krebs, who first identified the vendor in February 2014.
With valid supplier credentials in hand, the attackers accessed Target's external vendor environment and then moved laterally into the internal network. By around November 27, the start of Black Friday weekend, they had begun deploying POS malware known as BlackPOS, or Kaptoxa, which reads unencrypted card data out of terminal memory during the authorization process.
Malware reached POS systems in 1,797 stores. Approximately 40 million payment card accounts and 70 million customer records containing names, addresses, phone numbers, and email addresses were exposed. Accounting for overlap, as many as 110 million individuals were affected.
Did hackers really break into Target through the air conditioning system?
No. This is the most durable myth about the breach, and it is worth correcting precisely, because it points the lesson in the wrong direction.
Fazio Mechanical Services stated publicly that it "does not perform remote monitoring of or control of heating, cooling and refrigeration systems for Target," and that its "data connection with Target was exclusively for electronic billing, contract submission and project management." Suppliers in that program logged into external web applications. Reporting at the time identified Ariba for invoicing, along with Target's Partners Online and Property Development Zone portals.
So the entry point was not a building-automation system. It was an ordinary business application account belonging to an ordinary supplier.
That distinction matters. "Segment your air conditioning network" is a narrow, almost reassuring takeaway. "Any supplier account in any business application may be a path to your most sensitive environment" is the actual lesson, and it applies to every organization that works with outside vendors, which is all of them.
It is also worth noting that Fazio was itself a victim of a criminal phishing campaign and said it was in full compliance with industry practices at the time. The instructive failure here is architectural, not a matter of assigning blame to a small contractor.
What was the real root cause?
The root cause was identity and access governance. A third-party account held more reach than its business purpose required, and no control stood between that account and the cardholder data environment.
Three governance gaps compounded each other, and each is visible in the U.S. Senate Commerce Committee's March 2014 "Kill Chain" analysis:
No least privilege for third-party access. A billing-and-contracts supplier account should have been able to touch billing and contracts, and nothing else. Instead, that access became a foothold from which attackers could pivot.
Insufficient network segmentation. The vendor-facing environment was not adequately isolated from internal systems or from the POS environment, a requirement that PCI DSS treats as foundational.
No visibility into effective access. Nobody appears to have been able to answer, in advance, the question "what can this supplier account actually reach?" That question is an entitlement-mapping problem, and it is the one most organizations still cannot answer quickly.
Authentication was the door. Authorization, meaning what the account was permitted to do once inside, was the breach.
Why didn't Target's security tools stop it?
They fired. The alerts were not acted on.
Target had deployed a FireEye malware-detection system reportedly costing about $1.6 million roughly six months earlier, ran Symantec Endpoint Protection, employed more than 300 information-security staff, and had been certified PCI DSS compliant about two months before the attack. Bloomberg Businessweek's March 2014 investigation reported that FireEye generated alerts as the malware was staged, that the system's automatic-deletion capability had been switched off, and that escalations from Target's Bangalore security operations team to Minneapolis did not produce a response.
The uncomfortable implication for security leaders is that this was not a tooling-budget failure. Target had the products, the headcount, and the certification. What it lacked was the context to recognize that an alert on a vendor-adjacent system was an alert on the payment environment.
What did the Target breach cost?
Target's cumulative breach-related expenses reached roughly $292 million through the end of 2016, or approximately $202 million net of insurance recoveries, based on the company's own disclosures.
The settlement terms are as telling as the dollar figures. The 2017 multistate agreement required Target to appoint a chief information security officer, maintain a comprehensive information-security program, and implement encryption, access controls, and two-factor authentication for certain accounts. Regulators, in other words, diagnosed the same problem: identity and access governance.
Is this still happening in 2026?
Yes, and by the numbers, more than before. The stolen-supplier-credential pattern that broke Target in 2013 is now among the most common ways large organizations are compromised.
Third-party involvement in breaches doubled from 15% to 30% year over year, the largest single-year shift Verizon has recorded in its Data Breach Investigations Report (2025 edition, drawn from 12,195 confirmed breaches). Credential abuse was the leading initial access vector at 22%.
Supply-chain compromise costs an average of $4.91 million and takes 267 days to identify and contain, the longest dwell time of any vector in IBM's 2025 Cost of a Data Breach report, against a global average breach cost of $4.44 million.
Regulators have moved accordingly. The EU's Digital Operational Resilience Act (DORA) became applicable on January 17, 2025 with explicit third-party technology risk requirements. NIS2 supply-chain obligations applied from October 2024. PCI DSS 4.0's future-dated requirements, including phishing-resistant MFA for personnel with access to the cardholder data environment, came into force on March 31, 2025.
What would have made the difference?
No single control stops a determined attacker, and no vendor can honestly claim it would have prevented a specific historical breach. What can be said is which class of controls addresses this class of root cause:
Least privilege for every third-party account, scoped to the business function the supplier was engaged for.
Complete entitlement visibility, meaning the ability to answer "what can this account reach?" for any identity, in any application, in minutes rather than weeks.
Segmentation between vendor-facing systems and sensitive environments, verified rather than assumed.
Phishing-resistant MFA on all external and supplier access paths.
Lifecycle governance, so access granted at onboarding is reviewed, recertified, and revoked on schedule rather than left to accumulate.
Alert context that ties detections to the identities and data they touch, so a signal on a peripheral system isn't triaged as peripheral.
Most enterprises already own tools that are supposed to do this. Which raises the harder question.
Where the gap usually is: platform coverage, not platform absence
Having an identity governance and administration (IGA) platform is not the same as having IGA coverage.
In practice, IGA programs cover the applications that were straightforward to connect, such as the major directories and SaaS suites with mature connectors. The long tail goes ungoverned: legacy systems, industry-specific applications, custom internal tools, supplier and contractor portals, and applications with no usable API. Those are precisely the systems where third-party accounts live, and where entitlements go unmapped and unreviewed.
The reason is rarely strategic. Building and maintaining a production-grade connector is slow, specialized work, covering role modeling, entitlement mapping, API contract shaping, validation, documentation, and then ongoing maintenance every time the vendor ships a breaking change. Backlogs form, and the ungoverned tail persists for years.
This is the problem Klyro was built to close. Klyro applies AI operators to design, configure, and maintain IGA integrations end to end, including role modeling, entitlement mapping, governance policy, and disconnected applications that conventional connectors can't reach. Each integration ships with validation suites, documentation and runbooks, detailed entitlement and permission maps, and ongoing updates as target systems change. Connectors run in sandboxed, isolated environments under least-privilege principles with full audit logging.
Klyro does not replace an existing IGA platform. It extends its reach. The objective is straightforward: no application, and no third-party or non-human identity, should sit outside governance because integrating it was too expensive.
That last category is growing quickly. Every AI agent and service account deployed into a business process is an identity with entitlements, and the 2013 lesson applies unchanged. An identity you have not governed is an identity you cannot scope.
Frequently asked questions
How did hackers get into Target in 2013?
They phished network credentials from Fazio Mechanical Services, a refrigeration and air conditioning contractor, using Citadel malware. They then used that supplier access to reach Target's internal network and deploy BlackPOS malware on point-of-sale terminals.
Was the Target breach caused by the HVAC or air conditioning system?
No. Fazio Mechanical stated it did not remotely monitor or control Target's heating, cooling, or refrigeration systems, and that its data connection was used only for electronic billing, contract submission, and project management.
How many people were affected by the Target data breach?
About 40 million payment card accounts and 70 million records containing personal information were exposed, which is as many as 110 million individuals once overlap is accounted for.
How much did the Target data breach cost?
Roughly $292 million in cumulative expenses through 2016, or about $202 million net of insurance. That includes an $18.5 million multistate settlement in 2017, a $39.4 million settlement with financial institutions, and a $10 million consumer class-action settlement.
What percentage of breaches involve a third party?
Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30% of breaches, double the 15% reported the prior year.
What is IGA coverage, and why does it differ from having an IGA platform?
IGA coverage is the share of applications and identities actually governed by your identity platform. Many organizations own an IGA platform but govern only the applications that were easy to integrate, leaving legacy, custom, and supplier-facing systems outside access reviews and least-privilege enforcement.