Why do red team exercises often miss the controls that matter most?

Because many programmes reward visible compromise, which pushes teams toward access-centric tactics and away from less theatrical but more realistic stages like discovery, persistence, and exfiltration. The result is a control-testing model that can look rigorous while leaving the highest-risk paths under-tested.

Why This Matters for Security Teams

red team exercise are supposed to reveal whether security controls hold up under realistic pressure, not whether a team can generate a dramatic alert. When the exercise plan overweights initial access, phishing, or a single compromised account, it can miss the controls that actually shape impact, such as segmentation, identity governance, logging depth, egress monitoring, and incident decision-making. That is why the exercise can feel successful while the organisation remains exposed.

The problem is partly structural. Many engagements are scoped around an observable “win condition,” so the most visible tactics get attention while quieter weaknesses go untested. The NIST Cybersecurity Framework 2.0 is useful here because it frames outcomes across govern, identify, protect, detect, respond, and recover, rather than treating compromise as the only meaningful checkpoint. In practice, red teaming should validate whether controls slow, constrain, detect, and contain an attacker at multiple stages.

That matters for identity too. In many environments, the highest-risk failure is not a single account takeover but the ability to move laterally, reuse secrets, or persist with privileged access unnoticed. If the exercise never reaches those stages, it may fail to test privilege boundaries, non-human identity governance, or the monitoring needed to see abuse of legitimate access. In practice, many security teams encounter their weakest controls only after a real incident exposes them, rather than through intentional exercise design.

How It Works in Practice

Effective red team design starts with the question: which control outcomes need proof, and which attack paths would stress them? Mature programmes map exercise objectives to likely adversary behaviours, then define milestones beyond compromise. That includes discovery, privilege escalation, credential access, persistence, command-and-control, lateral movement, and exfiltration. Using MITRE ATT&CK as a planning aid helps teams move from generic “test the SOC” requests to specific techniques and defensive assumptions.

Practitioners often get more value by testing the handoff between controls than by testing any single tool. For example:

• Can the SOC correlate identity events with endpoint and cloud telemetry quickly enough to distinguish normal admin activity from abuse?
• Do PAM and JIT controls actually constrain privileged use, or do standing privileges remain available in practice?
• Are secrets protected well enough that one compromised host does not expose the broader environment?
• Can detection engineering identify data staging and unusual outbound transfer, not just malware execution?

For cloud-heavy and hybrid environments, the control questions should extend into configuration drift, token reuse, service-account abuse, and logging gaps across control planes. Red teams should also validate whether response playbooks are usable under pressure, because even strong detections fail if escalation paths, containment authority, or evidence preservation are unclear. Guidance from the CISA Cybersecurity Performance Goals is helpful when translating tactics into operational control checks, especially for logging, access control, and incident response.

These controls tend to break down when exercises are constrained to a single business unit, a narrow time window, or a pre-approved attack path that avoids production-grade monitoring and privilege boundaries.

Common Variations and Edge Cases

Tighter exercise scope often reduces business disruption, but it can also lower the chance of finding the controls that fail in real incidents, so organisations have to balance safety against fidelity. That tradeoff is especially sharp in regulated environments, where live testing may be limited and the exercise becomes more of a tabletop with technical proof points than a full adversarial campaign.

There is no universal standard for how deep every red team should go. Current guidance suggests varying scenarios over time so the programme does not become predictable or fixated on one access vector. Some organisations focus one cycle on identity abuse, another on cloud control-plane weaknesses, and another on detection and recovery. That rotation is more useful than repeatedly proving that phishing still works. The ENISA threat landscape is a practical reminder that adversary behaviour evolves across the full kill chain, not just at the inbox.

The biggest edge case is a mature perimeter with weak internal telemetry. In that environment, an exercise may succeed only because the team can still reach a workstation or a user token, while the deeper control failures remain invisible. For identity-rich estates, the hardest part is often not gaining access but proving whether access is properly bounded, monitored, and revoked when it is no longer needed.

Related resources from NHI Mgmt Group

• Why do traditional red team exercises miss so many AI security issues?
• Why do identity controls matter in red and blue team simulations?
• Why do identity and access controls change the value of red team exercises?
• Why do red team exercises often fail to change security decisions?