Enterprise-grade Zero Trust Identity implementation using Microsoft Entra ID Conditional Access, Privileged Identity Management, and Identity Protection.
Overview · Architecture · Implementation · Scripts · Gallery
This project documents the end-to-end implementation of the Identity pillar of the Microsoft Zero Trust security model using Microsoft Entra ID (formerly Azure Active Directory). The implementation enforces the principle of "verify explicitly, use least privilege access, assume breach" across all identity-driven access decisions in a Microsoft 365 environment.
The engagement covers seven implementation phases, progressing each Conditional Access policy through a safe Report-Only → Enforced deployment lifecycle. All configurations have been validated in a live Microsoft 365 tenant and evidence captured at each stage.
| Metric | Value |
|---|---|
| Implementation Phases | 7 |
| Conditional Access Policies | 5 |
| Authentication Methods Configured | 4 (Authenticator Push, SMS, FIDO2, Voice) |
| PIM Roles Configured | Global Administrator (JIT) |
| Deployment Pattern | Report-Only → Enforced |
| Evidence Screenshots | 30 |
Modern enterprises face an identity-centric threat landscape where:
- Over 99% of account compromise attacks can be prevented by enabling MFA (Microsoft Security Intelligence).
- Legacy authentication protocols (SMTP AUTH, POP3, IMAP, Basic Auth) bypass modern authentication controls and cannot enforce MFA, making them a primary attack vector.
- Privileged accounts with permanent standing access represent a critical blast radius if compromised.
- Risky sign-ins from unfamiliar locations, anonymous IPs, and atypical travel patterns go unchallenged without intelligent risk-based policies.
- Security Defaults provide a baseline but lack the granularity required for enterprise-grade compliance.
Without a structured Conditional Access framework, organisations rely entirely on password strength — a fundamentally insufficient control against modern credential-based attacks.
This implementation replaces Microsoft Security Defaults with a layered Conditional Access policy framework, integrating Microsoft Entra ID Protection signals to create an adaptive, risk-aware access control plane.
┌─────────────────────────────────────────────────────────────────┐
│ ACCESS REQUEST │
│ User + Device + Location + App │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ CONDITIONAL ACCESS POLICY ENGINE │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ Baseline │ │ Risk-Based │ │ Named Locations │ │
│ │ MFA Policy │ │ Policies │ │ (Trusted Networks) │ │
│ └──────────────┘ └──────────────┘ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ ┌──────────────────────────────────┐ │
│ │ Block Legacy Auth │ │ Authentication Methods │ │
│ │ Policy │ │ (Push / SMS / FIDO2) │ │
│ └──────────────────────┘ └──────────────────────────────────┘ │
└──────────────────────────┬──────────────────────────────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
✅ Grant 🔒 Block ⚠️ Require
Access Access MFA / PWD Reset
Key design decisions:
- Security Defaults disabled in favour of granular Conditional Access policies
- All policies staged in Report-Only mode before enforcement (zero-disruption rollout)
- Microsoft Authenticator push notifications as the primary MFA method
- FIDO2 security keys enabled for privileged accounts
- PIM configured for Just-In-Time privileged access (zero standing access)
- Identity Protection integrated to feed real-time risk signals into Conditional Access
graph TB
subgraph Users["👥 Identity Layer"]
U1[Standard Users]
U2[Privileged Admins]
U3[Service Accounts]
end
subgraph Signals["🔍 Risk Signal Sources"]
IP[Entra ID Protection<br/>Risk Engine]
NL[Named Locations<br/>Trusted IPs & Countries]
AM[Authentication Methods<br/>Push / SMS / FIDO2]
end
subgraph CA["⚙️ Conditional Access Policy Engine"]
P1[1.1 Baseline MFA<br/>All Cloud Apps]
P2[1.2 User Risk Policy<br/>High Risk → PWD Reset + MFA]
P3[1.3 Sign-in Risk Policy<br/>Medium+ Risk → MFA]
P4[1.4 Block Legacy Auth<br/>Exchange ActiveSync + Other]
P5[1.5 Named Locations<br/>Restrict Untrusted Networks]
end
subgraph PIM["🔐 Privileged Access"]
JIT[Just-In-Time<br/>Role Activation]
APPR[Approval Workflow<br/>Time-Bound Access]
end
subgraph Outcome["✅ Access Decisions"]
GRANT[Grant Access]
BLOCK[Block Access]
MFA_REQ[Require MFA]
PWD[Force Password Reset]
end
U1 --> CA
U2 --> PIM
U3 --> CA
PIM --> CA
IP --> CA
NL --> CA
AM --> CA
P1 --> MFA_REQ
P2 --> PWD
P3 --> MFA_REQ
P4 --> BLOCK
P5 --> GRANT
P5 --> BLOCK
MFA_REQ --> GRANT
PWD --> GRANT
style CA fill:#0078D4,color:#fff
style PIM fill:#FF6B35,color:#fff
style Signals fill:#00B388,color:#fff
style Users fill:#2B2B2B,color:#fff
style Outcome fill:#107C10,color:#fff
flowchart LR
subgraph Phase1["Phase 1 — Baseline"]
B1[Disable Security Defaults]
B2[Configure Auth Methods]
B3[Create CA Policy - Report Only]
B4[Validate Reporting]
B5[Enforce CA Policy]
B1 --> B2 --> B3 --> B4 --> B5
end
subgraph Phase2["Phase 2 — Risk-Based"]
R1[User Risk Policy<br/>Report Only]
R2[User Risk Policy<br/>Enforced]
R3[Sign-in Risk Policy<br/>Report Only]
R4[Sign-in Risk Policy<br/>Enforced]
R1 --> R2
R3 --> R4
end
subgraph Phase3["Phase 3 — Legacy Auth"]
L1[Block Legacy Auth<br/>Report Only]
L2[Validate No Breakage]
L3[Block Legacy Auth<br/>Enforced]
L1 --> L2 --> L3
end
Phase1 --> Phase2
Phase2 --> Phase3
sequenceDiagram
participant Admin as 👤 Administrator
participant CA as ⚙️ Conditional Access
participant Mon as 📊 Sign-in Logs
participant Users as 👥 Users
Admin->>CA: Create Policy (Report-Only)
CA->>Mon: Log would-be decisions (no impact)
Admin->>Mon: Review impact — who would be affected?
Mon-->>Admin: Impact report (affected users, apps, locations)
Admin->>Admin: Validate scope — tune exclusions if needed
Admin->>CA: Switch Policy to Enabled (Enforced)
CA->>Users: Enforce MFA / Block / Grant
Users-->>CA: Authenticate with MFA
Admin->>Mon: Monitor for unexpected blocks
| Component | Details |
|---|---|
| Tenant Type | Microsoft 365 Business Premium / E3/E5 |
| Identity Provider | Microsoft Entra ID (Azure AD P2 features used) |
| Licensing Required | Entra ID P2 (for Identity Protection + PIM) |
| Admin Portal | entra.microsoft.com |
| PowerShell Module | Microsoft.Graph (v2.x) |
| Deployment Method | Azure Portal GUI + PowerShell validation |
| Evidence Format | Portal screenshots at each configuration stage |
| Technology | Purpose |
|---|---|
| Microsoft Entra ID | Identity and Access Management platform |
| Conditional Access | Policy-based access control engine |
| Entra ID Protection | ML-driven risk detection for users and sign-ins |
| Privileged Identity Management (PIM) | Just-In-Time privileged role activation |
| Microsoft Authenticator | Primary MFA method (push notifications + passwordless) |
| FIDO2 Security Keys | Phishing-resistant MFA for privileged accounts |
| Named Locations | Trusted IP ranges and country allowlists |
| Authentication Methods Policy | Centralised control of all authentication methods |
| Microsoft Graph API | PowerShell automation and reporting |
| Sign-in Logs / Audit Logs | Monitoring and validation evidence |
Before beginning this implementation, verify the following:
Licensing
- Microsoft Entra ID P2 licence assigned to all in-scope users (required for Risk-Based CA and PIM)
- Microsoft 365 E3/E5 or Business Premium (includes Entra ID P1 minimum)
Roles Required
- Global Administrator (for initial setup and Security Defaults change)
- Conditional Access Administrator or Security Administrator (ongoing management)
- Privileged Role Administrator (for PIM configuration)
Pre-Implementation Checks
- Inventory all service accounts and break-glass accounts — exclude from MFA policies
- Identify any legacy authentication clients (on-premises mail clients, printers, scanners)
- Confirm no existing Conditional Access policies that may conflict
- Create at least one Break Glass emergency access account excluded from all CA policies
- Enable Entra ID audit logging to Log Analytics (recommended before any changes)
PowerShell Prerequisites
# Install Microsoft Graph PowerShell SDK
Install-Module Microsoft.Graph -Scope CurrentUser -Force
# Verify installation
Get-Module Microsoft.Graph -ListAvailable | Select-Object Name, VersionDeployment Safety Pattern: Every Conditional Access policy in this project was first deployed in Report-Only mode, monitored via Sign-in Logs, validated for impact, and only then switched to Enabled (Enforced). This pattern is mandatory for enterprise deployments to prevent accidental lockouts.
Objective: Replace Security Defaults with a granular Conditional Access policy requiring MFA for all users across all cloud applications.
Why this matters: Security Defaults enforce MFA but cannot be customised — they block legacy authentication globally, apply MFA to all users including service accounts, and cannot integrate with risk signals. A Conditional Access policy gives you full control over scope, conditions, and grant controls.
Security Defaults must be disabled before creating Conditional Access policies. Both cannot be active simultaneously.
Navigation: Entra ID → Properties → Manage Security Defaults → Set to Disabled
What this shows: The Security Defaults toggle has been set to Disabled in the Entra ID tenant properties. The reason selected is "My organization is using Conditional Access" — the correct justification that signals a planned migration rather than security regression.
Best practice: Document the date and approver of this change in your change management system. This is an auditable action visible in the Entra ID Audit Log.
Before enforcing MFA, configure the available authentication methods in the centralised Authentication Methods policy.
What this shows: The Authentication Methods policy blade in Entra ID showing the initial state of authentication method registrations across the tenant — including which methods are enabled, which are Microsoft-managed, and the registration status.
What this shows: The configured authentication methods with Microsoft Authenticator enabled as the primary method. The policy is configured at the tenant level, replacing the legacy per-user MFA settings for a centralised management experience.
Best practice: Migrate authentication method management from the legacy MFA portal (account.activedirectory.windowsazure.com/usermanagement/multifactorverification.aspx) to the unified Authentication Methods policy. The legacy portal will be retired.
Create the policy scoped to All users → All cloud apps → Require MFA, set to Report-Only first.
What this shows: The Conditional Access policy CA001 - Baseline - Require MFA for All Users is in Report-only state. In this mode, the policy evaluates every sign-in and logs what it would have done, with zero impact on users. This is visible in Sign-in Logs under the "Report-only" tab.
Best practice: Name policies using a consistent convention: CA[number] - [Category] - [Description]. This makes audit logs readable and policy management scalable.
Before enforcement, document that MFA is NOT currently required — this establishes the pre-enforcement baseline.
What this shows: A user sign-in completing successfully without an MFA prompt while the CA policy is in Report-Only mode. This confirms the Report-Only mode is working correctly — the policy is evaluating but not enforcing. This screenshot serves as the "before" evidence for the implementation.
Before enforcing, verify MFA registration coverage across the tenant.
What this shows: The MFA registration status report from the Entra ID portal (or PowerShell export), displaying which users have registered at least one MFA method and which remain unregistered. Users without MFA registered will be blocked at sign-in once the policy is enforced.
Best practice: Use the Authentication Methods Activity report and ensure registration coverage exceeds 95% before enforcement. Communicate to users in advance using a targeted campaign.
Once MFA registration is confirmed, switch the policy from Report-Only to Enabled.
What this shows: The Conditional Access policy has been switched from Report-Only to On (Enabled) and the policy assignment is now active. The policy summary shows: Users = All Users, Cloud apps = All cloud apps, Grant = Require multifactor authentication.
What this shows: Confirmation that the Baseline MFA Conditional Access policy is now enforced across the tenant. All authentication requests are now evaluated against this policy and MFA is required before access is granted to any cloud application.
Validation: Sign in as a test user — you should be prompted for MFA on every new authentication session.
Objective: Integrate Microsoft Entra ID Protection risk signals into Conditional Access to automatically respond to high-risk users and risky sign-in events.
Why this matters: Entra ID Protection analyses billions of signals daily and assigns risk scores to users and sign-in events. Without risk-based Conditional Access, a compromised account can sign in successfully as long as the attacker has the correct password and can pass MFA. Risk-based policies add a second layer — even if MFA is passed, a high-risk sign-in can be blocked or forced to reset credentials.
Risk Levels:
- User Risk: Probability that a user identity has been compromised (based on leaked credentials, anomalous behaviour)
- Sign-in Risk: Probability that a specific sign-in attempt was not performed by the account owner (anonymous IP, atypical travel, malware-linked IP, etc.)
Policy logic: If user risk = High → Require password change + MFA
What this shows: The User Risk-based Conditional Access policy CA002 - Risk - High User Risk in Report-only state. The policy conditions show User risk = High, Grant controls = Require password change (which implicitly requires MFA). No users are impacted yet — the policy is logging would-be decisions.
What this shows: The User Risk policy switched to Enabled (Enforced). Any user Entra ID Protection flags as High risk will now be required to reset their password and complete MFA before accessing any cloud resource. The account is effectively soft-locked until the risk is remediated.
Best practice: Exclude break-glass accounts and service accounts from risk-based policies. High-risk service accounts should be alerted on separately through Entra ID Protection alerts configured in Microsoft Sentinel.
Policy logic: If sign-in risk = Medium or High → Require MFA
What this shows: The Sign-in Risk Conditional Access policy CA003 - Risk - Medium+ Sign-in Risk in Report-only mode. The policy targets sign-in risk level ≥ Medium, requiring MFA as a step-up control. In Report-only mode, sign-in logs show the risk level detected and what the policy would have done.
What this shows: The Sign-in Risk policy is now Enabled. Any sign-in flagged as Medium or High risk will trigger an MFA challenge. If the user cannot complete MFA, access is blocked. The risk signal is cleared once MFA is successfully completed for a legitimate user.
Monitoring: Review the Risky Sign-ins report weekly in Entra ID Protection. Confirmed safe sign-ins should be marked as "confirmed safe" to improve the risk model accuracy for your tenant.
Objective: Block all authentication requests using legacy protocols that cannot support modern authentication controls including MFA.
Why this matters: Legacy authentication protocols (Basic Auth, NTLM for cloud apps, Exchange ActiveSync v14 and below, POP3, IMAP, SMTP AUTH, Autodiscover v1) are the number one attack vector for credential stuffing and password spray attacks. These protocols send credentials in plaintext or using easily-cracked encoding and cannot be intercepted by Conditional Access MFA controls — the request is authenticated before CA can evaluate it.
Microsoft's position: Microsoft has deprecated Basic Authentication for Exchange Online. Legacy authentication must be explicitly blocked for all remaining paths.
Policy logic: If client app = Legacy authentication clients → Block
What this shows: The Conditional Access policy CA004 - Block - Legacy Authentication configured to target all users, all legacy authentication clients (Exchange ActiveSync and "Other clients"), with a Block grant control. The policy is being configured before being set to Report-Only.
What this shows: The Block Legacy Authentication policy in Report-only state — the first validation stage. Sign-in logs will now show which users and clients are still using legacy authentication. This is critical discovery: any user blocked at enforcement should be migrated to a modern client first.
What this shows: A second view of the Report-Only legacy authentication sign-in log entries showing legacy protocol breakdowns — for example, clients still using ActiveSync v14, Outlook for Mac (old), or on-premises mail clients. Each entry represents a user or device that will be blocked at enforcement.
Best practice: Run Report-Only for a minimum of 14 days and export the impacted user list. Reach out to each affected user, migrate them to Outlook (modern auth) or another supported client, and confirm the migration before enforcement.
What this shows: Validation testing of the Block Legacy Authentication policy. A legacy authentication connection attempt (for example, IMAP or Basic Auth SMTP) is shown being blocked after the policy was enforced. The error returned to the client is a standard authentication failure — no information is leaked about why the block occurred.
Validation command:
# Query Sign-in Logs for legacy auth attempts (post-enforcement)
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgAuditLogSignIn -Filter "clientAppUsed ne 'Browser' and clientAppUsed ne 'Mobile Apps and Desktop Clients'" |
Select-Object UserDisplayName, ClientAppUsed, Status, CreatedDateTime |
Where-Object { $_.Status.ErrorCode -eq 53003 }Error code 53003 confirms "Access has been blocked by Conditional Access policies" — the expected result for legacy auth attempts post-enforcement.
Objective: Define trusted network locations (IP ranges and countries) to use as conditions in Conditional Access policies — allowing different access requirements for on-premises vs. remote access scenarios.
Why this matters: Named Locations enable location-aware access policies. Organisations can allow seamless access from trusted corporate network IPs while requiring additional verification (MFA, compliant device) from unknown locations. Country-based locations provide geofencing capabilities to block access from high-risk regions.
Navigation: Entra ID → Security → Conditional Access → Named Locations
What this shows: The Named Locations blade showing the configured locations. Two types are visible: IP ranges (corporate office egress IPs marked as Trusted) and Countries (an allowlist of countries from which access is permitted). The "Trusted" flag is significant — it affects the isCompliantDevice evaluation and is used by Identity Protection to reduce risk scoring for sign-ins from these locations.
What this shows: The configuration of a specific trusted IP named location, showing the IPv4/CIDR range entries for the corporate network egress IP addresses. The Mark as trusted location checkbox is enabled — this tells Entra ID Protection that sign-ins from these IPs are expected and should not contribute to sign-in risk scores.
Best practice: Include only public-facing egress IPs, not internal RFC 1918 ranges. Use CIDR notation for IP ranges. Review and update named locations whenever corporate WAN IP addresses change (ISP changes, office relocations).
What this shows: The country-based Named Location configuration showing the countries from which user sign-ins are expected and permitted. Countries not in this list can be targeted by a separate Conditional Access policy to require step-up authentication or block access entirely.
Best practice: If your organisation operates in a defined set of countries, consider a "Block access from unknown countries" CA policy targeting "All users" and excluding known-good countries. This is a high-value, low-disruption control.
What this shows: A Conditional Access policy using Named Locations as a condition, in Report-only state. The policy evaluates sign-ins from outside trusted named locations and would apply additional controls (such as requiring MFA or a compliant device). Report-only mode reveals the volume and distribution of out-of-network sign-ins.
What this shows: The Named Locations-based CA policy in Enforced state. Users signing in from outside defined trusted IPs and countries are now subject to the additional access controls specified in the policy grant. The policy combines with the Baseline MFA policy to create a layered defence.
Objective: Configure the centralised Authentication Methods policy to define which MFA methods are available to users, moving away from the legacy per-user MFA settings.
Why this matters: The Authentication Methods policy provides a single pane of glass for controlling which authentication methods are available tenant-wide. It enables phishing-resistant methods (FIDO2, certificate-based authentication), controls method registration, and replaces the fragmented legacy MFA settings per user.
What this shows: The Microsoft Authenticator authentication method configuration showing push notification settings. Key configuration details visible: the method is Enabled, scoped to All users, with number matching and additional context enabled. Number matching is now required by Microsoft (rolled out as default) to prevent MFA fatigue attacks.
Best practice: Enable Number matching and Additional context (app name + location) on Microsoft Authenticator push notifications. This prevents MFA fatigue attacks where attackers spam push notifications hoping the user approves one inadvertently.
What this shows: SMS and voice call authentication method configuration. SMS is enabled as a fallback method, though it is explicitly less secure than app-based authentication due to SIM-swapping attacks and SS7 vulnerabilities.
Best practice: Treat SMS as a fallback method only — not as a primary MFA factor for privileged accounts. For admin roles, enforce phishing-resistant MFA (FIDO2 or certificate-based) through a separate Conditional Access policy scoped to the Directory roles condition.
What this shows: The full Authentication Methods policy overview showing all configured methods at a glance — Microsoft Authenticator (push + passwordless), SMS, Voice, FIDO2, and their enablement status. This centralised view is the replacement for the legacy Azure MFA Settings page.
What this shows: FIDO2 security key authentication method enabled in the tenant. FIDO2 is a phishing-resistant authenticator — it uses public/private key cryptography bound to the origin domain, making it immune to man-in-the-middle and phishing attacks. Enabled here for all users, with self-service registration permitted.
Best practice: Mandate FIDO2 or Windows Hello for Business for all accounts holding Entra ID directory roles (Global Admin, Security Admin, etc.). Configure a dedicated CA policy: CA - Require Phishing-Resistant MFA for Directory Roles.
What this shows: The Authentication Methods registration settings, including whether the combined registration experience is enabled and whether users can manage their own authentication methods. The combined registration experience (/mysecurityinfo) allows users to register MFA methods and SSPR in a single workflow.
What this shows: The final, validated state of all authentication methods after configuration — confirming that all intended methods are enabled, scoped correctly, and that deprecated methods (e.g., legacy per-user MFA, security questions) are disabled or excluded in favour of the centralised policy.
Objective: Eliminate standing privileged access by configuring Privileged Identity Management (PIM) for Entra ID directory roles. Administrators must request role activation with justification, MFA verification, and optional approval workflow.
Why this matters: Standing privileged access (permanent Global Admin assignment) is one of the most critical risks in any Microsoft 365 environment. If a Global Admin account is compromised, the attacker has unlimited access with no time constraint. PIM converts permanent assignments to eligible assignments — the role is not active until explicitly requested, creating a full audit trail and a narrow time window.
Zero Trust Principle: Least privilege access. Administrators should operate with user-level accounts for day-to-day tasks and activate privileged roles only when required, for a defined time period.
Navigation: Entra ID → Identity Governance → Privileged Identity Management → Entra ID Roles → [Role] → Assignments → Add Assignments
What this shows: The PIM assignment interface showing a user being added as Eligible (not Active) for an Entra ID role. The distinction is critical: Eligible = the user can request activation; Active = the user has the role right now. All privileged role assignments should be Eligible, not Active (with the exception of one break-glass account).
What this shows: The completed PIM role assignment showing the configuration — role assignment type (Eligible), assignment duration (time-bound or permanent eligibility), and the justification requirement. When the user activates the role, they must provide a business justification, complete MFA, and (optionally) receive approval from a designated approver.
Recommended PIM settings for Global Administrator:
- Activation requires MFA: Yes
- Activation requires justification: Yes
- Require approval: Yes (for production tenants)
- Maximum activation duration: 8 hours
- Assignment expiry: Annual renewal required
Best practice: Review PIM access reviews quarterly. Remove stale eligible assignments for users who have changed roles. Alert on role activation events in Microsoft Sentinel using the MicrosoftEntraId data connector.
Objective: Validate that Microsoft Entra ID Protection is active and feeding risk signals into the Conditional Access engine.
Why this matters: Identity Protection is the intelligence layer that makes risk-based Conditional Access possible. It processes over 30 trillion signals daily across the Microsoft ecosystem to detect compromised credentials, impossible travel, anonymous IP usage, malware-linked sign-ins, and other risk indicators. Without it, CA policies can only evaluate static conditions (location, device, app) — not behavioural anomalies.
What this shows: The Microsoft Entra ID Protection dashboard showing that Identity Protection is enabled by default in the tenant. The dashboard surfaces current Risky users, Risky sign-ins, and Risk detections. The risk signals from this blade feed directly into the Risk-Based Conditional Access policies configured in Phase 1.2.
Key Identity Protection features validated:
- Risk detection policies active (User Risk, Sign-in Risk)
- Risk signal flow confirmed to CA engine
- Investigation workflows available for Security Operations team
Monitoring best practice: Integrate Identity Protection alerts with Microsoft Sentinel via the Microsoft Entra ID Protection data connector. Create scheduled analytics rules to auto-close confirmed safe sign-ins and escalate high-risk events to the SOC.
All scripts use the Microsoft Graph PowerShell SDK (v2.x). Legacy AzureAD and MSOnline modules are deprecated and not used.
| Script | Purpose |
|---|---|
Get-MFAStatus.ps1 |
Export MFA registration status for all users |
Export-ConditionalAccessPolicies.ps1 |
Export all CA policies to JSON for backup/documentation |
New-NamedLocations.ps1 |
Bulk-create Named Locations from a CSV |
Get-PIMAssignments.ps1 |
Report all PIM eligible and active role assignments |
Each phase was validated against the following checklist before being considered complete:
- Security Defaults confirmed disabled
- Authentication Methods policy configured (Push + SMS + FIDO2)
- CA Policy created (All users → All cloud apps → Require MFA)
- Report-Only mode active — sign-in logs confirm policy evaluation
- MFA registration coverage reviewed (>95% required before enforcement)
- Policy switched to Enabled
- Test sign-in confirms MFA prompt triggered
- User Risk policy created (High risk → Password change + MFA)
- User Risk policy validated in Report-Only mode
- User Risk policy enforced
- Sign-in Risk policy created (Medium+ → MFA)
- Sign-in Risk policy validated in Report-Only mode
- Sign-in Risk policy enforced
- Legacy auth clients identified via Report-Only mode (14-day observation)
- Affected users migrated to modern authentication clients
- Block Legacy Auth policy enforced
- Test connection via legacy protocol confirmed blocked (error 53003)
- Corporate IP ranges added as Trusted Named Locations
- Country allowlist configured
- Named Locations CA policy validated in Report-Only mode
- Named Locations CA policy enforced
- Microsoft Authenticator (push + number matching + context) enabled
- SMS enabled as fallback
- FIDO2 enabled
- Legacy per-user MFA settings reviewed and superseded
- Combined registration experience confirmed active (
/mysecurityinfo)
- Administrator accounts converted from Active to Eligible assignments
- PIM activation requires MFA and justification
- Time-bound activation configured (≤8 hours)
- Approval workflow configured (recommended)
- Break-glass accounts excluded and documented
- Identity Protection dashboard accessible and displaying risk data
- Risk signals confirmed flowing to Conditional Access engine
- Risky Users and Risky Sign-ins reports reviewed
Every Entra ID tenant must have at least two emergency access (break-glass) accounts that are excluded from all Conditional Access policies and PIM. These accounts must be:
- Named clearly (e.g.,
breakglass1@yourdomain.onmicrosoft.com) - Use long, randomly generated passwords stored offline in a physical safe
- Excluded from all CA policies explicitly (by user exclusion, not group exclusion)
- Monitored by an alert that fires any time they are used (Azure Monitor alert)
- Tested quarterly to confirm they still work
| Risk | Mitigation |
|---|---|
| All admins locked out by a bad CA policy | Always test in Report-Only first; use break-glass accounts |
| Service accounts blocked by MFA policy | Exclude service accounts explicitly; use Workload Identity CA instead |
| Legacy apps broken by legacy auth block | Identify and migrate legacy clients before enforcement |
| Privileged access without PIM | Convert all directory role assignments to Eligible |
| MFA fatigue attacks | Enable number matching on Authenticator push notifications |
- Start broad (all users / all apps) and narrow down if exclusions are needed — not the reverse
- Regularly review policy exclusion lists; exclusions are the most common source of policy bypass
- Use Conditional Access Insights and Reporting to identify unused or conflicting policies
1. Always use Report-Only mode before enforcement
Every policy in this project was deployed in Report-Only mode first. This is non-negotiable in production. Even with thorough planning, unexpected legacy clients and service accounts will appear in the logs during the observation period.
2. MFA registration must precede enforcement
Enforcing MFA before users have registered causes immediate lockouts. Communicate the change, run registration campaigns via SSPR registration, and validate coverage before switching any policy to Enabled.
3. Named Locations must be maintained
Trusted IP configurations become stale when offices relocate, ISPs change, or new branch offices are added. Build a quarterly review process for Named Location IP ranges.
4. PIM activation alerts are valuable
Configure Microsoft Sentinel (or Azure Monitor) alerts on PIM role activation events. Any unexpected Global Admin activation outside business hours is a critical alert that warrants immediate investigation.
5. Number matching is a must
MFA fatigue attacks (push spam) are a real and common attack pattern post-credential compromise. Enabling number matching on Authenticator push notifications eliminates this attack vector with zero user friction increase.
6. Identity Protection risk scores improve over time
The risk engine learns your tenant's baseline over time. Initial false positives in risk-based CA policies are normal — mark confirmed-safe sign-ins and confirmed-compromised users accordingly to train the model.
This implementation delivers measurable security and operational improvements:
| Outcome | Impact |
|---|---|
| 99%+ reduction in account compromise risk | MFA blocks the vast majority of credential-based attacks |
| Eliminated standing privileged access | PIM reduces blast radius of admin account compromise to a time-bounded window |
| Legacy authentication blocked | Closes the primary vector for password spray and credential stuffing attacks |
| Risk-adaptive access | Compromised accounts are automatically challenged or blocked without human intervention |
| Compliance alignment | Supports NIST SP 800-207 (Zero Trust), ISO 27001 A.9, CIS Controls v8 (Control 6) |
| Audit-ready evidence | Full screenshot evidence at each phase satisfies internal audit and external audit requirements |
| Zero service disruption | Report-Only → Enforced pattern ensured no user lockouts during rollout |
- Compliant Device Requirement — Add
Require compliant deviceas a grant control for sensitive apps (requires Intune enrolment — see Project 2) - Phishing-Resistant MFA for Admins — Scope a dedicated CA policy requiring FIDO2/CBA for all directory role holders
- Token Protection — Evaluate Conditional Access token binding (preview) to prevent token theft/replay attacks
- Continuous Access Evaluation (CAE) — Validate CAE is active for supported apps to enable near-real-time policy enforcement on session revocation
- Workload Identity Policies — Extend Conditional Access to service principals and managed identities (requires Entra Workload Identity Premium)
- Cross-Tenant Access Policies — Configure inbound/outbound B2B collaboration trust settings
- Authentication Strengths — Migrate from simple "Require MFA" to Authentication Strength definitions for granular method control
A visual summary of all 30 implementation evidence screenshots across the 7 phases.
| Screenshot | Description |
|---|---|
|
Security Defaults Disabled |
|
Auth Methods Initial State |
|
Auth Methods Configured |
|
CA Policy — Report Only |
|
Pre-enforcement Login (No MFA) |
|
MFA Registration Status Report |
|
CA Policy Applied |
|
CA Policy Enforced |
| Screenshot | Description |
|---|---|
|
User Risk — Report Only |
|
User Risk — Enforced |
|
Sign-in Risk — Report Only |
|
Sign-in Risk — Enforced |
| Screenshot | Description |
|---|---|
|
Policy Configuration |
|
Report Only — View 1 |
|
Report Only — View 2 |
|
Enforcement Testing |
| Screenshot | Description |
|---|---|
|
Named Locations Overview |
|
Trusted IP Range |
|
Trusted Country Config |
|
CA Policy — Report Only |
|
CA Policy — Enforced |
| Screenshot | Description |
|---|---|
|
Authenticator Push |
|
SMS / Voice Config |
|
Methods Overview |
|
FIDO2 Security Keys |
|
Registration Settings |
|
Final Configuration |
| Screenshot | Description |
|---|---|
|
Add Eligible User |
|
Role Assignment Config |
| Screenshot | Description |
|---|---|
|
Identity Protection Active |
| Resource | Link |
|---|---|
| Microsoft Zero Trust Guidance | learn.microsoft.com/security/zero-trust |
| Conditional Access Overview | learn.microsoft.com/entra/identity/conditional-access |
| CA Policies Best Practices | learn.microsoft.com — CA Common Policies |
| Entra ID Protection | learn.microsoft.com/entra/id-protection |
| Authentication Methods | learn.microsoft.com — Auth Methods |
| Privileged Identity Management | learn.microsoft.com/entra/id-governance/privileged-identity-management |
| Block Legacy Authentication | learn.microsoft.com — Block Legacy Auth |
| Named Locations | learn.microsoft.com — Named Locations |
| Emergency Access Accounts | learn.microsoft.com — Break Glass |
| Microsoft Graph PowerShell SDK | learn.microsoft.com/powershell/microsoftgraph |
| NIST SP 800-207 Zero Trust | csrc.nist.gov/publications/detail/sp/800/207/final |
microsoft-entra-id conditional-access zero-trust mfa identity-protection privileged-identity-management microsoft-365 azure-ad cybersecurity fido2 named-locations graph-api powershell devsecops
Lokesh Karnam
Microsoft 365 & Azure Infrastructure Engineer
Celegence Systems
Part of the Microsoft 365 Infrastructure Portfolio — a series of enterprise-grade implementation projects demonstrating Zero Trust security architecture across Identity, Endpoint, Email, and SIEM.
Project 1 — Identity · Project 2 — Endpoint · Project 3 — Email Security · Project 4 — Vulnerability Management · Project 5 — SIEM · Project 6 — Identity Protection · Project 7 — Cloud Apps