Microsoft Entra ID: MFA, SSO, Conditional Access, and User Management Guide 2026

Multi-factor authentication is the single most impactful security control you can turn on in Microsoft Entra ID. I've seen environments get compromised through credential stuffing where every single affected account had no MFA. Don't let that be yours.

There are two paths: Security Defaults (the simple switch) and Conditional Access policies (the enterprise-grade approach). Security Defaults is a single toggle that enforces MFA registration for all users, requires MFA for admins on every sign-in, and blocks legacy authentication protocols. It's free and included with every Microsoft Entra tenant. To enable it, go to Identity > Overview > Properties, scroll to the bottom, and click Manage security defaults. Flip the toggle to Enabled and save.

If you're on Microsoft Entra ID P1 or P2, turn Security Defaults off and use Conditional Access instead, the two are mutually exclusive by design. The Conditional Access approach gives you far more control: you can require MFA only on risky sign-ins, exempt compliant devices, or scope the policy to specific apps. Go to Protection > Conditional Access > Policies > New policy.

Set Users to "All users" (you can exclude a break-glass admin account, more on that in the Advanced section). Set Target resources to "All cloud apps." Under Grant, select "Require multifactor authentication." Set the policy to Report-only mode first and run it for a week, check the sign-in logs to see who would have been affected. Then flip it to On.

After enabling MFA, users will be prompted to register their second factor at next sign-in. They'll see the combined registration screen at aka.ms/mfasetup where they can add the Microsoft Authenticator app, a phone number for SMS, or a FIDO2 hardware key. If a user says they never got the prompt, check whether they're excluded from the policy scope or whether their session token predates the policy activation, signing out and back in resolves it.

Single sign-on through Microsoft Entra ID means your users authenticate once and get access to all their business apps without re-entering credentials. Getting it wrong produces errors like AADSTS700082, AADSTS50011 (reply URL mismatch), or a blank redirect loop that deposits users back at the Microsoft sign-in page with no explanation.

Go to Applications > Enterprise applications and either browse the gallery for a pre-integrated app or click New application > Create your own application for a custom SAML or OIDC app. For gallery apps, most of the SAML configuration is pre-populated, but you still need to verify two things that almost always cause problems: the Reply URL (Assertion Consumer Service URL) and the Identifier (Entity ID). These must exactly match what the application vendor specifies in their SSO documentation. Even a trailing slash difference will produce error AADSTS50011.

Once the app is registered, click Single sign-on in the app's sidebar. For SAML, download the Federation Metadata XML and upload it into the application's admin console. For OIDC apps, copy the Application (client) ID and the tenant's OpenID Connect metadata document URL, which follows the format https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration.

After configuration, click Test on the SSO configuration page, Microsoft Entra ID will walk through the SAML exchange and flag exactly which assertion or claim is failing. If the test shows a missing claim, go to Attributes & Claims and add the required attribute. Common missing claims include employee_id, department, or a custom attribute the SaaS vendor requires for user provisioning. Don't forget to assign users or groups to the application under Users and groups, a user with no assignment will hit error AADSTS50105 even if SSO is configured perfectly.

Conditional Access is where Microsoft Entra ID earns its keep, and where most admins inadvertently lock people out on a Friday afternoon. I've been there. Let me save you the experience.

Conditional Access sits at Protection > Conditional Access. Every policy has the same anatomy: Assignments (who, what apps, what conditions) and Access controls (what to grant or block). The logic is: IF [user] accesses [app] under [conditions] THEN [require/block]. Policies are evaluated at sign-in time, and all matching policies are combined, if two policies both apply to a sign-in, the user must satisfy both grant controls.

The most common production configuration is a three-policy stack: (1) Require MFA for all users on all cloud apps, (2) Block access from legacy authentication protocols, and (3) Require a compliant or hybrid-joined device for access to sensitive apps. For policy (2), set the condition Client apps to check "Exchange ActiveSync clients" and "Other clients", these are the legacy protocols that don't support MFA and are exploited constantly. Set the grant to Block access.

