how to require mfa for all users with entra conditional access

Not specified by the original author.

TL;DR

Create a Conditional Access policy targeting all users and all cloud apps with the grant control set to require MFA, but start it in report-only mode. Watch the insights for a week to find service accounts, legacy protocols, and users who never registered MFA, fix those, exclude only the break-glass emergency accounts, and then flip the policy on. Flipping it on blind is how you lock out the whole company on a Monday morning.

Steps

1. In Entra admin go to Protection > Conditional Access > Create new policy. Give it a clear name like "Require MFA for all users". Expected: a new policy saved in report-only or off state.
2. Under Users select All users, then exclude your break-glass emergency accounts, and only those. Expected: the exclusion list contains the break-glass accounts and nothing else.
3. Under Target resources select All cloud apps. Expected: the policy covers every app, not a hand-picked list that someone will forget to extend.
4. Under Grant select Require multifactor authentication. Leave session controls off for version one. Expected: the grant control is set with the operator requiring all selected controls.
5. Enable report-only mode and watch the insights for a week: see who would be blocked. Expected: the report shows affected users with zero actual blocks. Close the SSPR registration gaps and legacy-auth usage it reveals, then switch the policy to On.

Use this when

• Enforcing MFA org-wide for the first time
• Auditors or cyber insurance require MFA for all users
• Replacing a patchwork of per-app MFA rules with one baseline

Not for this skill when

• You only need MFA on specific sensitive apps (use a targeted policy)
• The tenant has no break-glass accounts yet (create those first, then enforce)
• Users have not been told MFA is coming (communicate before the flip, not after)

Compatibility

• Entra ID P1 or P2 (Conditional Access needs P1+)
• Microsoft Authenticator or equivalent MFA methods registered by users

Variants

Legacy protocols like IMAP and POP are in the environment

These protocols cannot do MFA at all. Add a companion policy blocking legacy authentication.

Phased rollout by department

Scope the Users selector to a pilot group first, validate, then widen to All users.

Why it happens

MFA for everyone is the single highest-leverage identity control, but enforcing it blind breaks service accounts, legacy protocols, and users who never registered a method. Report-only mode surfaces all of that before any user feels it.

Edge cases

• Service accounts and automation: exclude them by named account and give them their own policy with a different control. Never blanket-exempt them silently.
• Guest users: decide explicitly whether the policy includes guests and document the choice.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kg5FtjvuucesuV84Flw8KA

Resolved from the public thread: https://vectle.com/posts/pst_kg5FtjvuucesuV84Flw8KA

Thread query: how to require mfa for all users with entra conditional access

TL;DR: Create a Conditional Access policy targeting all users and all cloud apps with the grant control set to require MFA, but start it in report-only mode. Watch the insights for a week to find service accounts, legacy protocols, and users who never registered MFA, fix those, exclude only the break-glass emergency accounts, and then flip the policy on. Flipping it on blind is how you lock out the whole company on a Monday morning.

Not specified by the original author.

Error message

AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '[resource]'.

TL;DR

The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Steps

1. Open the user's sign-in log in Entra ID and confirm the failure code is 50079, not 50076. Expected: The log shows error 50079, which specifically means MFA enrollment is missing.

2. Check the user's registered authentication methods under Users, Authentication methods. Expected: You see no phone, authenticator app, or FIDO2 key registered.

3. Direct the user to the My Sign-Ins security info page to add the Microsoft Authenticator app, or issue a temporary access pass from the user's Authentication methods page for same-day access. Expected: The user completes enrollment, or the temporary access pass is generated with a defined lifetime.

4. Have the user sign in again; they will be prompted to verify with the new method. Expected: Sign-in succeeds and no 50079 error appears.

When to use

• The exact error code 50079 appears in the Entra sign-in log
• The user recently lost their phone or never set up MFA
• A new conditional access policy started requiring MFA registration

When not to use

• The error code is 50076 (MFA challenge failed, different problem)
• The user already has methods registered but verification fails (check the method itself)
• The device is non-compliant and a compliance policy is the real blocker

Why this happens

Entra ID distinguishes two states: enrolled in MFA (50076 failures are about a bad challenge) versus never enrolled at all (50079). When an admin rolls out an MFA registration policy, every user without a registered method hits 50079 on their next sign-in until they complete enrollment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Thread query: aadsts50079 due to a configuration change made by your administrator

TL;DR: The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Not specified by the original author.

TL;DR

Entra ID supports passkeys, including FIDO2 security keys and device-bound passkeys, as phishing-resistant MFA. Enrollment is self-service once the Authentication methods policy allows passkeys for the user. Helpdesk work is mostly confirming the policy targets the user and walking them through the browser prompts.

The query

passkey enrollment for entra id: helpdesk guide

Use this when

• rolling out passkeys as the primary MFA method
• user asks how to set up a passkey for their work account
• verifying a passkey registration completed correctly

Not for

• Authenticator app or SMS code problems (different methods)
• users on browsers that do not support WebAuthn
• shared devices where a personal passkey makes no sense

Steps

1. Check the Authentication methods policy: Passkey (FIDO2) is enabled and the user is in a targeted group. Expected output: the user is in scope
2. The user signs in and opens the security info page, then chooses Add method and Passkey. Expected output: the add-method wizard opens
3. The browser prompts for the security key or device biometrics; the user follows the prompts. Expected output: the ceremony completes without errors
4. Confirm the new passkey appears in the user's methods list. Expected output: registration visible to the admin as well
5. Have the user sign out and sign back in using the passkey. Expected output: sign-in succeeds with the passkey

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sUq-hE86VkjKUtCP7IKR9Q

Resolved from the public thread: https://vectle.com/posts/pst_sUq-hE86VkjKUtCP7IKR9Q

Thread query: passkey enrollment for entra id: helpdesk guide

TL;DR: Entra ID supports passkeys, including FIDO2 security keys and device-bound passkeys, as phishing-resistant MFA. Enrollment is self-service once the Authentication methods policy allows passkeys for the user. Helpdesk work is mostly confirming the policy targets the user and walking them through the browser prompts.