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. Phishing-resistant MFA
Phishing-resistant MFA, UAE

Three methods qualify as phishing-resistant. The push notification your organisation relies on is not one of them.

Microsoft built-in Phishing-resistant MFA strength allows exactly three combinations: Windows Hello for Business or a platform credential, a FIDO2 security key, and multifactor certificate-based authentication. Authenticator push sign-in satisfies MFA and passwordless strength. It does not satisfy phishing-resistant, because it does not require an interaction between the method and the sign-in surface.

Book a phishing-resistant MFA reviewSee what qualifies and what does not
Phishing-resistant multifactor authentication for UAE organisations
  • Three methodsWhat the built-in strength actually allows
  • Three strengthsMFA, passwordless, phishing-resistant
  • Entra ID P1The licence Conditional Access requires
  • Custom allowedWhere the built-in set does not fit
What qualifies

Seven things that decide whether your MFA is actually phishing-resistant.

Microsoft defines an authentication strength as a Conditional Access control specifying which combinations of authentication methods users can use to access a resource, with users satisfying the requirement by authenticating with any allowed combination. The three built-in strengths are not interchangeable, and the differences between them are where most organisations discover a gap.

The test is interaction between method and sign-in surface

Microsoft defines the phishing-resistant strength as including methods that require an interaction between the authentication method and the sign-in surface. That is the whole principle. A code, a push or a prompt can be relayed to an attacker site because it does not know where it is being used. A key bound to the origin cannot be, and that is why the qualifying list is short.

FIDO2 security keys and passkeys

The first of the three qualifying combinations. FIDO2 satisfies all three built-in strengths: MFA, passwordless MFA and phishing-resistant MFA. For most UAE organisations this is the practical answer for administrators, for staff without a managed Windows device, and for anyone who needs to authenticate from a shared or unmanaged machine.

Windows Hello for Business or a platform credential

The second qualifying combination, and the one with the best user experience because it is already how people unlock their device. It satisfies all three strengths. The catch is device coverage: it only helps on devices that support it and are enrolled for it, which in most estates leaves a population that needs a different answer.

Multifactor certificate-based authentication

The third qualifying combination, and the reason organisations with existing public key infrastructure often get to phishing-resistant faster than they expect. Note the qualifier carefully: only the multifactor form qualifies. Single-factor certificate-based authentication appears in the published table satisfying none of the three strengths.

Authenticator push does not qualify, and that surprises people

Microsoft Authenticator phone sign-in satisfies MFA strength and passwordless MFA strength, and does not satisfy phishing-resistant MFA strength. Neither does a Temporary Access Pass, a password plus something the user has, federated multifactor, or SMS sign-in. For most UAE organisations, that means the current MFA deployment is genuinely good and genuinely not phishing-resistant.

Built-in strengths update themselves, custom ones do not

Microsoft states built-in strengths are always available, cannot be modified, and are updated when new methods become available. Custom strengths let you specify exactly the combinations you allow, which is useful for a transition period, at the cost of owning the maintenance. We generally use built-in for the destination and custom only for the journey.

Strengths apply per scenario, not per tenant

Microsoft lists the scenarios directly: requiring specific methods for a sensitive resource, for a sensitive action inside an application using authentication context, for access from outside the corporate network, for users at high risk, and for guest users accessing your tenant in combination with cross-tenant settings. That is what makes a phased rollout possible.

The limitation to understand before you promise anything

A phishing-resistant strength does not stop the user typing their password.

Microsoft states this plainly, and it changes what you can honestly claim about credential theft.

  • Quoted: Conditional Access policies are evaluated only after the initial authentication, so an authentication strength does not restrict a user initial authentication. A user can still enter a password but must then sign in using a phishing-resistant method, such as a FIDO2 security key, before they can continue.
  • The practical consequence is that a credential harvesting page can still capture the password. What it cannot do is complete the sign-in, because the second factor is bound to the origin and will not work on the attacker site.
  • That is still an enormous improvement, and it is the reason phishing-resistant MFA is worth deploying. But it means password hygiene, leaked credential detection and identity protection remain necessary rather than optional.
  • Getting to genuinely no password requires passwordless deployment alongside the strength, which is a separate and complementary piece of work rather than something the Conditional Access control delivers on its own.
Ask us to review your authentication strengths
How we approach it

Four things that get an organisation to phishing-resistant without an outage.

The technology is straightforward. The failure modes are all operational: a locked-out administrator, an unprepared service desk, and a population nobody realised had no eligible device.

We build the emergency access position first

Requiring a phishing-resistant strength on administrative roles is exactly the change that can lock every administrator out at once. Emergency access accounts, cloud-only, registered with a qualifying method, and excluded from policies that block sign-in, exist before the policy is written rather than after the incident.

We scope by population and by resource, not by deadline

Authentication strengths are designed for scoping, and Microsoft lists the scenarios explicitly. Administrators, then the Windows Hello eligible population, then everyone else. A tenant-wide policy on day one produces a service desk queue that gets the whole programme reversed, which sets the organisation back further than a slower rollout.

We size the key requirement honestly and early

The population that has no Windows Hello eligible device and no existing certificate infrastructure needs physical FIDO2 keys, and that has procurement lead time, distribution logistics and a lost key process attached. Working out how many people that is, in week one, is what keeps the timeline realistic.

We brief the service desk on the behaviours that generate calls

Two in particular. When a strength requires Windows Hello for Business and the user signed in with a password, they are not prompted, they must restart the session and choose a different sign-in option. And where a strength and a sign-in frequency both apply, they can be satisfied at different times, which produces access that looks wrong and is not.

How we sequence it

Four phases, and administrators go first for a reason.

Phishing-resistant MFA fails as a big-bang rollout because the methods that qualify all require either a device capability or a physical credential. Sequencing by population, not by deadline, is what makes it deliverable.
  1. 01
    Weeks 1 to 2

    Administrators and emergency access

    Privileged accounts first, because they are few, high value, and the population most likely to be targeted by a relay attack. Emergency access accounts are handled alongside, since Microsoft own guidance for those recommends a passkey or certificate-based authentication and they need excluding from policies that would block sign-in.

    • FIDO2 keys issued and registered for every administrative account
    • A Conditional Access policy requiring the phishing-resistant strength for admin roles
    • Emergency access accounts configured and excluded from blocking policies
    • A tested rollback path before the policy is enforced
  2. 02
    Weeks 3 to 6

    The managed Windows population

    Windows Hello for Business gives phishing-resistant authentication with no hardware to issue and a user experience people already understand, which makes it the fastest population to move. The Windows Hello behaviour around primary authentication is explained to the service desk before enforcement, because it generates calls otherwise.

    • Windows Hello for Business enrolled across the eligible estate
    • Sign-in options behaviour documented for the service desk
    • Policy scoped to the enrolled population, not the whole tenant
    • Registration campaign run before any enforcement
  3. 03
    Weeks 7 to 12

    Everyone else, and the awkward cases

    Shared devices, kiosks, frontline staff, contractors, macOS and mobile-only users. This is where the population divides into people who need a security key, people covered by certificate-based authentication where a public key infrastructure already exists, and people who need a scoped exception with a documented review date.

    • Security keys issued to populations without an eligible device
    • Certificate-based authentication used where PKI already exists
    • Exceptions documented with owner, reason and review date
    • Guest access strength decided alongside cross-tenant settings
  4. 04
    Ongoing

    Hold the line and close the exceptions

    Registration monitored, exceptions reviewed rather than forgotten, and new joiners registered for a qualifying method during onboarding rather than afterwards. Built-in strengths update themselves as Microsoft adds methods, so a policy using them keeps improving without maintenance, which is the argument for using built-in wherever it fits.

    • Registration coverage reported monthly
    • Every exception carrying a review date that is actually reviewed
    • Qualifying method registered during joiner onboarding
    • Custom strengths retired once the transition they covered is complete
Where this matters most

Six UAE situations where phishing-resistant is the right requirement.

The common trigger is a real-time phishing kit, which relays a legitimate sign-in page to the victim and forwards their code or push approval to the attacker. Against that, only origin-bound methods hold.

A bank whose administrators are individually targeted

Privileged accounts are a small, high-value population and the natural first phase. Requiring the phishing-resistant strength on administrative roles, with FIDO2 keys held on designated workstations, closes the attack path that has produced the most damaging identity compromises in the region.

A firm that has already been through a successful phish

Once an organisation has watched a relay attack defeat push-based MFA, the conversation stops being about whether and becomes about how fast. Scoping the strength to the most sensitive applications first gives a defensible answer within weeks rather than waiting for a full estate rollout.

A group with an existing public key infrastructure

Multifactor certificate-based authentication is one of the three qualifying combinations, which means organisations that already run a certificate authority for other reasons frequently have a route to phishing-resistant that needs no new hardware. The distinction to check is that single-factor certificate authentication qualifies for nothing.

An operator with shared and frontline devices

The hardest population, because Windows Hello for Business assumes a personal device enrolment and a phone-based method assumes a phone. Security keys, sometimes shared under a controlled process and sometimes personal, are usually the answer, and working that out before enforcement rather than after is the entire difference.

A healthcare organisation with clinical workstation sharing

Rapid sign-in and sign-out on shared clinical machines is a genuine operational requirement, and it interacts badly with methods that assume one device per person. Certificate-based authentication with smartcards, or keys issued per clinician, are the two workable routes and both need to be tested against actual ward workflow.

An institution protecting a subset rather than everyone

Authentication strengths are per policy and per resource, so a university can require phishing-resistant methods for finance systems, research data and administrative roles while leaving general student access on standard MFA. That is a legitimate and defensible design rather than a compromise.

Three positions

How UAE organisations authenticate their people today.

The middle column is a good position that a great many organisations reached with real effort, and it is still relayable by a competent phishing kit. That is the uncomfortable part of this conversation.
Satisfies MFA requirements
Phishing-resistant strength enforcedYes
App push or code MFAYes
SMS or password onlyPartly
Resists real-time relay phishing
Phishing-resistant strength enforcedYes
App push or code MFANo
SMS or password onlyNo
Resists MFA fatigue attacks
Phishing-resistant strength enforcedYes
App push or code MFAPartly
SMS or password onlyNot applicable
Resists SIM swap
Phishing-resistant strength enforcedYes
App push or code MFAYes
SMS or password onlyNo
Bound to the sign-in surface
Phishing-resistant strength enforcedYes
App push or code MFANo
SMS or password onlyNo
Works without a phone
Phishing-resistant strength enforcedYes
App push or code MFANo
SMS or password onlyNo
Enforced per resource or risk level
Phishing-resistant strength enforcedYes
App push or code MFARarely
SMS or password onlyNo
Method set updates as Microsoft adds methods
Phishing-resistant strength enforcedYes, with built-in
App push or code MFANot applicable
SMS or password onlyNo
Rollout effort
Phishing-resistant strength enforcedModerate
App push or code MFALow
SMS or password onlyNone
Position after a targeted phishing campaign
Phishing-resistant strength enforcedHeld
App push or code MFACompromised
SMS or password onlyCompromised
Feature
Phishing-resistant strength enforced
App push or code MFA
SMS or password only
Satisfies MFA requirements
YesYesPartly
Resists real-time relay phishing
YesNoNo
Resists MFA fatigue attacks
YesPartlyNot applicable
Resists SIM swap
YesYesNo
Bound to the sign-in surface
YesNoNo
Works without a phone
YesNoNo
Enforced per resource or risk level
YesRarelyNo
Method set updates as Microsoft adds methods
Yes, with built-inNot applicableNo
Rollout effort
ModerateLowNone
Position after a targeted phishing campaign
HeldCompromisedCompromised
What satisfies what

Thirteen method combinations against the three built-in strengths.

Reproduced from the published table. Yes means the combination satisfies that strength. The pattern in the lower half is the finding most organisations are not expecting.
Authentication method combinationMFA strengthPasswordless 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-inNoNoNo
PasswordNoNoNo
Federated single-factorNoNoNo
QR codeNoNoNo
How an engagement runs

Five steps, and report-only mode is not skipped.

Typically eight to sixteen weeks depending on how many people need physical keys. The policy work is days. Registration, procurement and the awkward populations are what take the calendar.
  1. 1

    Establish licensing, current methods and eligibility

    Conditional Access requires Microsoft Entra ID P1, so that is checked first. Then which methods are currently registered across the population, which devices could support Windows Hello for Business, and whether a certificate infrastructure exists that could deliver multifactor certificate-based authentication.

  2. 2

    Build the emergency access position

    Two or more cloud-only emergency access accounts registered with a qualifying method and excluded from policies that block or restrict sign-in. This happens before any enforcing policy exists, because requiring a phishing-resistant strength on administrators is precisely the change that can lock everyone out simultaneously.

  3. 3

    Design the policies and run them in report-only

    Built-in phishing-resistant strength where it fits, custom strengths only where a transition genuinely needs them. Remembering that require multifactor authentication and require authentication strength cannot be combined in the same policy. Report-only first, always, with the impact reviewed against real sign-in data before enforcement.

  4. 4

    Register the population before enforcing on them

    Windows Hello enrolment for eligible devices, FIDO2 keys distributed and registered for everyone else, certificate-based authentication configured where a public key infrastructure exists. Enforcement follows registration by population, never the other way round, and the service desk is briefed before each wave.

  5. 5

    Enforce, then manage the exceptions down

    Policies moved from report-only to enforced per population. Every exception carries an owner, a reason and a review date. Registration coverage is reported monthly, and joiners register a qualifying method during onboarding, which is the only way the position holds rather than eroding.

Straight answers

What organisations ask about phishing-resistant MFA.

Microsoft built-in Phishing-resistant MFA strength allows combinations of Windows Hello for Business or a platform credential, a FIDO2 security key, and Microsoft Entra certificate-based authentication in its multifactor form. Those three, and no others. The published rationale is that the strength includes methods that require an interaction between the authentication method and the sign-in surface.

Correct, and the published table is unambiguous. Microsoft Authenticator phone sign-in satisfies MFA strength and passwordless MFA strength but not phishing-resistant MFA strength. It is a genuinely strong control against password reuse and credential stuffing. It is not a control against a real-time relay attack, because the approval does not know which site requested it.

Password plus something the user has satisfies MFA strength only, and Microsoft defines something the user has as text message, voice, push notification, software OATH token or hardware OATH token. SMS sign-in on its own satisfies none of the three strengths. Neither does a password alone, federated single-factor authentication, single-factor certificate-based authentication or a QR code.

No, and Microsoft is explicit about it. Conditional Access policies are evaluated only after initial authentication, so an authentication strength does not restrict a user initial authentication. A user can still enter a password, but must then sign in with a phishing-resistant method before continuing. The attacker gets the password and cannot complete the sign-in, which is a large improvement rather than a complete one.

Microsoft states that to use Conditional Access, your tenant needs a Microsoft Entra ID P1 licence. Authentication strengths are a Conditional Access grant control, so the same requirement applies. Most UAE organisations we work with already hold P1 through a Microsoft 365 subscription and have simply never used strengths.

No. Microsoft states 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 grant control. In practice you replace one with the other rather than adding it.

Built-in wherever it fits. Microsoft states built-in strengths are always available, cannot be modified, and are updated when new methods become available, which means a policy using one improves automatically as Microsoft adds qualifying methods. Custom strengths are worth it during a transition where you need to permit a combination the built-in set does not, and are worth retiring once that transition ends.

Microsoft lists requiring specific authentication methods from guest users accessing a resource tenant, in combination with cross-tenant settings, as one of the supported scenarios. It also notes one exclusion: the email one-time passcode method for guests is not currently supported in the available combinations. Guest strength is a decision to take deliberately alongside your cross-tenant access settings.

This is documented behaviour and it generates service desk calls. If the user signed in with Windows Hello for Business as the primary method, it satisfies a strength that includes it. But if they signed in with another method such as a password and the strength requires Windows Hello, they are not prompted for it. They must restart the session, select sign-in options, and choose a method the strength requires.

Microsoft publishes this as a known issue. When a resource requires both, users can satisfy the two requirements at different times. The published example is a passkey sign-in 24 hours ago satisfying the strength, while a Windows Hello device unlock today satisfies a one-hour sign-in frequency. It looks wrong and it is the documented behaviour, which is worth knowing before an auditor asks.

Usually not. Windows Hello for Business qualifies and needs no hardware beyond a device that supports it, and multifactor certificate-based authentication qualifies where a public key infrastructure already exists. Physical FIDO2 keys are for the population that has neither, which typically means shared devices, frontline staff, some contractors and macOS or mobile-only users. Sizing that group early is what makes the budget realistic.

Yes, and you should. Microsoft designed strengths for exactly that, listing scenarios including sensitive resource access, sensitive actions within an application using authentication context, access from outside the corporate network, and users at high risk. Administrators first, then the eligible device population, then everyone else, is the sequence that works.

Real, and it is the single thing we plan around. Requiring a phishing-resistant strength on administrative roles when an administrator has not registered a qualifying method locks them out completely. Emergency access accounts, report-only mode first, verified registration before enforcement, and a named person who can disable the policy are the four controls that make this safe.

They overlap but are not the same. Passwordless MFA strength includes methods that satisfy MFA without requiring a password, which includes Authenticator phone sign-in. Phishing-resistant is the narrower set. An organisation can be passwordless without being phishing-resistant, and can be phishing-resistant while users still hold passwords. Most organisations want both, in that order.

We scope per organisation, driven mainly by how many people need physical keys and how many awkward populations exist. The design and policy work is a small part. Hardware, distribution and the registration campaign are the majority, and that is a number we can put a range on within the first week once eligibility is measured.
Before you enforce

Fifteen checks that prevent a lockout on a Sunday night.

Enforcing an authentication strength is one of the few Conditional Access changes that can lock out an administrator completely. Every item in the first group exists because of that.

Do not lock yourself out

  • Do you have emergency access accounts?
    At least two, cloud-only.
  • Are they excluded from blocking policies?
    Report-only policies do not need exclusion.
  • Has every admin registered a qualifying method?
    Check before enforcing, not after.
  • Is the policy in report-only first?
    Always, without exception.
  • Who can disable the policy if it goes wrong?
    And can they sign in to do it.

Coverage

  • Which devices support Windows Hello for Business?
    That population is the cheapest to move.
  • Do you have a PKI already?
    Multifactor CBA qualifies, single-factor does not.
  • How many people need a physical key?
    Procurement lead time is real.
  • What about shared and frontline devices?
    Usually the hardest population.
  • Are guests in scope?
    Strengths work with cross-tenant settings.

Policy design

  • Are you mixing grant controls?
    Require MFA and require strength cannot be combined.
  • Is sign-in frequency also applied?
    The two can be satisfied at different times.
  • Built-in strength or custom?
    Built-in updates itself as methods are added.
  • Is the scope a resource, a risk level or everyone?
    Strengths are designed for scoping.
  • Does the service desk know the Hello behaviour?
    Users are not prompted, they must reselect.
Related reading

The pages around this one.

Passwordless authentication

The complementary programme, and where Windows Hello and passkeys come from.

Learn more

Conditional Access

The policy framework strengths are a grant control within.

Learn more

Windows Hello for Business

The qualifying method with the best user experience and the largest deployment.

Learn more
Next step

Check whether your administrators could sign in tomorrow with a phishing-resistant method.

In most tenants we look at, the answer is that some could and some could not, and nobody has checked. That single question determines whether this is a two week project for privileged accounts or a three month one.

Book a phishing-resistant MFA reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

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

Windows Hello for Business

Included from Windows Pro up, and almost nobody has deployed it

Learn more

MFA Solutions

Entra MFA, passwordless, FIDO2

Learn more

Entra ID Protection

On P1 you see a flag. On P2 you see why, and can act on it

Learn more

Privileged Identity Management

Just-in-time admin access, approval, and audit history you can download

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more

Entra ID P1 vs P2

What P2 genuinely adds, and what quietly moved

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