Accountability sits with the teams that own identity, privilege, and remediation governance, not just awareness training. If a simulation shows that common accounts can reach critical systems, leaders must answer for entitlement design, access review quality, and remediation prioritisation. Awareness is only one part of the control stack.
Why This Matters for Security Teams
When a phishing simulation exposes a large blast radius, the real issue is not email hygiene. It is whether identity, privilege, and recovery controls were designed to limit how far a compromised account can move. NHI Management Group notes that 97% of NHIs carry excessive privileges, which turns a single credential into an enterprise-wide risk. That is why outcomes from simulations should be treated as governance signals, not training scores.
Large blast radius findings also show whether access reviews are meaningful, whether privileged paths are documented, and whether remediation has an owner. If a common account can reach production systems, the failure sits with entitlement design and control validation, not with the person who clicked. This is especially true when the same patterns show up in incidents like Poland Military Breach and CoPhish OAuth Token Theft via Copilot Studio, where access scope mattered more than awareness alone. In practice, many security teams encounter this only after a simulation or compromise has already shown how much can be reached from a single foothold.
How It Works in Practice
Accountability should be assigned along the control chain. Identity engineering owns the shape of access, application and platform owners own what the account can actually reach, and security governance owns whether the exposure was measured, escalated, and remediated. A simulation that reveals broad reach is evidence that least privilege, segmentation, or privileged access management was not enforced effectively. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it ties access control, auditability, and corrective action to named responsibilities rather than vague awareness outcomes.
Practically, teams should review three layers:
- Who approved the original entitlement and whether the business justification still exists.
- Whether the account has standing access that should have been time-bound or segmented.
- Whether monitoring, alerts, and remediation workflows are strong enough to shrink blast radius after exposure.
This is where NHIMG guidance on the Ultimate Guide to Non-Human Identities is directly relevant, because the same excess-privilege and visibility problems that affect NHIs often mirror what simulations expose in human and service-account estates. The accountability question should therefore be answered in post-test governance review, with remediation tracked as a control failure, not just a learning outcome. These controls tend to break down when privilege data is stale, ownership is split across teams, and no one is empowered to remove access quickly.
Common Variations and Edge Cases
Tighter remediation usually increases coordination cost, requiring organisations to balance speed of access removal against disruption to operations. That tradeoff matters when blast radius is large but the affected accounts support critical services, shared admin functions, or legacy applications with unclear ownership. Current guidance suggests assigning accountability to the control owner closest to the failure, but there is no universal standard for this yet across every environment.
One common edge case is a simulation that exposes access inherited through group nesting, inherited roles, or service accounts used by automation. In those situations, the accountable party is often not the end user, but the team that approved the role model and the system owner that allowed overbroad inheritance. Another edge case is when remediation depends on third-party platforms or outsourced operations. Even then, the internal owner remains responsible for validating that the blast radius was reduced and that corrective actions were completed.
For governance programs, the key question is not who clicked, but who allowed excessive reach to exist and remain uncorrected. That framing aligns better with NIST SP 800-53 Rev 5 Security and Privacy Controls and the NHIMG view that access, rotation, and revocation are lifecycle duties, not one-time awareness outcomes.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Blast radius often reflects excessive NHI privileges and weak entitlement governance. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access review failures are central when simulations show broad reach. |
| NIST SP 800-63 | Accountability depends on identity proofing and lifecycle controls that bound account misuse. | |
| NIST AI RMF | GOVERN | Simulation findings require ownership, escalation, and traceable governance decisions. |
| NIST Zero Trust (SP 800-207) | SC-7 | Large blast radius shows inadequate segmentation and perimeter assumptions. |
Strengthen identity lifecycle assurance so privileged accounts cannot persist without oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
