What should organisations test in identity-focused adversary simulations?

Organisations should test whether a compromised identity can move from initial access to broader privilege before detection. Scenarios should include secret exposure, over-privileged service accounts, delegated vendor access, and weak offboarding. The goal is to expose where access assumptions fail, not just whether a single control generates an alert.

Why This Matters for Security Teams

Identity-focused adversary simulations should prove whether a compromised service account, API key, or delegated vendor identity can be used to expand access before defenders notice. That matters because identity is now the control plane for most enterprise systems, and NHI Mgmt Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges. If simulations only check for an alert, they miss the more important question of how far the attacker can actually go.

Security teams often over-focus on the compromise event itself and under-test the downstream paths: secret reuse, privilege chaining, lateral movement, and offboarding gaps. That is why identity simulations should reflect the conditions seen in real intrusions, not just a clean login failure. Guidance from the CISA cyber threat advisories and NHI Mgmt Group’s 52 NHI Breaches Analysis both point to the same pattern: attackers frequently succeed by abusing trusted identity paths rather than exploiting noisy perimeter failures. In practice, many security teams encounter identity abuse only after a service account has already touched multiple systems, rather than through intentional validation of access boundaries.

How It Works in Practice

Effective simulations start by selecting the identities most likely to be abused: long-lived service accounts, CI/CD tokens, vendor integrations, cloud workload identities, and application secrets stored outside a manager. The objective is to test whether the identity can authenticate, whether its entitlements are broader than expected, and whether a defender can stop misuse before the attacker reaches sensitive data or admin-level control.

A practical scenario usually maps to a small chain of actions:

• Expose or steal a secret from code, logs, or a misconfigured vault.
• Validate whether the secret still works after expected rotation or offboarding.
• Enumerate permissions attached to the identity and look for excessive access.
• Attempt privilege escalation through delegated roles, token exchange, or trust relationships.
• Measure whether alerts, revocation, and containment happen before broader compromise.

This is where identity-focused testing differs from a standard alert check. The most useful evidence is not just whether a detection fired, but whether the identity could move across environments, cloud tenants, or business applications. NHI Mgmt Group’s Key Challenges and Risks section highlights why this matters: secrets leak into code and CI/CD paths, while many organisations still lack reliable revocation and rotation. Current guidance suggests pairing simulation results with access review data so the team can see where assumed least privilege diverges from actual entitlement.

For stronger realism, align the exercise with identity telemetry, secret inventory, and workflow ownership. If a vendor account is compromised, test whether contractual access boundaries, JIT access, and offboarding controls are actually enforced. These controls tend to break down in highly automated environments where identities are shared across pipelines, tokens are reused across tools, and no single owner is accountable for revocation.

Common Variations and Edge Cases

Tighter identity simulation often increases operational overhead, requiring organisations to balance realistic attack paths against disruption to production workflows. That tradeoff matters because some identities are intentionally broad, especially in automation-heavy environments, but broad does not mean untestable.

One common edge case is third-party access. Vendor identities may be legitimate, yet they still deserve adversary simulation because trust boundaries are weaker and offboarding is often incomplete. Another is ephemeral cloud access: short-lived credentials can reduce dwell time, but they do not eliminate risk if the attacker can request new tokens through an abused workload path.

There is also no universal standard for how deep these simulations should go. Some teams focus on initial access plus privilege escalation; others include data access, persistence, and destructive actions. Best practice is evolving, but the test should always answer one question: can an attacker use one identity to reach more than that identity should permit? If the answer depends on undocumented exceptions, the environment is already harder to defend than the policy suggests.

For wider context on recurring identity failures, NHI Mgmt Group’s 52 NHI Breaches Analysis is useful because it shows how often identity weakness, not malware, becomes the real intrusion path.

Related resources from NHI Mgmt Group

• Why does identity matter more when vulnerabilities are discovered faster than they can be patched?
• What is the difference between prompt injection risk and identity abuse in agents?
• Why do non-human identities increase identity blast radius?
• When should organisations prioritise workload identity controls over more user-focused IAM work?