Cross-identity attack path

How cross-identity attack paths work

A cross-identity attack path is not just “credential abuse.” It is a sequence in which an attacker intentionally crosses identity boundaries to keep moving after initial access, often because each identity type grants a different kind of trust, privilege, or persistence.

The important idea is that the path changes shape as it progresses. A human login may be used to reset access or approve a session, a service account may provide durable back-end reach, and an agent or automation role may open tool access or delegated actions. That progression matters because defenders who only watch one identity class can miss the handoff.

This pattern is especially visible in environments with shared admin paths, delegated access, broad service permissions, or weak separation between human and machine identities. In practice, the attack path is the relationship between identities as much as the identities themselves.

For a broader view of how attackers chain identity abuse across environments, the mechanics of Identity Threat Detection and Response (ITDR) are directly relevant, because cross-identity movement is often detected only when the full sequence is correlated.

Where cross-identity paths usually begin

Most cross-identity attack paths start with one of a small set of entry points: stolen human credentials, password reset abuse, session theft, exposed secrets, or misuse of a third-party integration. The first identity is often the easiest one to compromise, not the final one the attacker wants.

From there, the attacker looks for the next identity that has more useful reach, such as a service account with persistence, a cloud role with automation authority, or an agent credential that can invoke tools and services. The handoff is the key event, because it converts an initial foothold into broader control.

Identity boundaries are also crossed when defenders allow weak delegation. For example, a human account may be permitted to mint or approve access for a non-human account, or an automation identity may be allowed to act on behalf of a person without tight scoping. Those bridges are legitimate features, but they become attack paths when they are too broad or too difficult to observe.

Guidance on lifecycle, ownership, and rotation helps explain why these paths emerge so often. The NHI Lifecycle Management Guide is useful here because stale, shared, or over-retained identities create the conditions for identity hopping.

Why defenders treat identity transitions as a control problem

Cross-identity attack paths are dangerous because each transition can bypass a different control. Human identities may be protected by MFA, but a service account may rely on long-lived secrets. A machine role may avoid interactive login controls, while an agent role may be trusted to execute actions once it has tool access. The attacker does not need every identity to be weak, only one usable chain.

That is why posture management matters. If identity inventory, privileges, secrets, and environment boundaries are not continuously reviewed, it becomes hard to see where one identity can impersonate, delegate to, or inherit from another. Identity Security Posture Management (ISPM) Guide is relevant because it frames these paths as a posture issue, not just an incident-response issue.

Cross-identity paths also create detection gaps. A compromise may look low severity in one system, then become severe after the attacker pivots into a different identity type with better access. Detecting that progression requires correlation across authentication, authorization, secret use, and privilege changes, not just alerting on a single account.

Attacker behaviour across identity types is covered in the The State of NHI & AI Agent Breach Report 2026, which shows why stolen tokens, compromised service accounts, and delegated access often appear in the same intrusion chain.

How to think about defence and investigation

Defending against cross-identity attack paths means tracing who can hand off authority to whom, not only who can log in. The practical question is whether one identity can be used to reach another identity class with different trust assumptions, longer persistence, or broader operational reach.

When investigating, analysts should reconstruct the sequence of identity transitions, including resets, token issuance, secret use, role assumption, and tool invocation. That makes it possible to see where the attacker crossed from human into machine, from machine into service, or from service into agentic access.

The best defensive model is to treat identity transitions as privileged events in their own right. If a boundary crossing is unusual, excessive, or poorly owned, it should be visible as an escalation path even when each individual step looks legitimate on its own.

For identity-detection practice, Identity Threat Detection and Response (ITDR) and Active Directory and Entra ID Hardening Guide both support the same core lesson: break the chain, not just the account.

Risk and Threat Considerations

Cross-identity attack paths are risky because compromise rarely stays inside the first identity that was touched. Once an attacker can move from a human account into a service or agent identity, they often gain persistence, broader reach, and access that is harder to monitor with standard user-centric controls.

Failure mechanism: Weak delegation, shared secrets, overprivileged roles, or poor identity separation let an attacker pivot from one trust domain to another without triggering a clear boundary event. Each handoff expands the attack surface and can bypass controls designed for only one identity type.

Impact: The result can be lateral movement, durable persistence, unauthorized tool use, and escalation into high-value systems or data. In mature environments, the biggest danger is not one compromised identity, but the attacker’s ability to convert that foothold into a chain of identities with compounding authority.

Practitioner Guidance

Why practitioners should care: Cross-identity attack paths are a governance problem as much as a detection problem. If human, service, workload, and agent identities are managed in separate silos, no single owner may see the full attack route or understand where authority can be handed off.

Common misunderstanding: Teams often assume MFA or strong login policy is enough if the first account is protected. In reality, the attacker may only need the first identity to reach a weaker back-end identity with longer-lived access or broader privilege.

Practitioner takeaway: Map the handoffs between identity types, then treat each handoff as a control point that must be owned, limited, and observable.

Related resources from NHI Mgmt Group

• Why do cloud-native security programs need identity-aware attack path analysis?
• Who is accountable when a known identity attack path is not addressed?
• How should security teams build identity governance for environments where credentials are the main attack path?
• Why do identity permissions matter so much in attack path analysis?