We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft security
  3. Authentication strengths
Conditional Access authentication strengths, UAE

Requiring MFA treats a text message and a FIDO2 key as the same thing. Authentication strengths do not.

An authentication strength specifies which combinations of methods can be used for a given resource, so your finance system can demand phishing-resistant sign-in while the intranet accepts a push notification. It is one grant control and it changes how granular your access policy can be.

Book an authentication strength reviewSee the method mapping
Conditional Access authentication strengths for UAE organisations
  • 3 built inMFA, passwordless MFA, phishing-resistant MFA
  • 3 methodsSatisfy the phishing-resistant strength
  • Entra ID P1Licence prerequisite for Conditional Access
  • Per resourceDifferent strengths for different applications
What authentication strengths do

Eight things that determine whether this lands cleanly.

The control is simple to configure and easy to deploy in a way that locks people out or, worse, that appears to be enforcing something it is not. Most of the difficulty is in the documented limitations rather than in the concept.

Different requirements for different resources

An authentication strength specifies which combinations of authentication methods users can use to access a resource, and users satisfy it with any of the allowed combinations. That is what lets a sensitive application require phishing-resistant methods while everything else accepts a weaker but workable combination.

The three built-in strengths

Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength. Built-in strengths are always available and cannot be modified, and Microsoft updates them when new methods become available, which means their definitions move without you doing anything.

Exactly what satisfies phishing resistance

Three combinations: Windows Hello for Business or platform credential, FIDO2 security key, and Microsoft Entra certificate-based authentication in its multifactor form. Notably, Microsoft Authenticator phone sign-in satisfies MFA and passwordless strengths but not the phishing-resistant one.

What satisfies nothing at all

Certificate-based authentication in single-factor form, SMS sign-in, password alone, federated single-factor, and QR code satisfy none of the three built-in strengths. Estates that have quietly been relying on one of these for a sensitive application find that out when the policy goes on.

It does not restrict the initial authentication

The limitation people misread most. Conditional Access policies are evaluated only after the initial authentication, so an authentication strength does not restrict it. A user can still enter a password, and then must sign in with a phishing-resistant method before they can continue.

It cannot be combined with Require multifactor authentication

You cannot use the Require multifactor authentication and Require authentication strength grant controls together in the same Conditional Access policy, because the built-in Multifactor authentication strength is equivalent to the Require multifactor authentication control. Migration means replacing, not layering.

Guests, and one method that is not supported

Requiring specific methods from guest users accessing a resource tenant is a documented scenario, used in combination with cross-tenant settings. The constraint to know is that the Email one-time pass for guests is not currently supported in the available combinations, which affects how partner access is designed.

How it interacts with sign-in frequency

Microsoft records a known issue worth understanding before you rely on both. When a resource requires an authentication strength and a sign-in frequency, users can satisfy the two requirements at different times, so a passkey sign-in from yesterday plus a device unlock today can be sufficient.

The behaviour that generates tickets

If a user signs in with a password first, they are not prompted for Windows Hello. They have to start again.

Microsoft documents this precisely, and it is the single most common source of confusion when a phishing-resistant strength goes live.

  • If the user signs in with Windows Hello for Business as the primary authentication method, it satisfies a strength that includes Windows Hello for Business. If they sign in with another method such as a password, and the strength requires Windows Hello for Business, they are not prompted for it.
  • Instead the user needs to restart the session, select Sign-in options, and choose a method the authentication strength requires. From the user perspective this reads as being blocked with no route forward, and the route forward is not obvious unless somebody told them.
  • The related point is that authentication strengths do not restrict the initial authentication at all, because Conditional Access policies are evaluated only after it. A password can still be entered. The strength governs what has to happen before access continues, not what the user may type first.
  • The mitigation is entirely communication and sequencing: register the required methods before the policy applies, tell people what the Sign-in options route looks like, and pilot with a group that will report friction rather than work around it silently.
Ask us to plan the rollout sequence
How we approach it

