Microsoft Entra ID

Authentication and single sign-on

Entra ID authenticates users for Microsoft 365, Azure, and thousands of SaaS applications via SAML, OAuth 2.0, and OIDC federation. SSO means one sign-in session grants access to all integrated apps — users are not prompted per application once the Entra token is established.

Conditional Access enforcement

CA policies evaluate every sign-in attempt against conditions — user risk, device compliance state, location, application sensitivity — and grant, block, or require additional verification. CA is the primary enforcement layer for Zero Trust in Microsoft environments.

Device identity and management

Entra ID maintains device objects for every Entra-joined, hybrid-joined, and Entra-registered device. Device objects carry compliance state from Intune, BitLocker recovery keys, and group memberships used for CA policy evaluation and Intune group targeting.

Privileged access governance

Privileged Identity Management (P2) provides just-in-time role activation with approval workflows and time limits — replacing always-on Global Admin assignments. Combined with access reviews, PIM gives audit teams a defensible record of who had privileged access and when.

App registration and API access control

Enterprise applications and app registrations define how third-party and custom applications authenticate against the Microsoft identity platform. Permission scopes and admin consent control what each application can access — a misconfigured app registration is a common lateral movement path.

Identity governance and lifecycle

Entitlement Management (P2) automates access package assignment for new joiners, movers, and leavers. Access reviews periodically certify group and role membership. Lifecycle Workflows trigger automated tasks — provisioning, deprovisioning, manager notifications — based on HR events.

Report-only mode before enforcement

Every new CA policy should run in Report-only mode for at least two weeks before switching to On. Use the CA Insights and Reporting workbook in Entra > Monitoring to see which sign-ins would have been blocked — identify service accounts, break-glass accounts, and application service principals before the policy affects them.

Emergency access (break-glass) accounts

Emergency access accounts must be excluded from every CA policy — including MFA and device compliance requirements. These accounts exist to recover the tenant if all other admin access is lost. Store the credentials offline, configure alerts for any sign-in from these accounts, and test them quarterly.

Require compliant device grant

"Require device to be marked as compliant" uses Intune compliance state. It only works for Intune-managed devices — it will block Entra-registered BYOD devices that have never enrolled in MDM. Scope the policy to Microsoft 365 apps and exclude device platforms you are not yet managing.

Named locations and trusted networks

Define office IP ranges as Trusted Named Locations in Entra > Security > Named locations. CA policies can then use "Any location except trusted" as the condition — requiring MFA or compliant device from any network that is not an approved office location without blocking office-based users.

Sign-in frequency and session controls

Session controls set how long a token is valid before re-authentication is required. Set sign-in frequency to 1 hour for high-sensitivity apps (Entra admin portal, Exchange admin). Persistent browser session: Never for shared or kiosk devices. Continuous Access Evaluation (CAE) revokes tokens in near-real-time on policy changes.

Authentication strengths

Authentication strength CA policies require a specific authenticator type — phishing-resistant (hardware key or Windows Hello for Business) rather than any MFA. Require phishing-resistant MFA for any access to the Entra admin portal, Azure, and other privileged surfaces. This resists MFA fatigue and adversary-in-the-middle attacks that standard TOTP does not.

Eligible vs Active role assignments

Eligible assignments give a user the ability to activate a role — they do not have it permanently. Active assignments grant the role continuously (avoid except for break-glass and automation service principals). Audit your directory for permanent Active assignments as a first step when enabling PIM.

Role activation settings

Configure per-role: maximum activation duration (recommend 1–4 hours for admin roles), require MFA or phishing-resistant MFA on activation, require justification text, require approval from one or more designated approvers. For highly sensitive roles (Global Admin, Privileged Role Admin), require approval from a second named person.

Approval workflows

Designated approvers receive an email and Teams notification when activation is requested. Approvers review the justification and approve or deny via the PIM portal or the MyAccess portal. Set approval timeout to 4–8 hours so requests do not pend indefinitely — unapproved requests expire automatically.

PIM for Groups

PIM can manage membership in Entra ID security groups, not just directory roles. Use this to provide JIT access to groups that are used for CA policy exclusions, Intune assignment targets, or SharePoint permissions — without granting a permanent directory role. Requires P2 and the group to be a role-assignable group.

Access Reviews for privileged roles

Configure recurring access reviews for all PIM-eligible role assignments — quarterly is the standard frequency for admin roles. Reviews are sent to the role member, their manager, or a designated reviewer. Memberships that are not reviewed or approved within the review window are automatically removed if you configure auto-removal on deny.

PIM alerts and audit log

PIM generates built-in alerts for: roles with too many permanent admins, roles not using PIM, duplicate role assignments, and stale eligible assignments. The PIM audit log records every activation, approval, denial, and assignment change — export to Log Analytics for retention beyond the default 30-day portal view.

Finding a device object in Entra

Entra ID > Devices > All devices. Filter by device name, operating system, join type, or compliance state. The device detail page shows join type, registration time, last activity, Intune management state, and the Recovery Keys tab for BitLocker keys. Use Get-MgDevice -Filter "displayName eq 'DEVICE-NAME'" for scripted lookups.

BitLocker recovery key location

For Entra-joined and hybrid-joined devices with BitLocker policy configured to escrow to Entra: Devices > [device name] > Recovery Keys tab shows the key ID and the recovery key itself (visible to users with sufficient RBAC). If Recovery Keys tab is empty, the key has not escrowed — see the BitLocker troubleshooting guide for the force-escrow procedure.

Stale device objects

Devices that have been re-imaged, renamed, or re-enrolled create new Entra device objects. The old object retains its last compliance state and may hold a now-invalid BitLocker key or group membership. Identify stale objects using Get-StaleDevices — cross-referencing Intune last check-in with Entra last activity date. Delete stale objects after confirming the current device object is healthy.

Device registration certificate renewal

Hybrid-joined devices register a device certificate in Entra ID that is renewed automatically by the Automatic-Device-Join scheduled task. If the renewal fails (Entra Connect sync issue, certificate store problem, or network access to sts.windows.net blocked), the device will eventually fail CA device-based checks. Run dsregcmd /status on the device to verify AzureAdJoined state and certificate validity.

dsregcmd — the first diagnostic tool

dsregcmd /status on any Windows machine shows join type (AzureAdJoined, DomainJoined, WorkplaceJoined), the device certificate thumbprint, SSO state, and whether the PRT (Primary Refresh Token) is present. A missing PRT is why a device cannot satisfy device-based CA controls even if it appears joined. Run as the affected user — PRT is user-scoped.

Compliance state propagation delay

Intune marks a device compliant, but Entra ID still shows it as non-compliant. Compliance state syncs from Intune to the Entra device object within minutes under normal conditions. Trigger a manual device sync in Intune (Devices > [device] > Sync), then wait 5–10 minutes before re-testing CA. If the state does not update, check the Intune device configuration status and the Entra Connect sync health.