We value your privacy

We use cookies to analyze 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 Entra
  3. Authentication strengths
Conditional Access authentication strengths for US businesses

A policy that just says require MFA cannot tell a text message apart from a hardware key. Authentication strengths can.

The control names the method combinations acceptable for a particular resource. That is what lets the finance platform insist on phishing-resistant sign-in while the intranet carries on accepting a push approval. It is a single grant control, but it changes the resolution at which you can write access policy, and it is the answer American organizations increasingly need when a carrier or an auditor asks whether their MFA is phishing resistant.

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

Eight things that determine whether this lands cleanly.

Configuring it is straightforward. Deploying it badly is equally straightforward, and comes in two flavors: locking users out, or running a policy that looks like it enforces something and does not. The concept is not where the difficulty lives. The documented limitations are.

Different requirements for different resources

A strength is a list of acceptable method combinations for reaching a resource, and any one of those combinations satisfies it. Because the list is per resource, a sensitive application can insist on phishing-resistant methods while the rest of the estate carries on with something weaker that people can actually use every day.

The three built-in strengths

There are three: Multifactor authentication strength, Passwordless MFA strength and Phishing-resistant MFA strength. They are permanently present, you cannot edit them, and Microsoft revises their contents as new authentication methods ship. In other words the definition you wrote policy against can shift underneath you without anyone in your organization touching a setting.

Exactly what satisfies phishing resistance

Exactly three combinations clear that bar: Windows Hello for Business or a platform credential, a FIDO2 security key, and Microsoft Entra certificate-based authentication in its multifactor form. Worth committing to memory, Microsoft Authenticator phone sign-in gets you past the MFA and passwordless strengths and stops short of the phishing-resistant one.

What satisfies nothing at all

Five methods clear none of the three built-in strengths: single-factor certificate-based authentication, SMS sign-in, a password on its own, federated single-factor, and QR code. Any application that has quietly been protected by one of those is about to become inaccessible the moment the policy is enabled, and that is usually the first anyone hears of it.

It does not restrict the initial authentication

Of every limitation in the documentation, this is the one most often misread. Conditional Access does not run until the first authentication has already happened, which means a strength has no say over it. The password still gets typed. What the strength controls is what has to occur after that before the user goes any further.

It cannot be combined with Require multifactor authentication

The two grant controls, Require multifactor authentication and Require authentication strength, are mutually exclusive within one Conditional Access policy. Microsoft treats the built-in Multifactor authentication strength as equivalent to the older control, so there is nothing to gain by combining them and the product will not let you. Moving across is a swap, not an addition.

Guests, and one method that is not supported

Demanding particular methods from guests who reach into your tenant is supported, and works alongside cross-tenant access settings. One constraint shapes the whole design: Email one-time pass for guests does not appear in the available combinations today, which forces a rethink of how partner onboarding is built.

How it interacts with sign-in frequency

There is a documented known issue here, and it is worth reading before you lean on the pair. Where a resource carries both an authentication strength and a sign-in frequency, the two can be satisfied at separate moments. A passkey used yesterday combined with a device unlock this morning can be enough to get through.

The behavior that generates tickets

Start with a password and no Windows Hello prompt ever appears. The session has to be restarted from scratch.

The behavior is spelled out in the documentation, and it still generates more support calls than anything else on the day a phishing-resistant strength is switched on.

  • Sign in with Windows Hello for Business as the primary method and any strength listing Windows Hello for Business is satisfied straight away. Come in through something else, a password being the usual case, against a strength that demands Windows Hello for Business, and no prompt for it will ever appear.
  • What actually has to happen is a fresh session, a click on Sign-in options, and a deliberate choice of a method the strength accepts. Nobody discovers that sequence on their own. To the person at the screen it simply looks like a wall, which is why this has to be communicated before enforcement, not after.
  • Alongside that sits a point people conflate with it. Strengths place no limit whatsoever on the first authentication, because Conditional Access has not yet run at that moment. The password can still be typed. What the strength decides is what must follow before the session proceeds, not what the user is permitted to try first.
  • Nothing technical fixes this. It is handled by sequence and by messaging: get the methods registered before the policy touches anyone, show people what the Sign-in options path looks like, and run the pilot with a group that will complain loudly rather than quietly find a workaround.
Ask us to plan the rollout sequence
How we approach it

Four things that stop this becoming a lockout incident.

There is nothing complicated about the control itself. The trouble comes from two directions: requiring a method before people have registered it, and a sign-in experience that never asks for the very thing the policy demands.

We measure registration before writing policy

Three things and only three clear the phishing-resistant bar: FIDO2 security keys, Windows Hello for Business or a platform credential, and certificate-based authentication in multifactor form. Turn the policy on before those are registered and what you have built is a lockout with a configuration screen in front of it. Your registration percentage is the number that sets the schedule.

We brief people on the Sign-in options route

A password sign-in against a strength that requires Windows Hello for Business produces no prompt for Hello at all. The user has to abandon the session, start again, open Sign-in options and pick something that qualifies. Anyone who has not been briefed on that reads the whole thing as a dead end.

We replace the old grant control rather than stacking

Those two grant controls cannot coexist inside a single policy, since the built-in MFA strength does the same job as the older control. The migration is therefore a straight replacement, and a policy attempting to hold both will refuse to save.

We design guest access around what is supported

Yes, and it is a supported scenario that works together with cross-tenant access settings. The design constraint is Email one-time pass for guests, which does not currently appear in the available combinations, and its absence eliminates one of the more common ways partners get onboarded.

How a rollout runs

Four phases across roughly four to six weeks.

An hour covers the configuration. Everything else is registering the required methods across enough devices and ordering the rollout so that nobody ends up locked out of their own account.
  1. 01
    Week 1

    Establish what people can currently satisfy

    We establish which methods are actually registered across your user population, and from that which strengths each group could meet right now. Anywhere still leaning on SMS, or on a password followed by a push, this is the moment it becomes clear that a phishing-resistant strength is a registration program with a policy change at the end of it.

    • 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 comes before enforcement, without exception. Temporary Access Pass earns its place in this phase, with one caveat that catches people out: it meets the MFA strength alone, neither passwordless nor phishing-resistant, so it cannot serve as the safety net under 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 new policy is built on Require authentication strength and takes the place of Require multifactor authentication rather than sitting beside it, because the platform does not permit both. It goes live against a single sensitive application first, scoped to a group that will tell you when something rubs.

    • 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

    From there it spreads resource by resource, ordered by how sensitive each one is rather than switched on everywhere in a weekend. Guest access is designed alongside cross-tenant settings, taking into account that Email one-time pass for guests is absent from the supported 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.

It plays out the same way each time. A business that has MFA on every account finds out that the word every is doing a lot of work, and that it covers methods nobody would knowingly put in front of the crown jewels.

A financial firm protecting a payments or trading system

One application carrying far more risk than everything around it is badly served by a single requirement stretched across the whole tenant, because that averages the risk instead of describing it. Put a phishing-resistant strength on the resource that matters and something lighter everywhere else, and the configuration now matches reality. It also reads well when an examiner, or a New York DFS Part 500 assessment, asks how you protect privileged and high-risk access.

A business that has been phished despite having MFA

Adversary-in-the-middle tooling walks straight through push approvals and one-time codes, and that is exactly why Microsoft Authenticator phone sign-in clears the MFA and passwordless strengths while falling short of the phishing-resistant one. Lifting the sensitive resources onto that stronger strength is the direct remedy. It is also, increasingly, the specific change a cyber carrier asks about once a claim has been filed.

An organization with a small high-privilege population

Issuing FIDO2 keys across an entire workforce is a program of work. Issuing them to the admins and the people who approve payments takes about a week. Because a strength can be scoped, the tougher requirement lands only where the keys already are, and that is what turns an all or nothing decision into something you can stage.

A company giving partners access to a shared workspace

Guests reaching into your tenant can be held to particular methods, and the scenario is supported when paired with cross-tenant access settings. What shapes the design is the absence of Email one-time pass for guests from the current combinations, which means partner onboarding has to travel a different route.

A provider protecting a clinical records system specifically

If electronic protected health information lives in one system and nowhere else, putting the strongest requirement on that system alone keeps the control in proportion to what HIPAA actually asks of you. It has a second benefit that matters more than it sounds: you can explain in one sentence why signing into that system feels different from signing into anything else.

A business protecting an action rather than an application

Pair a strength with Conditional Access authentication context and you can demand a particular method at the moment a user does something sensitive inside an application, rather than at the door. That is the mechanism behind requiring a hardware key to release a payment while leaving the application itself open on a normal sign-in.

Three positions

How US organizations express access requirements.

Most organizations sit in the middle column, and that is precisely where the real exposure lives. A code by text and a hardware key both clear that bar, and only one of the two survives a phishing attempt.
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.

Drawn straight from the published combination table. Ten minutes with it before you write a policy heads off the two errors we see repeatedly: treating Authenticator as phishing resistant, and treating SMS as if it satisfies anything at all.

Authentication method combination

FIDO2 security key

MFA
Yes
Passwordless MFA
Yes
Phishing-resistant MFA
Yes

Authentication method combination

Windows Hello for Business or platform credential

MFA
Yes
Passwordless MFA
Yes
Phishing-resistant MFA
Yes

Authentication method combination

Certificate-based authentication, multifactor

MFA
Yes
Passwordless MFA
Yes
Phishing-resistant MFA
Yes

Authentication method combination

Microsoft Authenticator, phone sign-in

MFA
Yes
Passwordless MFA
Yes
Phishing-resistant MFA
No

Authentication method combination

Temporary Access Pass, one-time and multiple use

MFA
Yes
Passwordless MFA
No
Phishing-resistant MFA
No

Authentication method combination

Password plus something the user has

MFA
Yes
Passwordless MFA
No
Phishing-resistant MFA
No

Authentication method combination

Federated single-factor plus something the user has

MFA
Yes
Passwordless MFA
No
Phishing-resistant MFA
No

Authentication method combination

Federated multifactor

MFA
Yes
Passwordless MFA
No
Phishing-resistant MFA
No

Authentication method combination

Certificate-based authentication, single-factor

MFA
No
Passwordless MFA
No
Phishing-resistant MFA
No

Authentication method combination

SMS sign-in, password, federated single-factor, QR code

MFA
No
Passwordless MFA
No
Phishing-resistant MFA
No
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.

Sequence is the entire discipline here. Demand a method before that method exists on user devices and what you have built is an outage wearing the clothes of a security control.
  1. 1

    Map resources to the strength they need

    The whole reason the control exists is that applications do not all deserve the same treatment. Microsoft names four scenarios, sensitive resources, sensitive actions, high-risk users and external access, and every one of them can be given its own strength.

  2. 2

    Measure what people can satisfy today

    We inventory what is registered across your users and lay it against the published combination table. Since phishing resistance is met only by FIDO2, Windows Hello for Business or a platform credential, and multifactor certificate-based authentication, the shortfall that surfaces is normally wider than anyone expected going in.

  3. 3

    Register methods and define the fallback

    Nothing gets enforced until registration is done. Temporary Access Pass is genuinely useful for onboarding, with the caveat that it meets the MFA strength alone and therefore cannot back up a phishing-resistant policy. Break-glass account handling is settled and tested before a single policy goes into enforcement.

  4. 4

    Create the policy with the correct grant control

    Because the platform will not accept both in one policy, Require authentication strength takes over from Require multifactor authentication rather than sitting next to it. The first target is a single sensitive resource, piloted by a group that will raise a hand when something hurts instead of quietly finding a way around it.

  5. 5

    Brief people, then broaden by sensitivity

    People get written guidance on the Sign-in options path, since the prompt they need will never appear on its own once they have started with the wrong method. After that we extend the policy one resource at a time, with the sign-in frequency interaction properly understood wherever both controls are in use.

Straight answers

What US organizations ask about authentication strengths.

The older control flattens every multifactor method into one category and treats them as interchangeable. A strength does the opposite: it names the combinations that are acceptable for a given resource. That is what allows one application to insist on phishing-resistant methods while another is content with a password followed by a push. For completeness, the built-in MFA strength does exactly what the old Require MFA control did.

Three, and no more: Windows Hello for Business or a platform credential, a FIDO2 security key, and Microsoft Entra certificate-based authentication in multifactor form. The detail that catches teams out is Microsoft Authenticator phone sign-in, which meets the MFA and passwordless strengths and does not meet the phishing-resistant one.

By itself, no. SMS sign-in clears none of the three built-in strengths. A text message does show up as one option within password plus something the user holds, and that combination reaches the MFA strength and stops there. Four other methods reach nothing at all: a password on its own, federated single-factor, single-factor certificate-based authentication, and QR code.

You cannot. The two grant controls are blocked from coexisting inside one Conditional Access policy, on the grounds that the built-in Multifactor authentication strength already does the job of the older control. Adopting strengths therefore means swapping the control out of that policy rather than adding to it.

It does not, and this is the piece people get wrong most often. Evaluation of Conditional Access happens only once the first authentication is complete, which puts the initial step beyond the reach of any strength entirely. The password still gets entered. Only afterwards does the user have to produce a qualifying method to go any further.

The prompt they are waiting for never comes. Where the primary authentication was a password and the strength calls for Windows Hello for Business, the only way through is to start the session again, open Sign-in options and pick a method that qualifies. Brief people on that sequence before enforcement day, not during it.

You can. A Conditional Access administrator is able to define a custom strength from whichever method combinations the business wants to permit. In practice the three built-ins answer the requirement most of the time, and building a custom one earns its keep only where your registered methods genuinely refuse to fit the standard shapes.

They do, and it belongs in your planning. The built-ins are permanently present, closed to editing, and revised by Microsoft as new methods arrive. The practical consequence is that a policy written last year may today be admitting a method that had not shipped at the time. Usually that works in your favor. Either way you should know it happens.

Holding guests to particular methods when they reach a resource tenant is documented and supported, working together with cross-tenant access settings. Design around one gap: Email one-time pass for guests does not currently feature in the available combinations.

Against an MFA strength it works. Against passwordless or phishing-resistant strengths it does not. Both forms of Temporary Access Pass, single use and multiple use, reach the MFA strength and go no higher. Keep that in view when you design onboarding for a phishing-resistant policy, because the fallback everybody reaches for first is not eligible.

There is a known issue on record for this. Put both an authentication strength and a sign-in frequency on the same resource and the two can be met at different moments. The documented example makes it concrete: a passkey used a day ago covers the strength, while a Windows Hello for Business device unlock this morning covers a one hour frequency.

You can, provided you bring Conditional Access authentication context into it. Microsoft lists this among its supported scenarios: tying a specific method to a sensitive action taken inside an application. It is the mechanism that lets you insist on a hardware key to approve a transaction while leaving ordinary access to the application alone.
Before you enforce anything

Fifteen checks that prevent a lockout.

When an authentication strength causes an incident, the root cause is nearly always registration coverage. These checks surface that during planning instead of at the start of a working week.

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

The reason it matters which method somebody actually used.

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

Find out what share of your workforce could clear a phishing-resistant strength right now.

The qualifying list is short: FIDO2 keys, Windows Hello for Business or a platform credential, and certificate-based authentication in multifactor form. Where the count comes back low, treat what follows as a registration program that happens to end in a policy change.

Book an authentication strength reviewExplore Microsoft Entra services

Related Services

Explore more solutions that work great with this service

Phishing-Resistant MFA

Phishing-resistant multifactor authentication for US organizations:

Learn more

Passwordless Authentication and Passkeys

Passwordless authentication rollouts for US organizations using

Learn more

Microsoft Entra Conditional Access Design

Conditional Access design and review for US organizations:

Learn more

Continuous Access Evaluation Readiness

Continuous access evaluation readiness for US organizations: the five

Learn more

Microsoft Entra ID P1 and P2 Licensing Review

Independent Entra ID P1 against P2 advice for US organizations:

Learn more

MFA Solutions

Multi-factor authentication implementation for US businesses on

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

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 USA
  • IT AMC USA
  • 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

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA