Identity breaches follow a repeatable seven-step attack chain

At a glance

What this is: This is an independent analysis of the seven-step identity breach chain and the controls that can interrupt it.

Why it matters: It matters because the same attack pattern spans human, NHI, and platform identities, so IAM teams need layered controls that limit escalation and speed containment.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Linx Security's analysis of the seven-step identity breach chain

Context

Identity breach chains succeed because authentication, authorisation, and persistence are often treated as separate problems when attackers use them as one continuous path. The article’s central message is that once a credential, token, or session is accepted, the attacker can often move faster than the programme’s ability to review, detect, and revoke access.

For IAM and security teams, the practical issue is not just stopping the first compromise. It is reducing the blast radius when identities are abused, especially across human users, service accounts, SaaS permissions, and cloud control planes where one foothold can become many.

Key questions

Q: What breaks when attackers steal a valid identity credential?

A: A valid credential collapses the difference between an external attacker and a trusted user or workload. Once the credential is accepted, the attacker can blend into normal authentication flows, move into connected systems, and often bypass controls that only protect the front door. The real failure is not just compromise, but the ability to reuse trust across multiple services.

Q: Why do service accounts and tokens make identity attacks harder to contain?

A: Service accounts and tokens often outlive a single session, so compromise can persist after a password reset or user lockout. If those identities have broad permissions, an attacker can move laterally, create new trusted objects, or return later through the same trust path. That is why lifecycle governance matters as much as detection.

Q: How do security teams reduce the blast radius of an identity breach?

A: Limit standing privilege, narrow cross-service access, and separate high-risk actions from ordinary logins. Add monitoring for role changes, new application consents, and unusual access across SaaS and cloud platforms. When possible, make elevation temporary and revocation automatic so a compromised identity cannot keep moving after initial containment.

Q: Who is accountable when identity compromise spreads across SaaS and cloud?

A: Accountability usually spans IAM, platform, application, and operations teams because the breach travels through shared trust relationships. The right governance model assigns ownership to each identity object, each privileged pathway, and each revocation process. If no one owns the lifecycle of a trusted object, attackers will.

Technical breakdown

Initial access through credentials, secrets, and exposed accounts

Identity attacks usually begin when an attacker acquires something the environment already trusts: a password, token, API key, session cookie, or inactive account. Phishing, credential stuffing, reused passwords, and leaked secrets in source control or CI/CD systems all create a valid starting point. Once that first credential works, the attacker no longer needs to break the perimeter in the traditional sense. They are operating as an authenticated identity, which is why these incidents are so hard to distinguish from normal traffic.

Practical implication: eliminate exposed credentials and disable dormant accounts before they become an authenticated entry point.

MFA bypass, privilege gain, and JIT elevation

Multi-factor authentication reduces risk, but it does not end the attack chain. Fatigue attacks, social engineering, help desk abuse, SIM swaps, and stolen session artefacts can all bypass the friction MFA creates. From there, attackers look for standing admin rights, cross-service permissions, or tokens that can be reused for higher privilege. Just-in-time access reduces this exposure by making administrative capability temporary rather than persistent, but only if privilege grants and revocations are tightly governed.

Practical implication: combine phishing-resistant MFA with JIT admin access and strong controls around privileged resets.

Lateral movement, persistence, and identity-based impact

Once elevated, attackers use identity relationships to move through connected systems. SSO, SaaS admin roles, cloud control planes, OAuth apps, service principals, and API tokens can all become pivot points. Persistence often comes from creating new trusted objects that survive password resets or from modifying logs and re-entry paths so the attacker can return later. The final objective is usually not identity access itself, but data theft, fraud, ransomware enablement, or operational disruption.

Practical implication: monitor for new trusted identity objects, unusual cross-system access, and privilege changes that outlive the original incident.

Threat narrative

Attacker objective: The attacker’s objective is to turn one trusted identity into broad, durable access that can be used for exfiltration, fraud, or service disruption.

1. Entry occurs when attackers obtain valid credentials, session material, or exposed secrets through phishing, reuse, dark web purchase, or leaked code.
2. Escalation happens when MFA is bypassed, an admin account is abused, or standing privilege lets the attacker expand access beyond the original foothold.
3. Impact follows when the attacker moves laterally, creates persistent identity objects, and uses the trusted access path for data theft, ransomware, or operational disruption.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity breaches succeed because trust is evaluated once and then reused too broadly. The seven-step chain shows that credentials, tokens, and session artefacts become reusable proof of identity long after the original trust decision. That is why attackers can turn one successful login into a multi-stage compromise across SaaS, cloud, and internal applications. Practitioners should treat every authenticated identity as a potential propagation path, not a one-time event.

