Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error AADSTS50076

AADSTS50076 and AADSTS50079: multi-factor authentication has not been met

10 min read Updated October 4, 2026 Microsoft 365 & Entra ID

Fix it now

Entra ID wants a second factor for this sign-in and the session has not supplied one. AADSTS50076 means the user has a method and has not used it; AADSTS50079 means there is nothing registered to answer with, so the sign-in is being diverted into registration. Both are interrupts, not failures.

  1. Have the user complete the prompt with the method they registered, normally an approval in the Microsoft Authenticator app.
  2. If they have never registered, send them to the security info page in My Account from a browser where they can sign in, and have them add a method.
  3. If they cannot get far enough to register, add or reset methods for them from Entra ID, Users, the user, Authentication methods, or issue a Temporary Access Pass if that method is enabled in your tenant.
  4. Check where the demand comes from before you change anything: Entra ID, Overview, Properties, Manage security defaults on a free tenant, or Entra ID, Conditional Access where you hold Premium licences.
  5. If a script or service account is hitting this, do not try to bypass the requirement. Move that workload to application-only authentication with a certificate.

Since 29 July 2024 security defaults no longer give users a 14-day grace period to register. New starters need a method before their first real sign-in, not after it.

If the user completes the challenge and the sign-in continues, you are done. If the prompt keeps returning, or registration itself is blocked, the next section separates the three mechanisms that can demand a factor.

Why it happens

Three different mechanisms can demand a second factor and they behave differently. Security defaults apply one fixed set of requirements to the whole tenant and cannot be narrowed. A Conditional Access policy applies whatever you specify to whichever users, applications and conditions you choose. Legacy per-user multifactor settings, held on the account itself, are the oldest of the three and the usual explanation for prompts that match no policy you can find.

Whichever mechanism demands it, the outcome is the same: the token has to carry evidence that a second factor was satisfied. Microsoft documents AADSTS50076 as the user needing to use multifactor authentication because of a configuration change such as a Conditional Access policy, per-user enforcement, or a move to a new location. AADSTS50074 is documented as strong authentication being required and the user not passing the challenge, and AADSTS50078 as the presented multifactor authentication having expired under policies configured by the administrator – the factor was satisfied, just longer ago than the policy now accepts.

AADSTS50079 and AADSTS50072 are registration interrupts rather than authentication failures. Microsoft documents 50079 as a managed user needing to register security info, or a federated user needing to get the multifactor claim from their identity provider, and 50072 as the user needing to enrol for second factor authentication interactively. That registration path can itself be blocked, either because the authentication methods policy leaves the user nothing usable, or because a policy restricts where registration may happen.

The user has never registered a second factor

You have this one if AADSTS50079 or AADSTS50072, and the Authentication methods page for that user is empty.

  1. Send the user to the security info page and have them add the Microsoft Authenticator app.
  2. Confirm the methods you expect people to use are actually enabled for them in the authentication methods policy.
  3. For new starters, register during onboarding rather than leaving it to the first blocked sign-in – the old 14-day grace period under security defaults no longer exists.

The registered method is no longer available

You have this one if The user has a method listed, and it points at a lost, wiped or replaced phone.

  1. Verify the person’s identity through a channel that does not depend on the account itself.
  2. Remove the stale method from Entra ID, Users, the user, Authentication methods.
  3. Issue a Temporary Access Pass, if enabled, so they can sign in once and register a new device.
  4. Confirm the old entry is gone once the replacement is registered.

Help-desk method resets are a favourite target for social engineering. Insist on out-of-band identity verification every time, with no exception for senior staff.

The existing factor is considered too old

You have this one if AADSTS50078, on a session that was working earlier the same day.

  1. Have the user complete the challenge again; this is the policy working, not a fault.
  2. If it recurs more often than intended, review the sign-in frequency on the policy that applies.
  3. Scope short intervals to the applications that need them rather than applying one aggressive value everywhere.

A shared or service account is being used interactively

You have this one if An integration, a scheduled job or a shared mailbox account cannot complete a prompt nobody is there to answer.

  1. Register the workload as its own application and use application-only authentication with a certificate.
  2. For a shared mailbox, remove the sign-in credentials entirely and grant delegated access to named people.
  3. Do not exclude a human account from the requirement to make an integration work.

Legacy per-user settings and policy are both in play

You have this one if Prompts that correspond to no policy you wrote, usually on a handful of long-standing accounts.

  1. Check whether those accounts are enabled or enforced in the legacy per-user multifactor settings.
  2. Decide on one source of truth, move the requirement there, and clear the legacy state.
  3. Test with one account and record what the previous state was before changing the rest.

Full reference

Reading the prompt pattern

What the user reports Where to look
Prompted on every sign-in from one device The browser is discarding the session, or the device is not registered
Prompted at a regular interval A sign-in frequency session control
Cannot get past the setup screen No usable method is enabled, or registration is restricted by policy
Only prompted away from the office A location condition or a trusted network exclusion
A script or integration cannot pass it An interactive requirement applied to a non-interactive flow
Prompted after changing phone The registered method no longer exists on the new device

