They often count them as successful security outcomes without explaining the business loss that was prevented. A blocked attack is valuable, but its importance depends on how much access was stopped and how quickly. Mature reporting distinguishes between denial, containment, and full compromise.
Why This Matters for Security Teams
Blocked identity attacks can be a useful signal, but only if the organisation understands what was actually prevented. A denied login, a stopped token replay, and a fully contained session hijack are not the same outcome. Treating them as equivalent creates misleading metrics, weakens risk communication, and hides where controls are failing to keep pace with attacker methods. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it anchors reporting in control effectiveness rather than event counts alone.
The real issue is that many teams optimise for the word “blocked” without asking what the attacker reached before being stopped. If the adversary already harvested secrets, established a foothold, or moved into a high-value identity path, the block may have prevented compromise but not exposure. That distinction matters for incident response, executive reporting, and post-incident lessons learned. It also matters for non-human identity and agentic AI environments, where a blocked call does not necessarily mean the workflow, token, or delegated access chain was safe.
In practice, many security teams discover the gap only after a blocked attempt is followed by lateral movement, rather than through intentional measurement of what was actually denied.
How It Works in Practice
Security teams should classify blocked identity attacks by stage, technique, and asset impact. A simple “success” or “failure” label is too shallow for modern identity telemetry. Mapping the event to attacker behaviour using the MITRE ATT&CK Enterprise Matrix helps distinguish password spraying, valid account abuse, token theft, MFA fatigue, and privilege escalation attempts. When AI-enabled tradecraft is involved, the MITRE ATLAS adversarial AI threat matrix can help teams reason about prompt injection, model manipulation, and AI-assisted recon that supports identity compromise.
A practical reporting model usually includes:
- What was blocked: credential submission, token use, session creation, privilege grant, or data access.
- Where it was blocked: IdP, PAM, SSO, endpoint, API gateway, application layer, or downstream control.
- What the attacker had already achieved: valid account access, secret exposure, mailbox access, or admin path discovery.
- How fast the block occurred: before authentication, after authentication, or after privileged action.
- What residual risk remained: exposed secrets, reusable tokens, service account abuse, or follow-on attempts.
This is where alerting, detection engineering, and incident response converge. A blocked attack should trigger investigation, not celebration, because the attacker may have tested multiple identity paths before being stopped. Current guidance suggests pairing block rates with dwell time, access depth, and control coverage so the metric reflects actual risk reduction. That is especially important for agentic systems that hold delegated credentials or tool access, because a single blocked action may still leave an autonomous workflow partially trusted. These controls tend to break down when identity events are siloed across cloud, endpoint, and SaaS platforms because no single system can show the full attack path.
Common Variations and Edge Cases
Tighter identity controls often increase operational friction, requiring organisations to balance stronger prevention against user disruption and investigation overhead. That tradeoff becomes visible in environments with high volumes of legitimate automation, shared service accounts, or delegated API access, where a block can interrupt business processes as easily as it can stop an adversary.
Best practice is evolving for AI-driven and non-human identity contexts. There is no universal standard for yet whether a blocked agent action should be reported separately from a blocked human login, but the distinction is increasingly important. A blocked agent may still have executed upstream steps, retrieved context, or triggered secondary actions before enforcement occurred. In those cases, security teams should describe the prevention boundary precisely rather than collapsing everything into a single “stopped” event.
The same caution applies to identity attacks that span multiple phases. A failed credential check may be low severity if no valid account existed, but high severity if the same actor had already obtained a session token or access to a privileged mailbox. For that reason, blocked identity attacks should be analysed alongside campaign-level evidence from CISA cyber threat advisories and, where relevant, reporting on AI-orchestrated operations such as Anthropic — first AI-orchestrated cyber espionage campaign report. The key question is not whether something was blocked, but whether the block prevented meaningful access, action, or persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATLAS and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Blocked attacks should be measured as monitoring outcomes, not just event counts. |
| NIST AI RMF | GOVERN | AI-driven identity attacks need governance for accountability and risk reporting. |
| MITRE ATLAS | Adversarial AI can support identity attacks and change what a block actually means. | |
| MITRE ATT&CK | T1078 | Valid accounts and credential abuse are central to blocked identity attack analysis. |
| NIST SP 800-53 Rev 5 | AU-6 | Review and analysis of security events is needed to interpret blocked attacks correctly. |
Define ownership, thresholds, and escalation rules for AI-assisted identity attack blocking.
