TL;DR: Target's 2013 breach began with phished contractor credentials and ended with malware on point-of-sale systems, exposing about 40 million payment cards and 70 million customer records, according to Klyro. The lesson is that supplier access becomes breach fuel when entitlement scope, segmentation, and review discipline do not match business purpose.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Klyro's blog post: Target's breach shows how third-party access, not infrastructure glamour, can become the entry path to a payment environment.
Why it matters: IAM, PAM, and third-party governance teams need to treat supplier accounts as governed identities with scoped reach, not as low-risk exceptions outside normal entitlement review.
By the numbers:
- Target's breach exposed about 40 million payment cards and 70 million customer records.
- Third-party involvement in breaches doubled from 15% to 30% year over year.
- Supply-chain compromise costs an average of $4.91 million and takes 267 days to identify and contain.
- Credential abuse was the leading initial access vector at 22%.
Context
The core issue is not whether a supplier is trusted in the business sense. It is whether the supplier's identity can reach sensitive systems beyond the work it was hired to do, and whether anyone can explain that reach before an incident proves it.
Third-party access often expands quietly through billing portals, procurement tools, support consoles, and project systems. When those identities are not inventoried and recertified like any other privileged account, the path from ordinary business use to crown-jewel access stays invisible.
Key questions
Q: How do supplier credentials lead to lateral movement in enterprise networks?
A: Supplier credentials lead to lateral movement when a third party’s service account, API key, or VPN credential is reused, overprivileged, or poorly segmented, letting an attacker move from one system to another. Weak network segmentation, shared accounts, and long-lived secrets make the jump easier. Restrict each credential to a narrow system scope, rotate secrets, and remove access when the supplier’s work ends.
Q: What is the best way to scope third-party account access?
A: The best way is to assign each third-party account the minimum systems, data sets, and actions needed for one defined business purpose, then enforce time-bound access, separate credentials, and approval-based provisioning. If a supplier identity can reach systems, that reach should be mapped to a named owner, reviewed regularly, and revoked when the contract, role, or task changes.
Q: How do microsegmentation tools reduce breach blast radius across network segments?
A: Microsegmentation tools reduce breach blast radius by enforcing fine-grained communication rules between workloads, users, and services. If one segment is compromised, the attacker cannot move freely to adjacent systems. Practitioners should group assets by function and sensitivity, apply default-deny policies, and monitor policy drift, exception sprawl, and failed connection attempts.
Q: What should teams do when they discover that an employee account may have been exposed in a breach?
A: They should move quickly to confirm the affected account, reset credentials, and review whether the exposure touched other company services. If the account is tied to a shared workflow, access should be revoked or narrowed until the risk is contained. The response should be coordinated so employees know what changed and why.
Technical breakdown
How supplier credentials become a lateral-movement path
A third-party identity usually starts with legitimate business access, but the technical question is where that access terminates. If the supplier can authenticate to an external portal that is bridged into internal systems, attackers only need valid credentials and a usable session to move from the vendor edge into a more sensitive environment. The failure is not the password alone. It is the combination of reachable applications, weak segmentation, and trust in the source account's business purpose rather than its effective permissions. See the Third-Party, B2B and Contractor Access Guide.
Practical implication: Map every supplier login path to the internal systems it can actually reach and remove any unexplained route into sensitive environments.
Why entitlement visibility matters more than account counts
Identity governance breaks when teams know an account exists but cannot answer what it can do. Effective entitlement visibility means being able to list permissions, connected applications, and inherited reach for a supplier account quickly enough to support review and containment. Without that view, least privilege is only a provisioning intention, not an enforceable control. The same problem appears in legacy apps, contractor portals, and custom business systems where connectors are incomplete or absent.
Practical implication: Treat entitlement mapping as a control objective, not a reporting exercise, and close any application that cannot expose usable access data.
How malware turns payment terminals into data theft points
Memory-scraping point-of-sale malware works by reading card data while it is briefly resident in terminal memory during processing. That makes the terminal itself a collection point, even when the surrounding environment appears ordinary. Once attackers have a foothold in the network, the value of the breach comes from reaching those terminals and sustaining access long enough to stage the malware. This is why segmentation and monitoring must cover the systems that process payment data, not only the systems that store it. See the Data Breach Notification Checklist.
Practical implication: Segment cardholder environments from vendor-facing systems and monitor for staging activity on terminals and adjacent hosts.
Threat narrative
Attacker objective: The attackers sought to steal payment card data and customer records by turning a supplier foothold into broad access to the retailer's point-of-sale environment.
- Entry came through phished contractor credentials taken from a third-party supplier account, giving attackers a valid foothold instead of forcing them to exploit a public-facing vulnerability.
- Escalation followed when those credentials were used to move from vendor-facing applications into Target's internal environment and then toward point-of-sale systems.
- Impact came when BlackPOS malware was deployed across stores, allowing card data to be read from terminal memory at scale.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Supplier access is not low-value access: The breach worked because a business-purpose contractor account reached far beyond the work it was intended to support. That is a governance failure, not a technical curiosity, because the same pattern appears whenever external identities are granted ambient trust. The practitioner conclusion is simple: supplier identities must be treated as governed access paths, not as convenience accounts.
Entitlement visibility was the missing control plane: The organisation could not answer in time what the supplier account could actually reach, which meant least privilege could not be enforced in practice. That failure is still common in environments where legacy applications, custom tools, and vendor portals sit outside identity governance coverage. The practitioner conclusion is to treat reachability as a first-class control objective.
Segmented trust would have limited the blast radius: The breach demonstrates that business separation on paper is not the same as network separation in practice. Once a third-party account can bridge into sensitive environments, the attacker inherits whatever overreach the architecture allows. The practitioner conclusion is to verify that vendor-facing systems cannot traverse into payment, production, or other crown-jewel domains without explicit control.
Access review cadences do not help if the access model is already wrong: Reviews can only certify what has been modelled and inventoried. If a supplier identity is omitted from governance coverage, the review process becomes a formality around an unknown reach set. The practitioner conclusion is to fix coverage first, then rely on recertification to keep the estate bounded.
Identity blast radius is the right named concept here: A third-party account with a small business role can still have a large operational blast radius when its effective permissions cross into sensitive systems. That blast radius is the real risk variable, not the nominal job description. The practitioner conclusion is to govern identities by reach, not by label.
What this signals
Third-party identity coverage is now a board-level governance issue: When external accounts can reach production or payment systems, the question is no longer whether the organisation has an access review process. The real question is whether that process actually covers supplier portals, legacy apps, and business-to-business systems that sit outside the easy connector set.
Identity blast radius should become a measurable design variable: The relevant metric is not how many external accounts exist, but how far one compromised account can move before controls stop it. That shifts programme attention from inventory alone to reachability, segmentation, and recertification coverage across the long tail of applications.
For practitioners
- Inventory every third-party login path List supplier, contractor, and partner accounts separately from employee access and record which applications each identity can reach.
- Re-certify supplier entitlements on a fixed cadence Review the effective permissions of every external identity against its current business purpose, then remove any inherited or stale reach.
- Segment vendor portals from sensitive environments Ensure external business applications cannot traverse directly into payment, production, or other crown-jewel systems without explicit control.
- Tie alerts to identity and data context Route detections so analysts can see which account, application, and data set an alert touches before deciding whether it is peripheral.
- Require phishing-resistant MFA for external access Apply stronger authentication to all supplier and contractor paths, especially where the account can reach operational or financial systems.
Key takeaways
- The breach shows how third-party access can become a high-impact entry path when business scope and effective permissions diverge.
- Scale matters because the incident exposed tens of millions of payment cards and customer records, and the same access pattern remains common in modern breaches.
- The control lesson is to govern supplier identities by reach, not by trust labels, with segmentation and entitlement visibility doing the heavy lifting.
Related NHI Mgmt Group resources: Third-Party, B2B and Contractor Access Guide · Breach Notification Laws by Country Guide · What to Do After a Data Breach Guide · Data Breach Register Template
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The breach began with a supplier account whose access became the entry path into Target. |
| NHI-05 — Overprivileged NHI | The contractor account had more effective reach than its billing and project role required. | |
| NHI-08 — Environment Isolation | Vendor-facing systems were not isolated enough from payment and internal environments. | |
| Recommendation — Inventory and constrain third-party identities before they can bridge into sensitive systems. Reduce external account privilege to the narrowest business function and remove inherited reach. Separate supplier-facing applications from crown-jewel environments and verify the boundaries. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | Stolen contractor credentials enabled movement from an initial foothold into internal systems. |
| Recommendation — Track supplier credential theft as an initial-access-to-lateral-movement path in detection and response. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on unmanaged entitlements for a third-party identity. |
| Recommendation — Review and enforce account entitlements so external identities cannot exceed approved reach. | ||
| CIS Controls v8 | CIS-5 — Account Management | External account lifecycle and revocation failures are central to the breach pattern. |
| Recommendation — Manage supplier accounts through joiner-mover-leaver processes and remove stale access promptly. | ||
Key terms
- Target data breach 2013: A major retail breach in which attackers used phished third-party credentials to move into a retailer's internal environment and deploy point-of-sale malware. The incident is widely used to illustrate how supplier access, not just perimeter weakness, can produce large-scale card and customer data loss.
- Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
- Network Segmentation: Network segmentation divides traffic and resources into controlled zones so access can be restricted between groups, systems, or applications. In remote access design, segmentation limits what a connected user or workload can reach after authentication, which reduces lateral movement and shrinks blast radius.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org