What security defaults actually enforce

  • All users must register for multifactor authentication, with no grace period since 29 July 2024.
  • Administrators in the roles Microsoft lists must complete multifactor authentication.
  • Users must complete it when Microsoft’s own evaluation decides it is necessary.
  • Legacy authentication protocols are blocked, including Exchange ActiveSync basic authentication.
  • Privileged activity in the Azure portal, the Microsoft Entra admin center, Azure PowerShell and Azure CLI is protected.
  • Device code flow is blocked for new tenants from 1 July 2026.

Security defaults are enabled automatically on tenants created on or after 22 October 2019, with a 24-hour grace period before enforcement, and can be turned on for existing tenants that have no Conditional Access policies, no premium licences and no active legacy authentication clients. The one documented exclusion is the directory synchronisation account used by Entra Connect and cloud sync. Everything else in the tenant is in scope, and there is no way to scope it further.

Codes in this family, in the order they bite

Code Stage What to do
AADSTS50079 Registration required Register a method, or issue a Temporary Access Pass
AADSTS50072 Registration interrupt, interactive Complete the enrolment the sign-in has diverted to
AADSTS50076 Factor required, not supplied Complete the challenge with a registered method
AADSTS50074 Challenge presented, not passed Retry; check the method still works on the device
AADSTS50078 Factor satisfied, but stale Complete a fresh challenge; review sign-in frequency

When you cannot move the requirement

  • Do not answer a service-account prompt by excluding a human account from the policy. It looks like it worked and it silently removes a control from a person.
  • Where a device cannot support modern authentication, give it its own narrow account and scope any exception to that account alone.
  • Where the requirement comes from security defaults and you need one exception, the honest answer is that security defaults cannot make exceptions and Conditional Access is the mechanism that can.
  • Record any exception you do make, with a date to review it, because these are exactly the entries nobody can explain two years later.

When a licence is the actual fix

Requiring multifactor authentication costs nothing. Security defaults are available to every tenant and will require it for everyone, which for a small organisation with no unusual cases is a sound answer. What security defaults cannot do is make exceptions: no per-application targeting, no trusted locations, no exclusion for a break-glass account, no control over how often people are challenged. Those are Conditional Access capabilities, and Microsoft documents Conditional Access as requiring Microsoft Entra ID P1 for the users in scope, while noting that Microsoft 365 Business Premium customers can use Conditional Access features as well. Treat P1 as one legitimate route rather than the only one, and check what you already hold first. Arco can confirm what your subscription covers and supply P1 seats where the gap is real.

Every code this article covers

Code What it points at Source
AADSTS50076 Because of a configuration change such as a Conditional Access policy, per-user enforcement, or a move to a new location, the user must use multifactor authentication to reach the resource Microsoft Learn
AADSTS50079 Multifactor authentication is required and a managed user must register security info, or a federated user must obtain the multifactor claim from their identity provider Microsoft Learn
AADSTS50074 Strong authentication is required and the user did not pass the multifactor challenge Microsoft Learn
AADSTS50072 The user needs to enrol for second factor authentication, interactively Microsoft Learn
AADSTS50078 The presented multifactor authentication has expired under policies configured by the administrator, and must be refreshed Microsoft Learn

Confirm the fix worked

  1. The user’s Authentication methods page lists at least one method they actually hold.
  2. The user completes a full sign-in and the sign-in record shows the second factor as satisfied in the authentication details.
  3. A second sign-in inside the expected window completes without another challenge.
  4. Any method belonging to a previous device has been removed from the account.

Questions people ask about this

Can I exclude one user from multifactor authentication?

Not with security defaults, which apply to everyone. Exclusions are a Conditional Access capability and Microsoft documents Conditional Access as needing Entra ID P1 for the users in scope. If your only requirement is excluding a break-glass account, that alone is a reasonable case for Premium.

Is there still a grace period for registration?

No. Microsoft removed the 14-day registration grace period for security defaults on 29 July 2024, for new and existing tenants, to reduce the risk of account compromise. Plan registration into onboarding.

Why is one user prompted several times a day?

Usually a session that is not being retained: a browser clearing cookies on exit, a device that is not registered, or a sign-in frequency applied more widely than intended. Check the device and browser before assuming the policy is wrong.

Does multifactor authentication cost extra?

Not by itself. Security defaults provide it to every tenant. You pay only when you need control over who is challenged, for what, and how often.

What about clients that cannot do modern authentication?

Security defaults block legacy authentication protocols outright, including Exchange ActiveSync basic authentication. The supported answer is to move the client onto modern authentication rather than to keep an old credential path alive for it.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix 403 FORBIDDEN and Access Denied in SharePoint Online and OneDrive License Error AADSTS50126, 50053 and 50137: sign-in rejected on password, lockout or a forced change Free Fix LargeObject and ExceededAllowedLength: Entra ID rejects an oversized object License Error AADSTS53000 and AADSTS53002: device not compliant or app not approved
← Back to Knowledge Base