Four things that stop this becoming a lockout incident.

The control is straightforward. Nearly all the difficulty comes from enforcing a method requirement before the methods are registered, and from a user experience that does not prompt for the thing it requires.

We measure registration before writing policy

Only FIDO2 security keys, Windows Hello for Business or platform credential, and multifactor certificate-based authentication satisfy the phishing-resistant strength. If those are not registered, the policy is a lockout with extra steps. Registration coverage is the number that decides the timeline.

We brief people on the Sign-in options route

Where a user signs in with a password and the strength requires Windows Hello for Business, they are not prompted for it. They must restart the session, select Sign-in options, and choose a qualifying method. Users who have not been told this experience it as being blocked with no way forward.

We replace the old grant control rather than stacking

Require multifactor authentication and Require authentication strength cannot be used together in the same policy, because the built-in MFA strength is equivalent to the older control. Migration is a replacement, and policies that try to carry both simply do not save.

We design guest access around what is supported

Requiring specific methods from guests accessing your tenant is a documented scenario used with cross-tenant settings. The constraint that shapes the design is that Email one-time pass for guests is not currently supported in the available combinations, which rules out a common partner onboarding pattern.

How a rollout runs

Four phases across roughly four to six weeks.

The configuration takes an hour. Getting the required methods registered on enough devices, and sequencing the policy so nobody is locked out, is the rest of it.
  1. 01
    Week 1

    Establish what people can currently satisfy

    Which methods are registered across the population, and therefore which strengths each group could satisfy today. Estates relying on SMS or password plus push discover immediately that a phishing-resistant strength is a registration project rather than a policy change.

    • Registered method inventory across the user base
    • Groups mapped to the strength they can satisfy today
    • Authentication methods policy reviewed for scoping
    • Gap between current and target strength quantified
  2. 02
    Weeks 2 to 3

    Register the methods before the policy exists

    Registration first, enforcement second, always in that order. Temporary Access Pass is useful here, and worth noting it satisfies MFA strength only, not passwordless or phishing-resistant, so it cannot be the fallback for a phishing-resistant policy.

    • Required methods registered for the pilot population
    • Temporary Access Pass process defined for onboarding
    • Break glass account handling confirmed
    • Registration coverage measured before enforcement
  3. 03
    Week 4

    Apply to a pilot resource with the right grant control

    The policy created with Require authentication strength, replacing rather than joining Require multifactor authentication, since the two cannot be used together. Applied to one sensitive application first, with a group that will report friction.

    • Policy created with the correct grant control
    • Legacy Require MFA control retired on that policy
    • Applied to one sensitive resource for pilot
    • User guidance issued covering the Sign-in options route
  4. 04
    Weeks 5 to 6

    Broaden, and handle guests deliberately

    Extension to further resources by sensitivity rather than all at once. Guest access designed with cross-tenant settings in mind, and with the knowledge that Email one-time pass for guests is not supported in the available combinations.

    • Strengths assigned per resource by sensitivity
    • Guest access approach designed and documented
    • Sign-in frequency interaction understood and recorded
    • Support guidance handed to the service desk
Where this applies

Six situations where one MFA requirement is not enough.

The pattern is always the same: an organisation with MFA everywhere discovers that everywhere includes methods it would not accept for its most sensitive systems.

A regulated firm protecting a payments or trading system

Where one application carries materially more risk than the rest, a single tenant-wide MFA requirement is the wrong shape. A phishing-resistant strength on that resource, with a weaker strength elsewhere, expresses the actual risk position rather than averaging it.

A business that has been phished despite having MFA

Push notification and one-time code MFA are defeated by adversary in the middle attacks, which is precisely why Microsoft Authenticator phone sign-in satisfies the MFA and passwordless strengths but not the phishing-resistant one. Moving the sensitive resources onto that strength is the direct response.

An organisation with a small high-privilege population

Rolling FIDO2 keys to everyone is a project. Rolling them to administrators and finance approvers is a week. Authentication strengths let the stronger requirement apply only where the keys exist, which is what makes a staged programme possible instead of all or nothing.

A company giving partners access to a shared workspace

Requiring specific methods from guest users accessing your tenant is a supported scenario in combination with cross-tenant settings. The design constraint is that Email one-time pass for guests is not currently supported in the combinations, so partner onboarding needs a different path.

A provider protecting a clinical records system specifically

Where one system holds the sensitive data and the rest of the estate does not, applying the strongest requirement only there keeps the control proportionate. It also makes the control explainable, which matters when somebody asks why access to that system works differently.

A business protecting an action rather than an application

Requiring a specific method when a user takes a sensitive action within an application, in combination with Conditional Access authentication context, is a documented scenario. That is how you require a hardware key to approve a payment without requiring one to open the application.

Three positions

How UAE organisations express access requirements.

The middle column is the most common and it is where a genuine security gap hides, because an SMS code and a hardware key both satisfy it and only one of them resists phishing.
Method quality distinguished
Strengths per resourceYes
Require MFA everywhereNo
MFA for some applicationsNo
Sensitive resources treated differently
Strengths per resourceYes
Require MFA everywhereNo
MFA for some applicationsPartly
Phishing-resistant enforceable
Strengths per resourceYes
Require MFA everywhereNo
MFA for some applicationsNo
Weak methods excluded where needed
Strengths per resourceYes
Require MFA everywhereNo
MFA for some applicationsNo
Guest access differentiated
Strengths per resourceWith cross-tenant settings
Require MFA everywhereNo
MFA for some applicationsNo
Registration measured before enforcement
Strengths per resourceYes
Require MFA everywhereSometimes
MFA for some applicationsNo
Works with authentication context
Strengths per resourceYes
Require MFA everywhereNot applicable
MFA for some applicationsNo
Definition updated as methods evolve
Strengths per resourceBuilt-ins update automatically
Require MFA everywhereStatic
MFA for some applicationsStatic
Lockout risk at enforcement
Strengths per resourceManaged
Require MFA everywhereLow
MFA for some applicationsLow
Defensible to an auditor
Strengths per resourceYes, per resource
Require MFA everywherePartly
MFA for some applicationsNo
Feature
Strengths per resource
Require MFA everywhere
MFA for some applications
Method quality distinguished
YesNoNo
Sensitive resources treated differently
YesNoPartly
Phishing-resistant enforceable
YesNoNo
Weak methods excluded where needed
YesNoNo
Guest access differentiated
With cross-tenant settingsNoNo
Registration measured before enforcement
YesSometimesNo
Works with authentication context
YesNot applicableNo
Definition updated as methods evolve
Built-ins update automaticallyStaticStatic
Lockout risk at enforcement
ManagedLowLow
Defensible to an auditor
Yes, per resourcePartlyNo
The mapping that decides everything

Which methods satisfy which built-in strength.

Taken from the published combination table. Reading it before writing policy prevents the two classic mistakes: assuming Authenticator counts as phishing resistant, and assuming SMS counts as anything.
Authentication method combinationMFAPasswordless MFAPhishing-resistant MFA
FIDO2 security keyYesYesYes
Windows Hello for Business or platform credentialYesYesYes
Certificate-based authentication, multifactorYesYesYes
Microsoft Authenticator, phone sign-inYesYesNo
Temporary Access Pass, one-time and multiple useYesNoNo
Password plus something the user hasYesNoNo
Federated single-factor plus something the user hasYesNoNo
Federated multifactorYesNoNo
Certificate-based authentication, single-factorNoNoNo
SMS sign-in, password, federated single-factor, QR codeNoNoNo
How an engagement runs

Five steps, and registration comes before policy every time.

