The settingWhat we hold this to
CreativeTechs minimum
Where Entra ID P2 exists: a CA policy on sign-in risk High = block or require MFA, and a second on user risk High = require secure password change. Both in state ENABLED.
Benchmark position
CISA MS.AAD.2.1 and 2.3, both tagged Entra ID P2. Both came back Skipped on the CreativeTechs tenant — licence-gated, not failing.
Where we differ, and why
Blocked on licence. Huntress ITDR already covers the detection half behaviourally, so the only thing P2 buys here is the automated response. Do not buy P2 for the detection.
Where the switch is
Entra admin centre → Protection → Conditional Access → Policies → New policy → Conditions → Sign-in risk / User risk.
How to verify
Graph: /identity/conditionalAccess/policies → conditions.signInRiskLevels contains 'high'
- Why it matters
- Automatic response to Microsoft's own identity risk signal — block or step up on a high-risk sign-in, force a reset on a high-risk user.
- How we check
- Maester CISA.MS.AAD.2.1 and 2.3 — both Skipped on our tenant, licence-gated. Secure Score SigninRiskPolicy and UserRiskPolicy.
- Fix — M365
- CA policy → sign-in risk High → block or require MFA. Second policy → user risk High → require secure password change.
- Fix — Google
- No equivalent at this tier.
- User notices
- An occasional extra prompt or a forced reset.
- Expected pushback
- Low from users. The biggest Secure Score gap in the fleet — 231 points across 24 tenants — and simultaneously the largest ITDR overlap.
- Huntress ITDR
- Partial. ITDR detects risky and anomalous sign-ins behaviourally, which is most of what the sign-in-risk policy would catch. What ITDR does NOT do is the automated response — forcing a password change on a high-risk user. If we buy P2 for anyone, that response is the reason, not the detection.
- Reason on file
- Needs Entra ID P2. ITDR covers the detection half; only the automated response is missing.