Microsoft Entra ID: Tips, Tricks & Best Practices –

Each section below gives the rule, why it matters, and how to apply it in the Entra admin center (entra.microsoft.com). Features marked P1 need Entra ID P1 (included in Microsoft 365 E3 and Business Premium); P2 needs Entra ID P2 (included in Microsoft 365 E5). Tenants without P1 should at least turn on Security defaults, which enforces MFA registration and blocks legacy auth for free.

The roadmap below shows the recommended order of work. Each phase builds on the one before it, so resist jumping straight to advanced features.

[embed: node/efc96d9b-6297]

The checklist in section 9 breaks each phase into individual tasks.

1. Authentication and MFA

MFA for every user is the single highest-value control in Entra ID; the goal now is not just MFA, but phishing-resistant MFA. Microsoft already enforces MFA for its admin portals and, since October 1, 2025, for Azure CLI, PowerShell, IaC tools and SDKs (Microsoft Learn).

Rank your methods

Rules

• Manage methods in the Authentication methods policy. The legacy per-user MFA and SSPR method settings were retired in September 2025. Everything now lives under Entra ID → Authentication methods → Policies.
• Use Authentication strengths (P1). In Conditional Access, swap a plain “Require MFA” for “Phishing-resistant MFA” on admin roles and sensitive apps.
• Turn on Authenticator context. Number matching is enforced by default; also show the app name and geographic location so users can spot MFA-fatigue attacks.
• Enable the “Report suspicious activity” setting. Users who reject an unexpected prompt can flag it, which raises user risk in Identity Protection.
• Use Temporary Access Pass (TAP) for onboarding. New hires get a time-limited pass, then register a passkey on day one, with no password ever issued.
• Run a registration campaign. It nudges users who still rely on SMS to set up Authenticator during sign-in.

Block legacy authentication

Legacy protocols (POP, IMAP, SMTP AUTH, older Office clients) cannot do MFA, so they are the favourite target of password spray. Create one Conditional Access policy targeting all users, condition Client apps → Exchange ActiveSync clients + Other clients, grant Block. Check the sign-in logs filtered by Client app first, to find anything that would break.

Passwords

• Microsoft Entra Password Protection: add a custom banned list (company name, product names, city, sports teams). Deploy the on-prem agent to extend it to Active Directory in hybrid tenants.
• No forced periodic expiry. Set passwords to never expire and rely on risk detection and leaked-credential checks instead, per current NIST and Microsoft guidance.
• Self-service password reset (SSPR): enable for all users with two strong methods required. Combined registration lets users set up MFA and SSPR in one step.
• Smart lockout: keep the default (10 failed attempts) unless you have a specific reason; in hybrid setups, set it below your on-prem AD lockout threshold.

2. Conditional Access (P1)

Conditional Access is Entra ID’s policy engine: every sign-in is checked against all matching policies, and every grant control from every matching policy must be satisfied. A single Block wins over everything else.

[embed: node/0ed8ad4b-122c]

Policies don’t run in order and don’t override each other: all matching policies apply together, so an exclusion in one policy never cancels another policy’s requirement.

Design principles

• Default to All users and All resources, then exclude. Listing apps or groups one by one leaves new apps and new users unprotected.
• Exclude break-glass accounts from every policy, and nothing else by default. Every exclusion is a hole; document why it exists and review it quarterly.
• Prefer groups for exclusions (e.g. CA-Exclude-BreakGlass) and protect those groups with PIM or restricted management so nobody can quietly add themselves.
• Deploy in report-only mode first. Leave a new policy in report-only for one to two weeks and review the Conditional Access insights and reporting workbook before enforcing.
• Test with the What If tool for specific users, apps, locations and device states.
• One purpose per policy. Small, single-purpose policies are easier to troubleshoot than one huge policy with many conditions.

Naming convention

Use a predictable pattern: CA<number>-<Persona>-<App>-<Control>-<Condition>, for example CA001-AllUsers-AllApps-Block-LegacyAuth or CA104-Admins-AllApps-RequirePhishResistantMFA. Number ranges per persona (000s global, 100s admins, 200s internal users, 300s guests, 400s workload identities) keep the list readable at 40+ policies.

Baseline policy set

Microsoft’s built-in policy templates and the Microsoft-managed policies created automatically in many tenants cover several of these; review them rather than duplicating.

Advanced controls

