Entra ID and Conditional Access

10 min read

Entra ID (formerly Azure AD) is the identity perimeter for M365 and Azure. This guide covers Conditional Access policy design, MFA enforcement patterns, app registration hygiene, and Privileged Identity Management configuration.

Conditional Access Baseline

A minimum Conditional Access deployment should cover these policy areas. Each policy targets a specific access scenario and should be deployed in report-only mode before enforcement.

Require MFA for all users Target: All users, exclude break-glass. Grant: Require MFA.

Block legacy authentication Target: All users, all apps. Condition: Client apps = Other, Exchange ActiveSync. Grant: Block.

Require MFA for admin roles Target: Directory roles (Global Admin, Exchange Admin, etc). Grant: Require MFA + compliant device.

Block access from untrusted locations Target: All users. Condition: Exclude named locations. Grant: Block or require MFA.

Break-Glass Accounts

At least two break-glass accounts should exist. These are emergency-access accounts excluded from Conditional Access policies. They should use long, random passwords stored in a physical safe, have no MFA (by design), and be monitored via sign-in log alerts.

Break-glass accounts must be excluded from all Conditional Access policies. If MFA is enforced universally without exclusion, you risk permanent lockout during identity provider outages.

App Registration Hygiene

Audit app registrations quarterly. Look for apps with excessive permissions (Directory.ReadWrite.All, Mail.ReadWrite), expired client secrets, and apps created by users who have since left. Remove or rotate as needed.

Privileged Identity Management

PIM makes privileged role assignments time-bound and approval-gated. Instead of permanent Global Admin, users activate the role for a set duration when needed. This reduces standing privilege exposure.