They should start with crown jewels, likely threat actors, and the attack paths most likely to produce material loss. In practice that means systems like identity providers, privileged directories, customer portals, secrets stores, and critical cloud workloads. The right target set is small enough to be testable but important enough to influence the roadmap.
Why This Matters for Security Teams
Red team target selection is a risk decision, not a coverage exercise. If the target list is built around convenience, the exercise can produce impressive technical demonstrations while missing the systems that actually govern identity, privilege, and business continuity. Current guidance from the NIST Cybersecurity Framework 2.0 treats governance and risk prioritisation as a core part of security outcome management, which is the right lens here.
Security teams should focus on systems whose compromise would create cascading impact, expose sensitive data, or unlock lateral movement. That often includes identity providers, PAM platforms, secrets stores, cloud control planes, and customer-facing workflows that sit on top of trusted authentication. The mistake is to treat red teaming like a bug hunt against isolated assets instead of a test of whether the organisation can absorb a real intrusion path.
For NHIMG, the identity bridge is central: if an attacker can seize the control plane for users, services, or agents, the rest of the environment often becomes secondary. In practice, many security teams encounter the limits of their target strategy only after privilege abuse or token theft has already turned a narrow test into an enterprise incident.
How It Works in Practice
Effective target selection starts with a short list of mission-critical systems and the attack paths that connect them. A useful method is to map each candidate system to three questions: what material loss follows compromise, what path would a realistic adversary use, and what defensive decision would the test inform. That keeps the exercise anchored in risk rather than novelty.
Teams usually get better results when they combine asset criticality, threat intelligence, and dependency mapping. For example, a customer portal may matter less as a standalone application than as the front door to identity services, payment tokens, or privileged workflows. Likewise, a secrets manager is not just a repository; it is often the fastest route to cloud workloads, CI/CD pipelines, and service-to-service trust. MITRE ATT&CK is useful here because it helps teams translate target choices into observable attack techniques and detection gaps. See MITRE ATT&CK for technique mapping.
A practical selection process often looks like this:
- Rank systems by business impact if compromised, not by technical complexity.
- Identify the identities, tokens, keys, and trust relationships that connect those systems.
- Choose at least one path that tests prevention, detection, and response together.
- Include a mix of external-facing and internal control-plane targets where realistic.
- Validate that legal, safety, and operational constraints are defined before testing begins.
Where identity is involved, teams should test more than login flows. They should examine token theft, session hijack, privilege escalation, and the abuse of service accounts or non-human identities. The OWASP guidance on identity and application risk can help structure those questions, especially where web portals and APIs expose privileged actions. See OWASP for relevant application security guidance. These controls tend to break down when target scope is defined by ownership boundaries instead of end-to-end attack paths, because the real blast radius crosses multiple teams and platforms.
Common Variations and Edge Cases
Tighter red team scoping often increases coordination overhead, requiring organisations to balance realism against safety, legal review, and operational disruption. That tradeoff becomes sharper in regulated environments, in high-availability production systems, and where testing touches customer data or safety-critical processes.
There is no universal standard for this yet, but current guidance suggests that target selection should change with the purpose of the exercise. If the goal is executive assurance, focus on crown jewels and business interruption paths. If the goal is detection validation, include systems that are noisy, monitored, and likely to generate alerts. If the goal is identity resilience, prioritise identity providers, federation trust, privileged access workflows, and secrets distribution.
Edge cases matter. A system that looks low-value in isolation may be the most important pivot point in the estate. That is common with CI/CD runners, API gateways, enterprise SSO, and agent orchestration layers that hold broad execution authority. For modern environments, the best practice is evolving toward testing the trust fabric rather than individual servers. In complex hybrid estates, this approach should be paired with a clear safety model so red team activity does not interfere with backup systems, incident response tooling, or live fraud controls.
When uncertainty remains, security teams should choose the smallest set of targets that still exercises the highest-value attack chain. Anything broader usually dilutes learning and makes remediation harder to prioritise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-1 | Target choice should be driven by threat and impact risk, not convenience. |
| MITRE ATT&CK | T1078 | Valid account abuse is a common path from a chosen target to broader compromise. |
| OWASP Non-Human Identity Top 10 | NHI and secrets-rich systems are often the highest-value red team targets. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Attack paths should test trust boundaries and segmentation effectiveness. |
| NIST AI RMF | GOVERN | Red team prioritisation for AI and agentic systems needs governance and accountable risk decisions. |
Pick targets that let testers emulate realistic techniques and measure detection for account abuse.
Related resources from NHI Mgmt Group
- How do security teams decide which legacy systems to retire first?
- How do security teams decide which OpenSSL systems to patch first?
- How should security teams decide whether to modernise authentication or stabilise existing systems first?
- How should security teams run AI red teaming for GenAI systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
