Project 6 — Entra ID Protection (Risk-Based Identity Controls)

Portfolio Position: Pillar 6 of 7 — Identity Risk & Protection
Tenant: Patchthecloud.onmicrosoft.com | Microsoft 365 Business Premium
Licensing: Microsoft Entra ID P2
Lab Date: January 2026

---

Business Problem

Project 1 (Zero Trust Identity Perimeter) established CA01 — a baseline Conditional Access policy requiring MFA for all users. MFA significantly reduces credential-based attacks, but it treats every sign-in equally regardless of risk. The gap:

• A user whose credentials appear in a breach database bypasses risk controls with MFA
• A sign-in from a Tor exit node or impossible travel location is not automatically challenged
• A compromised account remains active until an analyst manually discovers and remediates it
• No proportional response: the same MFA prompt applies to a normal sign-in and a sign-in from an anonymous proxy

The gap: Baseline MFA (CA01) does not protect against identity risk — anomalous behaviour patterns that indicate compromise even after MFA is satisfied.

---

Business Requirement

Requirement	Rationale
Risk-based sign-in challenge	Block or require MFA only when risk signals are present, not for every sign-in
Automatic compromised account remediation	Force password reset when user risk is High — no analyst intervention
Real-time detection	Risk evaluated at every sign-in using AI-driven signals
Break-glass account exclusion	Prevent lockout of emergency admin account
Defender XDR correlation	Identity risk signals fed into XDR for cross-pillar correlation

---

Microsoft Solution

Component	Role
Entra ID Protection	AI-driven risk engine — detects impossible travel, leaked credentials, anonymous IP, token theft, and more
CA02 — Risk — User Risk Remediation	If user risk = High → require password change (remediates compromised accounts)
CA03 — Risk — Sign-in Risk Block	If sign-in risk = Medium or High → block access (prevents suspicious sign-ins)
Risky Users dashboard	Visibility into users flagged with elevated risk; admin dismiss/confirm workflows
Risky Sign-ins dashboard	Per-sign-in risk timeline; audit trail for suspicious access events
Defender for Identity	Cloud identity threat detection; 228 cloud users onboarded

---

Enterprise Perspective

Stage	Detail
Business Problem	CA01 baseline MFA treats all sign-ins equally. No adaptive control for compromised credentials, token theft, or suspicious sign-in patterns.
Business Requirement	Risk-proportional controls: block risky sign-ins in real time; auto-remediate compromised accounts; break-glass account excluded.
Microsoft Solution	Entra ID Protection risk engine → CA02 (user risk → password reset) + CA03 (sign-in risk → block)
Configuration	Both policies deployed via Report-only → On methodology. CA02: High user risk → require password change. CA03: Medium/High sign-in risk → block. Break-glass excluded from both.
Validation	4 screenshots document progression from Report-only to On for each policy. Risky sign-ins: No results (clean environment). Defender Identity: 228 cloud users monitored.
Outcome	Three-layer identity protection active: CA01 (baseline MFA) + CA02 (user risk remediation) + CA03 (sign-in risk block). Every sign-in risk-evaluated. Zero open risky sign-ins.

---

Conditional Access Policy Stack (Verified)

Policy	Condition	Control	Method	State
CA01 — Baseline — Require MFA (All Users)	All sign-ins	Require MFA	—	✅ On
CA02 — Risk — User Risk Remediation	User risk: High	Require password change	Report-only → On	✅ On
CA03 — Risk — Sign-in Risk Block	Sign-in risk: Medium, High	Block access	Report-only → On	✅ On

Break-glass account: Excluded from CA02 and CA03. This is a mandatory safety control — a locked break-glass account cannot recover a misconfigured tenant.

Policy Deployment Methodology

Following the same Report-only → Validate → On approach used in Project 1:

Step	CA02 (User Risk)	CA03 (Sign-in Risk)
1. Create in Report-only	A-1: CA02 Report-only, CA01 On	A-3: CA03 Report-only, CA01+CA02 On
2. Validate sign-in logs	Review report-only impact, confirm no false positives	Review report-only impact
3. Enable (On)	A-2: CA02 moved to On	A-4: CA03 moved to On

---

Risky Users & Sign-ins (Verified)

Dashboard	Result	Interpretation
Risky sign-ins (last 7 days)	No results	No suspicious sign-ins detected in the lab period — clean environment
Risky users	Active filter applied; monitoring enabled	No high-risk users currently; risk policies are armed and ready