Standing privilege is the control gap that repeatedly turns compromise into escalation. This article’s examples show that attackers do not need to invent new access models when admin rights already exist and are broadly scoped. JIT access, service-scoped permissions, and frequent entitlement review matter because persistent privilege creates the conditions for identity-driven lateral movement. The practitioner conclusion is simple: the wider the standing access, the faster a single foothold becomes an enterprise problem.

Blast-radius control is the named concept this chain makes unavoidable. The article shows that prevention fails gracefully only when detection and revocation can contain the attacker before persistence or re-entry is established. That means the critical governance question is not whether an identity can be compromised, but how far it can move before controls intervene. Practitioners should design for containment first, because identity compromise is now a traversal problem as much as an authentication problem.

Identity persistence is the point where temporary compromise becomes durable exposure. OAuth apps, service principals, and token-based trust objects can survive password resets and incident response if lifecycle controls are weak. That is why account-level remediation without object-level governance leaves the attacker a second path back in. The field implication is that identity programmes must govern not just users and accounts, but the trusted objects those identities can create.

Automated response is no longer optional when identities are the attack path. The article makes clear that manual containment lags behind attacker speed once valid access exists. Security teams need rapid revocation, role-change alerting, and immutable logging to reduce the dwell time of identity abuse. The practitioner lesson is to make containment machine-speed, because identity attackers already operate at machine speed.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• For a broader view of recurring breach patterns, see 52 NHI Breaches Analysis and use it to test whether your revocation process actually closes the loop.

What this signals

Blast-radius control: Identity programmes increasingly need to be measured by how quickly they can revoke trust, not only by how well they can prevent compromise. In environments where identity is the control plane, a single valid token can outpace manual response and turn local failure into systemic exposure.

The practical signal to watch is the gap between detection and containment across SaaS, cloud, and directory services. If revocation is still stitched together by hand, then the attacker’s dwell time is being financed by your operating model rather than by their sophistication.

Teams should also prepare for more persistent identity objects that survive the first incident response pass. OAuth apps, service principals, and other trusted non-human identities will keep becoming the attacker’s favourite re-entry path until lifecycle governance and immutable audit trails are treated as core control functions.

For practitioners

• Inventory and disable dormant identities Find inactive users, stale service accounts, and orphaned access paths, then remove them before they can be reused as a valid entry point. Prioritise accounts that still have external exposure or broad application reach.
• Require phishing-resistant MFA for privileged access Use hardware keys or passkeys for high-risk identities, and apply stronger proof-of-identity checks for help desk resets and recovery flows. Treat MFA fatigue and reset abuse as control failures, not user mistakes.
• Move administrative access to just-in-time grants Replace persistent admin rights with time-bound elevation tied to a named task and a named owner. Make revocation automatic when the task ends or when anomalous role changes are detected.
• Monitor identity objects that survive sessions Alert on new OAuth apps, service principals, token creation, role changes, and other trusted objects that can persist after the original compromise is contained. These are the most common re-entry paths in identity-led breaches.
• Test containment speed across connected systems Measure how quickly a compromised identity can be disabled everywhere it is trusted, including SaaS apps, cloud control planes, and federated services. Use the result to identify where revocation is still manual or incomplete.

Key takeaways

• Identity breaches are usually chain attacks, not single events, which is why one compromised credential can become broad enterprise access.
• The scale of the problem is already measurable in service-account exposure, persistent privilege, and slow revocation after compromise.
• The most effective response is to combine prevention, blast-radius reduction, and machine-speed containment across human and non-human identities.

Key terms

• Identity breach chain: A sequence of attacker actions that starts with a trusted identity and ends in broader access, persistence, or impact. The key point is that each step builds on the trust created by the previous one, which is why identity incidents often look like normal administration until they are well advanced.
• Standing privilege: Persistent elevated access that remains available until someone manually removes it. In identity security, standing privilege is dangerous because it gives attackers immediate room to escalate and move laterally once a credential or token is compromised, especially when the entitlement spans multiple systems.
• Blast radius: The amount of access, systems, and data an attacker can reach after compromising one identity. Strong identity governance aims to shrink blast radius by limiting privilege scope, isolating trust zones, and making revocation fast enough to beat attacker movement.
• Identity persistence: A condition where an attacker creates or abuses trusted objects that survive the original compromise. This can include OAuth apps, service principals, tokens, and backdoor accounts, all of which allow the attacker to return even after passwords are changed or sessions are closed.

What's in the full article

Linx Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdowns of each identity attack stage and how attackers progress from foothold to persistence
• Real-world response examples tied to the article’s Colonial Pipeline, Uber, Okta, and Storm-0558 cases
• Control-by-control guidance on MFA, JIT, detection, and revocation across the attack chain
• Practical examples of how the vendor maps identity events to containment actions

👉 Linx Security's full post covers the examples, response steps, and control guidance in more operational detail

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 responsible for identity security strategy or governance in your organisation, it is worth exploring.