• Continuous Access Evaluation (CAE): lets Exchange, SharePoint and Teams revoke sessions in near real time when a user is disabled, a password changes, or the IP location changes. Keep it on; use strict location enforcement for high-value users.
• Token protection: binds sign-in tokens to the device, defeating token replay on supported Windows clients. Start in report-only for a pilot group.
• Sign-in frequency: shorter sessions for admins and unmanaged devices; leave regular users on managed devices at the default rolling window to avoid MFA fatigue.
• Authentication context: step up MFA only for sensitive actions, such as opening a SharePoint site labelled Highly Confidential or activating a PIM role.

3. Privileged access

Admin accounts should hold no standing privilege: roles are least-privilege, activated just-in-time, and used from accounts that exist only in the cloud.

Least privilege

• Keep Global Administrators between two and four. Two guarantees you’re never locked out; more than five is a red flag.
• Use the narrowest built-in role that does the job:

• Scope with administrative units (P1). A regional helpdesk can reset passwords only for users in its own region.
• Use restricted management administrative units to protect sensitive accounts and groups (such as your CA exclusion groups) from tenant-level admins.
• Use role-assignable groups to assign roles to teams; only Privileged Role Administrators can change their membership.

Privileged Identity Management (P2)

PIM turns permanent admin rights into eligible ones. Recommended settings for high-impact roles (Global Admin, Privileged Role Admin, Security Admin, Exchange Admin):

[embed: node/7241758c-df4d]

• Maximum activation of 1 to 4 hours, with justification and a ticket number required.
• Approval required for Global Admin and Privileged Role Admin.
• Authentication context on activation, so it demands phishing-resistant MFA.
• Email alerts to a security mailbox on every activation.
• No permanent active assignments except break-glass accounts.
• PIM for Groups to put just-in-time access on groups that grant Azure or app permissions.

Admin account hygiene

• Separate accounts: jane@contoso.com for email and browsing; adm-jane@contoso.onmicrosoft.com for admin work, with no mailbox and no license.
• Cloud-only admins: never sync privileged accounts from on-prem AD. A compromised domain controller must not hand over the tenant.
• Privileged access workstations or at least a compliant, dedicated browser profile for admin sessions.

Break-glass (emergency access) accounts

• Create two cloud-only accounts on the .onmicrosoft.com domain, permanently assigned Global Administrator.
• Protect them with FIDO2 security keys (or certificate-based auth) stored in separate physical safes.
• Exclude them from every Conditional Access policy via a dedicated group.
• Alert on every sign-in (Log Analytics or Sentinel alert rule on the account object IDs).
• Test sign-in every 90 days and after any major CA change.

Access reviews (P2)

Run quarterly reviews of privileged role assignments, monthly reviews of guest access to sensitive groups, and set reviews to auto-remove access when a reviewer doesn’t respond.

4. Applications and workload identities

Apps and service principals are now a top attack path: an illicit consent grant or a leaked client secret gives an attacker persistent access that MFA never sees.

Consent

• Restrict user consent (Enterprise apps → Consent and permissions) to “Allow user consent for apps from verified publishers, for selected low-impact permissions”, or turn it off entirely.
• Enable the admin consent workflow so blocked users can request an app and named reviewers approve or deny it, instead of users finding workarounds.
• Disable users’ ability to register applications unless developers need it; give developers the Application Developer role instead.

Audit what already exists

• Review enterprise apps for high-risk Microsoft Graph application permissions: Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All.
• Look for apps with no owner, no sign-ins in 90 days, or credentials added recently by an unexpected user.
• Microsoft Defender for Cloud Apps app governance (if licensed) flags unusual app behaviour automatically.
• Set Assignment required on enterprise apps so only assigned users or groups can sign in.

Credentials

Assign at least two owners to every app registration, track credential expiry (an expired secret is a common outage cause), and use Conditional Access for workload identities (Workload ID premium) to restrict service principals to known IP ranges.

5. Hybrid identity

In a hybrid tenant, the sync server is a direct path from on-prem AD into the cloud, so it must be protected like a domain controller.

• Turn on Password Hash Sync (PHS), even if you sign in with pass-through authentication or federation. It powers leaked-credential detection in Identity Protection and is your fallback if on-prem infrastructure goes down.
• Treat Entra Connect Sync and Cloud Sync agents as Tier 0. Restrict who can log on to those servers, patch them promptly, and keep Entra Connect on a supported version (older builds stop syncing when they fall out of support).
• Consider Entra Cloud Sync for new or simpler deployments: lightweight agents, high availability with multiple agents, and configuration managed from the cloud.
• Migrate off AD FS where possible. Use staged rollout to move groups of users to cloud authentication (PHS or PTA) one at a time, then decommission AD FS. This removes a high-value target (token-signing certificates) and its servers.
• Don’t sync privileged on-prem accounts (Domain Admins, Enterprise Admins) to the cloud, and don’t give synced accounts cloud admin roles.
• Enable Seamless SSO only if you need it, and roll over its Kerberos decryption key (the AZUREADSSOACC computer account) at least every 30 days. Entra-joined or hybrid-joined Windows devices using PRT-based SSO usually make Seamless SSO unnecessary.
• Filter what you sync. Use OU or group filtering so service accounts, disabled objects and test users stay on-prem.

6. Guests and external collaboration

Guest access should be easy to grant and automatic to remove; most guest risk comes from accounts nobody remembers inviting.

External collaboration settings

Entra ID → External Identities → External collaboration settings:

• Guest user access: “Guest users have limited access to properties and memberships of directory objects” (or the most restrictive option).
• Guest invite settings: only users assigned to specific admin roles (or the Guest Inviter role) can invite, unless your business genuinely needs open invitations.
• Collaboration restrictions: allow-list partner domains if your collaboration is with a known set of organisations.
• Email one-time passcode: keep enabled so guests without a Microsoft account can still sign in, rather than falling back to unmanaged accounts.

Cross-tenant access settings

• Inbound trust: for trusted partners, accept their MFA and compliant-device claims so guests aren’t prompted twice.
• Outbound: restrict which external tenants your users can be guests in, if data leakage is a concern.
• Cross-tenant sync: for multi-tenant organisations (mergers, subsidiaries), sync users as members instead of inviting them manually.
• Tenant restrictions v2: blocks users signing in to unapproved tenants from your network or managed devices, closing an exfiltration route.

Lifecycle

• Use entitlement management access packages (P2) for partner access: guests request a package, a sponsor approves, access expires after a set period (e.g. 180 days).
• Run access reviews on all guests quarterly, with automatic removal of guests who are denied or not reviewed.
• Remove guests who haven’t signed in for 90 days or who never redeemed their invitation.

7. Monitoring, lifecycle and hygiene

You can’t investigate what you didn’t keep: built-in log retention is only 7 days (free) or 30 days (P1/P2), so export logs from day one.

Logging

• Diagnostic settings: send SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, AuditLogs, RiskyUsers and UserRiskEvents to a Log Analytics workspace or Microsoft Sentinel. Keep at least 90 days hot and a year or more in archive.
• Alert on high-value events: break-glass sign-in, Global Admin assignment outside PIM, new federated domain added, CA policy deleted or disabled, new credential added to a privileged app, and changes to authentication methods policy.
• Use the built-in workbooks: Sign-ins, Conditional Access insights, Authentication methods activity, and Legacy authentication sign-ins.

Posture

• Identity Secure Score (Protection → Identity Secure Score): review monthly; it’s effectively a prioritised to-do list, and each item links straight to the fix.
• Entra recommendations surface tenant-specific issues such as expiring credentials, unused apps and stale accounts.

Lifecycle and hygiene

• Joiner-mover-leaver automation: use HR-driven provisioning (Workday, SuccessFactors, or API-driven inbound) plus Lifecycle Workflows (Governance licence) to create accounts, issue TAPs, and remove access on leave dates.
• Stale accounts: use the signInActivity property to find users with no sign-in for 90 days; disable first, delete after a further 30 days.
• Stale devices: disable devices inactive for 90 days, delete after 180; never delete hybrid devices directly in the cloud, clean them up in on-prem AD.
• Dynamic groups (P1): drive licence assignment, app access and CA targeting from attributes like department or job title, so access follows the HR record. Validate rules before saving, because a typo can empty a group instantly.
• Group-based licensing (P1) instead of assigning licences per user.
• Naming and expiration policies for Microsoft 365 groups to stop sprawl.

8. Tips, tricks and snippets

Troubleshooting

• Sign-in log → Conditional Access tab shows every policy that applied, didn’t apply, or would have applied in report-only, and why. Start every “why was I blocked?” ticket here.
• Correlation ID and request ID from the user’s error page let you find the exact sign-in event instantly.
• Authentication details tab shows which MFA method was used, and whether MFA was satisfied by a token claim rather than a fresh prompt.
• Audit log filter “Initiated by” quickly answers “who changed this?”

Tools worth knowing

• Microsoft Graph PowerShell SDK (Microsoft.Graph) replaces the retired AzureAD and MSOnline modules. Update old scripts.
• Graph Explorer (aka.ms/ge) to test API calls in the browser before scripting them.
• Maester, an open-source PowerShell framework that tests your tenant against CISA, EIDSCA and other baselines, and can run in a pipeline.
• Microsoft Zero Trust assessment and CISA SCuBA (ScubaGear) for free, structured configuration reviews.
• My Sign-ins (mysignins.microsoft.com) for users to check their own recent activity and report anything odd.

Useful Graph PowerShell snippets

Connect with only the scopes you need:

Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","Policy.Read.All","RoleManagement.Read.Directory"

List members of the Global Administrator role:

$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id |
    ForEach-Object { Get-MgUser -UserId $_.Id -Property DisplayName,UserPrincipalName } |
    Select-Object DisplayName, UserPrincipalName

Find users with no sign-in for 90 days:

$cutoff = (Get-Date).AddDays(-90)
Get-MgUser -All -Property DisplayName,UserPrincipalName,SignInActivity,AccountEnabled |
    Where-Object { $_.AccountEnabled -and $_.SignInActivity.LastSignInDateTime -lt $cutoff } |
    Select-Object DisplayName, UserPrincipalName, @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}}

Export all Conditional Access policies with their state (good for change tracking and backup):

Get-MgIdentityConditionalAccessPolicy -All |
    Select-Object DisplayName, State, CreatedDateTime, ModifiedDateTime |
    Sort-Object DisplayName

Find app registrations with credentials expiring in the next 30 days:

$soon = (Get-Date).AddDays(30)
Get-MgApplication -All -Property DisplayName,PasswordCredentials,KeyCredentials |
    ForEach-Object {
        $app = $_
        @($app.PasswordCredentials) + @($app.KeyCredentials) |
            Where-Object { $_.EndDateTime -and $_.EndDateTime -lt $soon } |
            ForEach-Object { [pscustomobject]@{ App = $app.DisplayName; Expires = $_.EndDateTime } }
    }

Check which users still rely only on SMS or voice for MFA:

Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
    Where-Object { $_.MethodsRegistered -and -not ($_.MethodsRegistered -match 'microsoftAuthenticator|fido2|passKey|windowsHelloForBusiness') } |
    Select-Object UserPrincipalName, MethodsRegistered

Small wins

• Add company branding (logo, background, sign-in text) so users notice when a phishing page looks wrong.
• Hide the “Stay signed in?” prompt on shared devices via branding settings.
• Set Users can create security groups / Microsoft 365 groups to No if you want governed group creation.
• Restrict access to the Entra admin portal for non-admins (User settings → Restrict access to Microsoft Entra admin center). It’s a deterrent, not a security boundary, since APIs still work.

9. Quick-start checklist

Work top to bottom; tick items off as you go.

Week 1: Foundations

• Create two break-glass accounts with FIDO2 keys and sign-in alerts
• Export sign-in and audit logs to Log Analytics or Sentinel
• Block legacy authentication (report-only first)
• Require phishing-resistant MFA for all admin roles

Weeks 2 to 4: Users and admins

• Require MFA for all users via Conditional Access (or Security defaults without P1)
• Migrate MFA methods to the Authentication methods policy; start an Authenticator registration campaign
• Enable SSPR and Password Protection with a custom banned list
• Reduce Global Admins to two to four; move others to least-privilege roles
• Turn on PIM for all privileged roles (P2)

Month 2: Apps and devices

• Restrict user consent and enable the admin consent workflow
• Audit apps for high-risk permissions and expiring credentials
• Require compliant devices for sensitive apps
• Add risk-based Conditional Access policies (P2)

Month 3 and ongoing: Governance

• Lock down guest invitations and configure cross-tenant access
• Schedule access reviews for admins and guests
• Automate joiner-mover-leaver and stale-account cleanup
• Review Identity Secure Score monthly and run Maester or ScubaGear quarterly