TL;DR: Third-party breaches are increasingly exposing identity data and connected access paths, with incidents such as Sisense showing how vendor relationships can become an entry point for broader compromise, according to Saviynt. Identity governance has to extend beyond employees to service, vendor, and machine identities before trust becomes an attack surface.
At a glance
What this is: This is a Saviynt analysis of how third-party supply chain breaches expose identity data and connected access paths, using Sisense as the clearest example.
Why it matters: It matters because IAM teams can no longer treat vendor access, service accounts, and connected identities as downstream concerns once a supplier becomes part of the trust boundary.
Context
Third-party supply chain breaches are identity problems as much as they are vendor risk problems. When a supplier, service provider, or connected platform is compromised, the access paths that were supposed to be bounded by governance often become the shortest route into customer data and administrative systems.
For IAM and NHI programmes, the issue is not only who is inside the enterprise but which external identities can still act with meaningful privilege after a trust relationship is established. Sisense is a useful reminder that downstream access, tokens, and integrated services can turn a supplier incident into a broader identity exposure.
The governance gap is cumulative: most organisations manage direct employee access more tightly than third-party access, yet third-party identities can touch the same systems, data, and operational workflows. That makes supplier lifecycle control, offboarding, and privilege review part of the core identity security model, not an adjacent procurement task.
Key questions
Q: What breaks when third-party access is not lifecycle managed?
A: Access outlives accountability. When vendor credentials are not tied to a clear offboarding process, old support paths, dormant accounts, and overbroad entitlements remain available after the business need has ended. That creates a standing exposure window that attackers can exploit and auditors will struggle to explain.
Q: Why do third-party identities increase supply chain risk?
A: Third-party identities increase risk because they depend on another organisation’s hygiene while still operating inside your trust boundary. If those credentials are long-lived, over-scoped, or difficult to revoke, they can outlast the business relationship and provide a path for lateral movement after the supplier is breached.
Q: How can IAM teams tell whether third-party access is overexposed?
A: Look for external accounts that can reach production data, administrative workflows, or automation layers without a narrow business purpose and expiry condition. If the same external identity can support multiple systems or multiple customers, the trust boundary is probably too wide. The best signal is any access path that is hard to explain in one sentence.
Q: How should organisations govern supplier-linked service accounts?
A: Treat supplier-linked service accounts as governed identities with named owners, least-privilege scopes, and explicit offboarding triggers. Review them whenever a vendor relationship changes, not only on a calendar cycle. If the business cannot justify the credential’s current use, the account should be removed or reduced before it becomes an active breach path.
Technical breakdown
How supply chain breaches turn third-party access into identity exposure
A supply chain breach becomes an identity issue when the compromised supplier already holds credentials, tokens, API access, or delegated permissions that reach customer environments. The attacker does not need to invent a new path if the trust relationship already exists. In practice, the breach surface includes service integrations, support tooling, and machine identities that were granted access to make operations easier. Once those identities are present, compromise of the upstream party can expose downstream data, administrative functions, or customer systems without any direct intrusion into the target organisation.
Practical implication: Treat every third-party integration as a governed identity with explicit scope, expiry, and offboarding.
Why third-party machine identities are harder to govern than employee accounts
Machine identities do not behave like human users, but many organisations still govern them with human-style review cycles. Service accounts and tokens are often issued once, embedded in workflows, and left untouched across supplier changes, platform upgrades, or ownership transitions. That creates a mismatch between the speed of vendor change and the slower pace of access reviews. When a third party is breached, the lack of lifecycle discipline around these identities can leave valid access in place long after the business relationship or operational need has shifted.
Practical implication: Inventory supplier-linked service accounts and remove any credential that lacks a clear business owner or expiry path.
What connected services reveal about blast radius in identity governance
Connected services expand blast radius because a breach in one domain can inherit trust into another through tokens, federated access, or delegated support rights. The technical problem is not only authentication, but authorisation scope and the persistence of that scope across environments. If a third party can read logs, access storage, or retrieve support data, the compromise of that third party effectively widens the number of systems exposed. Identity governance has to account for that cross-boundary propagation, not just the initial login event.
Practical implication: Map third-party trust chains end to end so you can see where one supplier compromise reaches beyond its intended boundary.
Threat narrative
Attacker objective: The attacker aims to convert trusted third-party access into broader downstream exposure of sensitive identity and operational data.
- Entry occurs through a compromised third party that already has access into customer-facing systems, support tooling, or shared services.
- Credential access follows when tokens, API keys, or delegated credentials are abused to reach connected data and identity assets.
- Lateral movement expands the incident when the trusted connection lets the attacker move from the supplier edge into downstream environments.
- Impact is realised as customer identity data, support material, or other sensitive information becomes exposed across the supply chain.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
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
Third-party supply chain breaches expose a governance boundary problem, not just a vendor risk problem. Once external identities can reach production systems, the enterprise has already extended its trust boundary beyond direct employment relationships. That means identity governance has to cover suppliers, service providers, and machine identities with the same seriousness as internal users. The practitioner takeaway is that external access is part of the identity programme, not an exception to it.
Vendor access without lifecycle offboarding is the failure mode these incidents keep revealing. The problem is not simply that third parties exist, but that their access often outlives the business need that justified it. When offboarding, scope reduction, and review are weak, a supplier compromise can become a customer compromise. Practitioners should treat supplier access persistence as a core governance defect.
Trust chains now create identity blast radius across organisational boundaries. A supplier credential rarely stays confined to the supplier’s environment once support, integration, or delegated administration is involved. That changes the security question from 'who can log in' to 'where can this trust relationship reach'. The implication is that IAM teams need a mapped view of external privilege propagation, not just a list of external accounts.
Third-party exposure forces NHI governance into the centre of supply chain risk management. Many of the identities involved in these incidents are not human accounts at all, but tokens, service principals, support credentials, and other machine identities. Those identities are often easier to overlook than employee access but just as capable of widening blast radius. The practical conclusion is that NHI governance is now a supply chain control, not a niche technical discipline.
Identity security in the supply chain will keep shifting from authentication to entitlement governance. The article’s core lesson is that authentication alone does not contain supplier risk when delegated access, broad entitlements, and incomplete offboarding remain in place. Identity teams will be judged on whether they can continuously limit what a third party can reach after trust is established.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Vendor access without lifecycle offboarding: Third-party risk becomes an identity failure when external access remains active after the business relationship has changed. That is the point where procurement assumptions stop matching operational reality, and the identity programme has to enforce the end of trust instead of merely recording it.
Identity blast radius now spans supplier boundaries: The practical challenge is not simply exposure of a single account, but propagation of privilege through support tools, tokens, and delegated access. Once that propagation is visible, IAM teams can prioritise which external trust chains deserve tighter scope, shorter lifetime, and faster revocation.
For practitioners
- Map third-party trust chains Document every supplier, support provider, and integration that can reach production systems, then trace what each one can touch across data, admin, and automation layers.
- Review supplier-linked machine identities Inventory service accounts, tokens, and delegated credentials tied to external parties, then assign an owner and expiry condition for each one.
- Tighten offboarding for external access Remove third-party access as part of contract change, platform migration, or relationship end, rather than waiting for periodic access certification.
- Limit the reach of connected services Reduce the permissions held by support and integration accounts so a supplier compromise cannot easily cross into broader customer data or administrative functions.
Key takeaways
- Third-party breaches become identity incidents when external access and delegated trust can be reused against customer systems.
- The Sisense example shows how supplier compromise can expose tokens, passwords, certificates, and other connected identity assets.
- Supplier offboarding, entitlement scope, and machine identity governance are the controls most likely to reduce blast radius.
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 sets 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 article centres on supplier identities and external access paths that become breach entry points. |
| NHI-01 — Improper Offboarding | Supplier access persisting after relationship changes is the core governance failure described here. | |
| NHI-05 — Overprivileged NHI | The article shows how broad external entitlements widen blast radius after compromise. | |
| Recommendation — Map every third-party identity to an owner, scope, and revocation path. Revoke third-party credentials when the relationship, platform, or support need ends. Reduce external privilege scopes so supplier compromise cannot cross major trust boundaries. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This topic is about governing who can reach what across third-party trust chains. |
| Recommendation — Review third-party entitlements against business need and remove access that exceeds scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The breach pattern is credential abuse followed by spread through trusted connections. |
| Recommendation — Hunt for supplier credential misuse and downstream movement across trusted integrations. | ||
Key terms
- Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.
- Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management 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 June 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org