For risk-based policies (requires Entra ID P2 and ID Protection), add a fourth policy: IF sign-in risk is Medium or High, THEN require MFA. Go to Conditions > Sign-in risk and select "Medium and above." This is the policy that catches credential stuffing attacks in real time, the attacker has the password but can't pass MFA, and the risky sign-in gets flagged automatically. Combined with Microsoft Entra ID Protection's automatic remediation, the user gets prompted to prove their identity before access is granted.

Always keep a break-glass admin account, a cloud-only Global Administrator account with a very long, randomly generated password stored in a physical safe, excluded from all Conditional Access policies. If your policies ever get misconfigured, this account is your recovery path. Name it something obvious like breakglass@yourdomain.onmicrosoft.com and monitor it with an alert in the sign-in logs.

User management in Microsoft Entra ID is more nuanced than it looks. Getting it wrong causes licensing waste, access gaps, and orphaned accounts that become security liabilities.

To create a new user, go to Identity > Users > All users > New user > Create new user. Fill in the User Principal Name (UPN), this is their sign-in address and must match a verified domain in your tenant. Set a strong temporary password and check Require this user to change their password when they first sign in. Under Properties, fill in the Job title, Department, and Manager fields, these are used by ID Governance automated access reviews and by Entra ID's dynamic group rules.

Dynamic groups are something every admin should know about. Instead of manually adding users to groups, you define a membership rule like (user.department -eq "Sales") and (user.accountEnabled -eq True) and the group populates automatically based on user attributes. Go to Identity > Groups > New group, set type to "Security" or "Microsoft 365," set membership type to Dynamic User, and click Add dynamic query. Dynamic groups update within minutes of an attribute change.

For bulk user creation, use the Bulk create option which accepts a CSV file. The template is downloadable from the bulk create wizard. Required columns are Name, User name, Initial password, and Block sign in (Yes/No). After upload, monitor the operation result under Bulk operation results, any row with an error code will tell you exactly what attribute was invalid.

When an employee leaves, don't just delete the account immediately. Go to their user profile, click Revoke sessions first, this invalidates all active tokens. Then disable the account by setting Block sign in to Yes. Wait 30 days for any data recovery or mailbox access needs, then delete. Deleted accounts stay in the recycle bin for 30 days and can be restored from Identity > Users > Deleted users. After 30 days they're gone for good along with their license assignment, so set a calendar reminder.

License assignment is where a lot of small and mid-size organizations get into trouble. They buy Microsoft Entra ID P2 licenses but only half the users get them applied, so ID Protection and ID Governance features behave inconsistently across the tenant. Here's the clean way to manage it.

Microsoft Entra supports two license assignment methods: direct (per-user) and group-based. Group-based licensing is the right approach for any organization with more than 20 users. Go to the group you want to license (or create one specifically for licensing purposes), click Licenses in the sidebar, then Assignments, and select the product. Every member of that group will receive the license. When you add a new employee to the group, the license is assigned automatically within minutes.

To check for license conflicts or assignment errors, go to Billing > Licenses > All products, click your product, then click Licensed users. Users with assignment errors appear with a warning icon. Click the user to see the specific error, common ones are "Not enough licenses" (you've run out of seats) or "Conflicting service plans" (two products in the same group have service plans that can't coexist).

For role assignment, the principle of least privilege applies hard here. Don't assign Global Administrator to people who only need to manage user accounts, give them User Administrator instead. For Conditional Access management, Conditional Access Administrator is the right scoped role. Go to Identity > Roles & admins > All roles and search for the role by name. Click it, then Add assignments. If you have Entra ID P2, use Privileged Identity Management (PIM) to make roles time-limited and require justification, this is accessed under Identity governance > Privileged Identity Management. With PIM, nobody holds a powerful role permanently; they activate it for a window of time and the activation is logged.

After assigning roles, verify them by switching to the user's perspective using the My Access portal at myaccess.microsoft.com. This shows what the user can actually see and access, a fast reality check before you tell them everything is set up.