The order is the whole method. Enforce a method requirement before the methods exist and you have created an outage rather than a control.
  1. 1

    Map resources to the strength they need

    Not every application needs the same requirement, which is the point of the control. Sensitive resources, sensitive actions, high risk users and external access are the four scenarios Microsoft names, and each can carry a different strength.

  2. 2

    Measure what people can satisfy today

    Registered method inventory across the population, mapped against the published combination table. Only FIDO2, Windows Hello for Business or platform credential, and multifactor certificate-based authentication satisfy phishing resistance, so the gap is usually larger than expected.

  3. 3

    Register methods and define the fallback

    Registration first. Temporary Access Pass helps with onboarding and it satisfies MFA strength only, so it cannot serve as a fallback for a phishing-resistant policy. Break glass account handling confirmed before anything is enforced.

  4. 4

    Create the policy with the correct grant control

    Require authentication strength replaces Require multifactor authentication rather than joining it, since the two cannot be used in the same policy. Applied to one sensitive resource first, with a pilot group that will report friction rather than route around it.

  5. 5

    Brief people, then broaden by sensitivity

    User guidance covering the Sign-in options route, because users are not prompted for a method they did not start with. Then extension resource by resource, with the sign-in frequency interaction understood if both controls are in play.

Straight answers

What organisations ask about authentication strengths.

Require MFA treats every multifactor method as equivalent. An authentication strength specifies which combinations of methods can be used for a resource, so you can demand phishing-resistant methods for one application and accept a password plus a push notification for another. The built-in MFA strength is equivalent to the older control.

Three combinations: Windows Hello for Business or platform credential, FIDO2 security key, and Microsoft Entra certificate-based authentication in its multifactor form. Microsoft Authenticator phone sign-in satisfies the MFA and passwordless strengths but not the phishing-resistant one, which surprises a lot of teams.

Not on its own. SMS sign-in satisfies none of the three built-in strengths. Text message does appear as one of the options behind password plus something the user has, which satisfies the MFA strength only. Password alone, federated single-factor, single-factor certificate-based authentication and QR code satisfy nothing.

No. You cannot use Require multifactor authentication and Require authentication strength grant controls together in the same Conditional Access policy, because the built-in Multifactor authentication strength is equivalent to the older control. Moving to strengths means replacing the control in that policy.

No, and this is the most misread part. Conditional Access policies are evaluated only after the initial authentication, so an authentication strength does not restrict it. The user can still enter a password, and then must sign in with a qualifying method before they can continue.

Because they are not prompted for the method the strength requires. If a user signs in with a password as primary authentication and the strength requires Windows Hello for Business, they need to restart the session, select Sign-in options, and choose a qualifying method. Tell people this before you enforce it.

Yes, Conditional Access administrators can create custom authentication strengths based on the method combinations they want to allow. In most engagements the three built-ins cover the requirement, and a custom strength is worth it when your method estate genuinely does not map onto them.

Yes, and it is worth planning for. Built-in strengths are always available and cannot be modified, and Microsoft updates them when new methods become available. That means a policy you wrote last year may accept a method today that did not exist when you wrote it.

Requiring specific methods from guest users who access a resource tenant is a documented scenario, used in combination with cross-tenant settings. The constraint to design around is that the Email one-time pass for guests is not currently supported in the available combinations.

For an MFA strength, yes. For passwordless or phishing-resistant strengths, no. Temporary Access Pass in both its one-time and multiple use forms satisfies the MFA strength only. That matters when you are designing the onboarding path for a phishing-resistant policy, since the obvious fallback does not qualify.

Microsoft records a known issue. When a resource requires both an authentication strength and a sign-in frequency, users can satisfy the two at different times. The documented example is a passkey sign-in 24 hours ago satisfying the strength while a Windows Hello for Business device unlock today satisfies a one hour frequency.

Both, for different jobs. The authentication methods policy scopes and configures which methods users and groups can use across the tenant. An authentication strength restricts further for specific scenarios such as sensitive resource access, user risk and location. Microsoft frames the strength as built on top of the methods policy.

