Six Controls, One Compromised Helpdesk Login

Nothing in this chain failed because the platform was weak. Identity Protection detected the token replay in Stage 2 exactly as designed — it simply had nothing left to challenge once a fully-authenticated session cookie was in play, which is a known limit of risk-based step-up, not a bug. PIM's authentication context stopped the direct privilege-escalation attempt cold in Stage 4, because a phishing-resistant credential genuinely cannot be relayed by an AiTM proxy. Every failure downstream of that point — the unreviewed access package, the four-minute rubber-stamp approval — was a governance decision, not a technology gap.

What finally closed the loop was correlation, not any single control: an Access Review's machine-learning recommendation only looked convincing because it cross-referenced a risk signal Identity Protection had been carrying, unresolved, since Stage 2. That is the real argument for licensing all six pillars together rather than picking one — each one closes a different phase of the same attack, and the ones that look "redundant" on a feature-comparison chart are usually the ones that catch what an earlier control only detected. The concrete fixes on Rud’s side of the table: make phishing-resistant authentication strength the baseline for every privileged activation in the tenant, not just the policy the attacker happened to hit first; put a real expiry and re-review date on every access package at creation time; and feed Identity Protection's risk score into access review recommendations as a matter of course, not as a lucky coincidence.