They assume traditional infrastructure is enough to test. In reality, the most meaningful gaps now often sit across identity, cloud, SaaS, and AI-enabled workflows, where trust relationships and delegated access create the attacker’s shortest path. Red teaming must follow those paths or it will miss the real exposure.
Why This Matters for Security Teams
Modern red teaming is supposed to show how an attacker would actually move through an organisation, but many programmes still focus on perimeter devices, isolated servers, or vulnerability counts. That approach misses the trust fabric that now matters most: identity providers, SaaS tenants, cloud control planes, privileged workflows, and sometimes AI-assisted business processes. A useful red team must validate paths, not just systems.
That shift aligns with NIST Cybersecurity Framework 2.0, which pushes organisations to treat security as an enterprise capability rather than a narrow technical exercise. It also means a red team is not simply testing whether a firewall blocks traffic, but whether trust can be abused across delegated access, federated identity, weak approval chains, and over-permissioned service accounts. For NHIMG clients, the key issue is that identity has become an attack route, not just an access layer.
Teams often get this wrong by using old scenarios because they are easier to schedule, easier to explain, and easier to measure. Those tests may still have value, but they can create false confidence if they never challenge the paths adversaries use to reach high-value assets. In practice, many security teams discover this only after an incident has already validated the attacker’s route rather than through intentional adversary simulation.
How It Works in Practice
Effective modern red teaming starts with attack-path modelling. The team identifies where trust is concentrated, how credentials or tokens are issued, and which workflows would let an intruder escalate from a low-value foothold to meaningful business impact. In cloud and SaaS environments, that often means mapping identity federation, API permissions, privileged roles, tenant-to-tenant trust, and recovery processes. In AI-enabled environments, it can also include prompt injection, tool abuse, data exfiltration through connected assistants, and insecure automation paths.
Practitioners should treat the engagement as a full campaign rather than a sequence of isolated tests. That means deciding whether the objective is data access, privilege escalation, fraud simulation, persistence, or business interruption, then proving each stage with observable evidence. Frameworks such as MITRE ATT&CK remain useful for mapping attacker behaviours, while the OWASP guidance on identity and agentic systems helps teams think about delegated authority and tool use in a more realistic way.
- Start with crown-jewel mapping, then identify the shortest identity-led path to those assets.
- Include SaaS, cloud, and third-party trust relationships, not just endpoints and servers.
- Validate how secrets, tokens, and API keys are stored, rotated, and abused.
- Test detection and response, not only initial access.
- Capture the business impact chain so findings can drive remediation priorities.
Where this guidance breaks down is in highly locked-down environments with limited telemetry and fragmented ownership, because the red team may be unable to prove paths end to end without privileged access to logs, cloud policy data, and identity records.
Common Variations and Edge Cases
Tighter red team scope often reduces operational risk, but it also increases the chance of missing the very paths attackers use, so organisations have to balance safety, legality, and realism. That tradeoff becomes more pronounced in regulated sectors, shared cloud estates, and environments where third-party integrations change weekly.
There is no universal standard for how much AI should be included in modern red teaming yet. Current guidance suggests testing AI only when it is part of a real business path, such as an assistant with tool access, a retrieval layer connected to sensitive data, or an automation workflow that can trigger actions. Pure model probing may be valuable for AI assurance, but it does not replace campaign-based red teaming for enterprise exposure.
Another common edge case is identity-heavy resilience testing. If privileged access is protected by strong controls but service accounts, API tokens, or delegated admin roles are not, the programme may still fail badly. That is why modern red teams often need to combine cloud, identity, and application testing rather than treat them as separate exercises. In the same way, organisations that only measure exploit success may miss whether controls actually detected, contained, and recovered from the attempt. A red team without detection engineering feedback becomes a demonstration, not a resilience test.
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Red teaming should reflect enterprise risk, not isolated technical testing. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Modern red teams target trust relationships that Zero Trust is meant to constrain. |
| OWASP Non-Human Identity Top 10 | Service accounts, tokens, and API keys are common red team escalation paths. | |
| OWASP Agentic AI Top 10 | Agentic workflows can be abused through prompts, tools, and delegated actions. | |
| MITRE ATT&CK | T1078 | Valid accounts is a common route for attackers and red team emulation. |
Tie red team objectives to enterprise risk decisions and update scenarios as business exposure changes.