Enterprise insight: "No risky sign-ins" is the intended outcome of a well-configured identity protection posture. It means either (a) no compromise has occurred, or (b) CA03 blocked the suspicious sign-in before it appeared as a successful risky event. This is distinct from an unconfigured environment — the policies are On, risk is monitored, and the absence of results confirms a healthy posture.

---

Defender for Identity (Appendix A.8)

Metric	Value
Cloud Users	228
On-Premises Users	0
Hybrid Users	0
Dashboard Status	Active

228 cloud identities are onboarded and monitored via the Defender for Identity dashboard within the Microsoft Defender portal. Alerts from Defender for Identity feed into Defender XDR (Project 5) for cross-pillar correlation with endpoint and email signals.

---

Implementation Phases

Phase	Activity	Status
1 — Review	Access Entra ID Protection; confirm risk detections are enabled by default	✅ Complete
2 — User Risk Policy	Create CA02 in Report-only → validate → move to On	✅ Complete
3 — Sign-in Risk Policy	Create CA03 in Report-only → validate → move to On	✅ Complete
4 — Dashboard Validation	Confirm risky users and risky sign-ins dashboards operational	✅ Complete
5 — Defender Integration	Confirm Defender for Identity dashboard — 228 cloud users onboarded	✅ Complete

---

PowerShell Automation Scripts

Script	Purpose
New-RiskBasedCAPolices.ps1	Deploy CA02 and CA03 via Graph API with break-glass exclusion
Get-EntraIDProtectionReport.ps1	Export risk detections, risky users, and risky sign-ins to CSV
Get-RiskyUsersReport.ps1	Retrieve all risky users with risk level, state, and last sign-in

---

Repository Structure

Project-6-Entra-ID-Protection/
├── README.md
├── .gitignore
├── LICENSE
├── GITHUB-METADATA.md
├── WEBSITE-PORTFOLIO-CARD.md
├── docs/
│   ├── 01-entra-id-protection-overview.md
│   ├── 02-user-risk-policy.md
│   ├── 03-sign-in-risk-policy.md
│   ├── 04-risky-users-sign-ins.md
│   ├── 05-defender-identity-integration.md
│   ├── 06-validation-testing.md
│   └── screenshots-placement-guide.md
├── scripts/
│   ├── New-RiskBasedCAPolicies.ps1
│   ├── Get-EntraIDProtectionReport.ps1
│   └── Get-RiskyUsersReport.ps1
└── architecture/
    └── entra-id-protection.md

---

Zero Trust Alignment

This project extends the Identity pillar from Project 1 with adaptive, risk-based controls:

Zero Trust Principle	Implementation
Verify Explicitly	Every sign-in evaluated for risk signals — not just credentials checked
Least Privilege	Risky users immediately restricted to password-reset-only workflow
Assume Breach	Users treated as potentially compromised; High user risk = forced remediation

---

Relationship to Other Projects

Project	Relationship
P1 — Zero Trust Identity Perimeter	CA01 (MFA baseline) built in P1. CA02/CA03 in this project build on that foundation.
P5 — Defender XDR + Sentinel	Identity risk signals from Entra ID Protection feed into Defender XDR for cross-pillar correlation.

---

Lessons Learned

1. Detection is not enforcement — Entra ID Protection detects risk by default, but Conditional Access policies must be created separately to enforce controls. A tenant without CA02/CA03 detects risk but takes no action.
2. Report-only before On — Both policies started in Report-only to validate impact before enforcement. This prevents false positives from locking out legitimate users.
3. Break-glass exclusion is non-negotiable — Excluding the break-glass account from risk-based CA policies is a safety requirement documented in the SOP. Without this, a misconfigured High-risk policy could lock out all admin access.
4. No results = healthy, not absent — The Risky Sign-ins dashboard showing "No results" in the lab period confirms the environment is clean, not that monitoring is not working.
5. Entra ID Protection is P2-licensed — Requires Microsoft Entra ID P2 (included in Microsoft 365 Business Premium and E5). Attempting to configure without P2 results in the feature being visible but non-functional.

---

Future Improvements

Improvement	Business Value
Named locations	Exclude known corporate IP ranges from risk evaluation to reduce false positives
Token protection	Prevent token theft / session replay attacks (Entra ID Protection P2 feature)
Authentication strength	Require phishing-resistant MFA (FIDO2) for High sign-in risk, not just block
Risk-based access to privileged roles	Combine with PIM (Project 1) — require fresh MFA when risk is detected before PIM activation
Workload identity risk	Enable risky workload identities monitoring (service principals and managed identities)