Conditional Access requires Microsoft Entra ID P1, which is the prerequisite stated on the authentication strengths documentation. If you are unsure which plan you hold or what it includes, that is worth establishing before designing policy rather than after.

Yes, in combination with Conditional Access authentication context. Requiring a specific authentication method when a user takes a sensitive action within an application is one of the scenarios Microsoft lists, and it is how you demand a hardware key to approve something without demanding one to open the app.

We scope by user population and how far current registration is from the target strength, since that gap sets the timeline. The free first step: pull your registered authentication methods report and count how many users could satisfy the phishing-resistant strength today. That number decides everything else.

Yes. Built-in authentication strengths are always available and cannot be modified, and Microsoft updates them when new methods become available. A policy written last year may therefore accept a method that did not exist when it was written, which is generally helpful and worth knowing.

Text message, voice, push notification, software OATH token, or hardware OATH token. Those combine with a password, or with federated single-factor authentication, to satisfy the multifactor authentication strength. None of those combinations satisfy the passwordless or phishing-resistant strengths.

Microsoft lists five: requiring specific methods for a sensitive resource, requiring a specific method for a sensitive action within an application using authentication context, requiring specific methods when accessing sensitive applications outside the corporate network, requiring stronger methods for users at high risk, and requiring specific methods from guest users.

Yes, through Microsoft Graph, by filtering authentication strength policies to those with a built-in policy type. That is a useful check when built-in definitions update as new methods become available, because it shows what a policy currently accepts rather than what it accepted when written.
Before you enforce anything

Fifteen checks that prevent a lockout.

Authentication strength incidents are almost always registration incidents. These checks move the discovery to a planning meeting rather than a Monday morning.

Readiness

  • What methods are actually registered?
    Measured, not assumed.
  • Who could satisfy phishing-resistant today?
    Usually fewer than expected.
  • Are FIDO2 keys or Windows Hello deployed?
    Two of the three qualifying methods.
  • Is certificate-based auth multifactor or single?
    Only multifactor qualifies.
  • Do we have Entra ID P1?
    Required for Conditional Access.

Policy design

  • Are we replacing Require MFA, not adding?
    They cannot be combined.
  • Which resources need which strength?
    Per resource, by sensitivity.
  • Are break glass accounts excluded?
    Verify, do not assume.
  • Do we use authentication context anywhere?
    It pairs with strengths.
  • Is sign-in frequency also applied?
    They can be satisfied separately.

People and guests

  • Do users know the Sign-in options route?
    They are not prompted automatically.
  • Is a Temporary Access Pass process in place?
    It satisfies MFA strength only.
  • How do guests authenticate today?
    Email one-time pass is not supported.
  • Are cross-tenant settings configured?
    They pair with guest strengths.
  • Has the service desk been briefed?
    Before, not after.
Related reading

The pages around this one.

Phishing-resistant MFA

Why the method quality distinction matters in the first place.

Learn more

Passwordless authentication

Getting the qualifying methods registered across the estate.

Learn more

Conditional Access

The policy framework this grant control sits inside.

Learn more
Next step

Count how many of your users could satisfy the phishing-resistant strength today.

Only FIDO2 keys, Windows Hello for Business or platform credential, and multifactor certificate-based authentication qualify. If that number is small, this is a registration programme before it is a policy change.

Book an authentication strength reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Phishing-Resistant MFA

The three methods that actually resist relay attacks

Learn more

Passwordless and Passkeys

Three seconds instead of sixty nine, and it cannot be phished

Learn more

Entra Conditional Access

The control that decides who reaches your data

Learn more

Continuous Access Evaluation

Sessions that stop when the condition changes

Learn more

Entra ID P1 vs P2

What P2 genuinely adds, and what quietly moved

Learn more

MFA Solutions

Entra MFA, passwordless, FIDO2

Learn more

Microsoft Entra

Identity and access management solutions

Learn more

Emergency Access Accounts

Break-glass admin that actually works on the day

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy