Conditional Access authentication strength looks like a stricter version of the MFA checkbox and behaves like an eligibility test. It does not ask whether the user completed multifactor authentication. It asks which method they used, and it keeps asking until one of the permitted methods is produced. If the user holds no such method and cannot register one, Microsoft Entra ID blocks the sign-in rather than falling back to something weaker. That is the design working correctly, and it is where almost all of the trouble comes from.
A strength is a grant control, so it sits inside a policy whose assignments, exclusions and evaluation order decide everything else about the sign-in. The Conditional Access policy design guide covers that layer. This page is only about the grant control itself and the population it quietly excludes.
One disclosure before the detail. My tenant is a lab with no enrolled devices and no partner tenants, so I have not run a phishing-resistant strength against a real external population. What follows is the documented behaviour, verified against Microsoft Learn on 2 September 2026, plus the places I would expect it to bite.
What Conditional Access authentication strength replaces
The older grant control is Require multifactor authentication. It is satisfied by anything the tenant currently treats as a second factor, which in most tenants means a text message counts exactly as much as a security key. A strength narrows that to a named list of methods and refuses everything outside it.
The two controls are not alternatives and Microsoft does not present them as such. Both appear in the same grant panel, and where a policy carries more than one control the administrator chooses between requiring all of the selected controls or requiring one of them. Requiring all is the default. That matters more than it sounds, because a policy that requires both a strength and the legacy MFA control is not stricter than the strength alone, it is just harder to read a year later.
The licence is Microsoft Entra ID P1, the same floor as Conditional Access itself, so a strength adds no cost to a tenant already licensed for policies. Where the P1 and P2 line actually falls is a separate question, set out in Entra ID P1 vs P2 and the licence maths.
Strengths are defined in the Microsoft Entra admin centre under Entra ID then Authentication methods then Authentication strengths. Microsoft’s own documentation does not agree with itself on that path: the grant controls reference and the custom strengths article both give the Entra ID route, while the troubleshooting article still routes through Security. All three were live on 2 September 2026. Use the Entra ID path and treat any guide that leads with Security as written against an older portal.
The three built-in strengths and what each one accepts
There are three, and their names are fixed: Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength. The useful way to read them is not as three security levels but as three progressively shorter lists of methods.
| Method | MFA | Passwordless MFA | Phishing-resistant MFA |
|---|---|---|---|
| FIDO2 security key | Yes | Yes | Yes |
| Windows Hello for Business, or platform credential | Yes | Yes | Yes |
| Certificate-based authentication (multifactor) | Yes | Yes | Yes |
| Microsoft Authenticator phone sign-in | Yes | Yes | No |
| Temporary Access Pass | Yes | No | No |
| Password plus something the user has | Yes | No | No |
| Federated single-factor plus something the user has | Yes | No | No |
| Federated multifactor | Yes | No | No |
Source: the Conditional Access authentication strengths overview on Microsoft Learn, which carried a last-updated date of 24 October 2025 when I read it on 2 September 2026. That gap is worth knowing about before you quote the table to a security committee.
The two federated rows are the ones people read past. They only apply where an external identity provider is asserting the claim, so whether they are available to you at all is settled by your hybrid identity topology long before anyone opens the strengths blade, and the current constraints on that topology are set out in Entra Cloud Sync vs Connect Sync. A cloud-only tenant can ignore both rows entirely.
The row that decides most deployments is Temporary Access Pass. It satisfies the Multifactor strength and nothing above it, which is correct behaviour and also means a Temporary Access Pass cannot be used to bootstrap a user into a resource protected by the phishing-resistant strength. If your onboarding depends on a Temporary Access Pass and your admin portals are protected by a phishing-resistant strength, those two decisions collide on the first day of employment for every new administrator.
What happens when the user cannot satisfy the strength
Entra first checks the methods the user has already used in the session. If one of them satisfies the requirement, access is granted with no further prompt, which is why a strength often appears to do nothing on the estate that already uses strong methods. If none of them satisfies it, the user is prompted for a method that does.
If the user has registered no method at all that satisfies the strength, they are redirected into combined registration in interrupt mode and asked to register one. Microsoft is explicit about the boundary case, and it is the sentence to read twice: if the strength does not include a method the user is able to register and use, Entra blocks the sign-in to that resource. There is no downgrade path and no prompt explaining which method was wanted.
Two things narrow that registration escape hatch further. Some passwordless methods cannot be registered during an interrupted sign-in at all and have to be registered in advance by the user or an administrator. And Windows Hello for Business is only offered after primary authentication has completed, so a user who has it will sometimes be told the method is unavailable when it merely has not been reached yet. The documented recovery is to restart the session, choose Sign-in options, and pick the method directly.
The other half of the problem is the authentication methods policy. A strength permits a method, it does not enable it. If FIDO2 is permitted by the strength but disabled for that user in the Authentication methods policy, the method is never offered and the user experiences it as a missing button rather than as a policy decision. When a strength is behaving strangely, check the strength, the authentication methods policy, and the user’s registered methods in that order.
External users are where authentication strength stops behaving
This is the part that gets deployments rolled back, and it is documented clearly enough that nobody has an excuse for being surprised by it. A strength applied to guests works together with the MFA trust setting in cross-tenant access settings, which decides whether an MFA claim from the user’s home tenant is accepted or whether the challenge is re-run in your tenant. Microsoft notes that MFA trust is optional for B2B collaboration and required for B2B direct connect.
Where the challenge lands changes which methods exist. In the home tenant every method is available. In the resource tenant, which is to say yours, five are not.
| Method | Home tenant | Resource tenant |
|---|---|---|
| Text message as second factor | Yes | Yes |
| Voice call | Yes | Yes |
| Microsoft Authenticator push notification | Yes | Yes |
| OATH software token | Yes | Yes |
| Microsoft Authenticator phone sign-in | Yes | No |
| OATH hardware token | Yes | No |
| FIDO2 security key | Yes | No |
| Windows Hello for Business | Yes | No |
| Certificate-based authentication | Yes | No |
Source: how authentication strengths work for external users, read 2 September 2026. Put that table next to the strengths table and the consequence falls out on its own. Every method in the Phishing-resistant MFA strength is in the unsupported column for the resource tenant. A phishing-resistant strength aimed at guests is therefore unsatisfiable in your own tenant by construction. It can only ever be met by a claim carried over from a home tenant that did the work, which means it depends entirely on MFA trust being enabled and on the partner having deployed those methods.
Microsoft’s own guidance for the guest policy recommends the Multifactor authentication strength for external users, not the strong ones, and that recommendation is not timidity. It is the only built-in strength the resource tenant can actually satisfy unaided.
One more incompatibility sits in the same article and is easy to miss: if you use external authentication methods to bring a third-party MFA provider into Entra, authentication strength is not compatible with them and Microsoft directs you back to the Require multifactor authentication control. A tenant that has standardised on a third-party provider cannot use strengths for that population at all.
Custom strengths, and the two limits worth knowing
A tenant may hold up to fifteen custom strengths, created under Entra ID, Authentication methods, Authentication strengths, New authentication strength. Fifteen is generous, and it is also a real ceiling for anyone who reaches for a bespoke strength per application.
The constraint that bites operationally is deletion. A strength referenced by a Conditional Access policy cannot be deleted, and any edit to one in use has to be confirmed. That is the right behaviour, and it means a strength is not a throwaway object: you unpick the policies first, then the strength. Certificate-based authentication carries its own combination rule inside a custom strength. If you configure both certificate issuers and policy OIDs, the presented certificate must match at least one issuer and at least one OID, not either one. The detail is in the custom authentication strengths documentation.
The failure modes
Guests cannot sign in and no error names the reason. A phishing-resistant strength has been scoped to guest or external users. None of the methods it permits can be completed in the resource tenant, and MFA trust is off, so there is nothing the guest can do from their side. The symptom is a hard block, not a prompt. Check the inbound cross-tenant access settings before you touch the policy.
The right method is registered and never appears. The strength permits it, the user has it, and the Authentication methods policy does not enable it for that user’s group. Entra offers the intersection of the three, and the user only ever sees the result.
Windows Hello for Business is reported as missing on a device that has it. It is only available after primary authentication. The user has judged the prompt too early. Restarting the session and selecting the method under sign-in options resolves it, and no policy change is needed.
New administrators cannot onboard. A Temporary Access Pass satisfies only the Multifactor strength. If the first thing a new administrator must reach is protected by a phishing-resistant strength, their bootstrap credential is not accepted there. Either register the strong method before the account is needed, or scope the strong policy so that the registration path itself is reachable.
A third-party MFA provider is in use and the policy does nothing useful. External authentication methods and authentication strength are incompatible. This one is quiet, because the policy still saves and still shows as applied.
The strength cannot be deleted during a tidy-up. Something still references it. Find the referencing policy rather than working around the object, because a strength nobody can account for is usually load-bearing somewhere.
When any of these is live, the sign-in logs answer the question faster than the policy blades do. The Authentication Details tab names the enforced strength in its Requirement column, and the Conditional Access tab shows which policy applied and which grant controls it carried.
What I would do differently
Set the strength by population, not by sensitivity. The instinct is to pick the strongest thing the data deserves, and that instinct is what produces an unsatisfiable policy for guests. Decide first who has to pass it, then check that at least one method in the strength is available to every one of them. For external users read that as the Multifactor strength unless you have confirmed MFA trust and the partner’s method estate, both of which are facts about someone else’s tenant that can change without telling you.
Deploy strengths in report-only and read the Requirement column rather than trusting the count of successful sign-ins. A strength that everyone already satisfies looks identical in a success graph to a strength that is not being evaluated at all, and the two are very different positions to discover you are in.
Keep the number of custom strengths near zero for as long as possible. Fifteen sounds like room to be expressive, but a strength cannot be deleted while a policy references it, so every custom strength is a small permanent obligation. Most estates need one exception, not a catalogue, and the built-in three cover more ground than their names suggest. If a device signal is what you are really reaching for, the condition side of the policy is the better tool, and the Conditional Access device filter is where that logic belongs.
Finally, write down the date you checked. The overview table was last updated in October 2025, the portal path disagrees between two current Microsoft articles, and the external user matrix is the kind of thing that changes without a headline. Anything you assert about which method satisfies which strength is a claim about a specific day.
Last verified: 2 September 2026.
