Agent Foskett Academy • Microsoft Entra • Module 2 • Lesson 16

Lesson 16 — Authentication Strengths in Microsoft Entra

Requiring MFA does not always mean requiring the strongest available authentication.

Microsoft Entra Authentication Strengths allow Conditional Access policies to specify which authentication method combinations are acceptable for a protected resource. Instead of accepting any MFA method, an organisation can require passwordless MFA, phishing-resistant MFA or a custom combination designed for a particular workforce, application or risk level.

This lesson explains built-in and custom Authentication Strengths, how method combinations are evaluated, how step-up authentication works, and how Agent Foskett investigates sign-ins that fail or satisfy an Authentication Strength requirement.

Strong authentication is about the method, not only the number of factors.

Start Lesson Back to Microsoft Entra Academy

Agent Foskett Microsoft Entra Authentication Strengths lesson

What you will learn

This lesson explains how Microsoft Entra requires defined classes of strong authentication through Conditional Access.

Built-in authentication strengths

Custom authentication strengths

Conditional Access enforcement

Sign-in investigation

Learning objectives

After completing this lesson, you should be able to explain, design and investigate Microsoft Entra Authentication Strengths.

Describe the purpose of an Authentication Strength.
Compare the three built-in strengths.
Explain how method combinations satisfy a strength.
Create custom strengths for specific security requirements.
Apply a strength through Conditional Access.
Investigate failed, interrupted and successful strength evaluation.

The problem this solves

A policy that says “require MFA” may still permit a weaker method than the application, account or transaction deserves.

Authentication Strengths let administrators define the exact classes of methods that are acceptable before access is granted.

What is an Authentication Strength?

An Authentication Strength is a Microsoft Entra Conditional Access grant control that defines which authentication method combinations a user may use to access a protected resource.

The user can satisfy the requirement with any permitted combination included in the selected strength.

User requests access to an application ↓ Microsoft Entra evaluates Conditional Access ↓ Policy requires an Authentication Strength ↓ Existing authentication is checked ↓ Sufficient allowed method combination? ├── Yes → Access evaluation continues └── No → Step-up or method registration prompt

Authentication requirement vs strength

“Require multifactor authentication” asks whether an MFA claim can be satisfied.

“Require authentication strength” additionally limits which method combinations are acceptable for that policy.

Why method choice matters

SMS, push approval, device-bound credentials and hardware-backed phishing-resistant credentials do not provide identical protection.

The strength selected should reflect the value of the account, application and data being protected.

Built-in Authentication Strengths

Built-in strength	Purpose	Typical use
Multifactor authentication strength	Accepts supported combinations that satisfy MFA.	General workforce MFA where a broad set of methods is permitted.
Passwordless MFA strength	Requires supported passwordless multifactor methods.	Passwordless access for managed workforce scenarios.
Phishing-resistant MFA strength	Requires methods designed to resist credential phishing and adversary-in-the-middle attacks.	Administrators, sensitive applications, high-risk users and critical transactions.

Multifactor authentication strength

This is the least restrictive built-in strength. It permits supported method combinations that satisfy Microsoft Entra MFA.

It is useful for broad coverage but should not automatically be treated as phishing-resistant protection.

Passwordless MFA strength

Passwordless MFA uses methods that combine possession of a device or credential with a local user gesture such as a PIN or biometric.

It removes the reusable password from the sign-in experience while still satisfying multifactor requirements.

Phishing-resistant MFA strength

Phishing-resistant methods use cryptographic binding to the legitimate service and are designed to prevent users from giving an attacker a reusable secret.

This is the strongest built-in option and is particularly important for privileged and high-impact access.

Typical resistant methods

Supported combinations commonly include passkeys or FIDO2 security keys, Windows Hello for Business and certificate-based authentication in appropriate configurations.

The selected methods should match the organisation's device, recovery and operational requirements.

How Conditional Access uses Authentication Strengths

Assignments ├── Users or workload identities ├── Target resources └── Conditions such as risk, device, location or platform ↓ Access controls ├── Block access └── Grant access └── Require Authentication Strength ↓ Report-only testing ↓ Controlled enforcement

Step-up authentication

A user may already have a valid session but still be prompted when a new application requires a stronger method than the one previously used.

This is expected behaviour: the earlier sign-in did not satisfy the stronger policy now in scope.

Previously satisfied authentication

Microsoft Entra evaluates the authentication context and claims already present in the session.

If the existing method combination satisfies the required strength and other policy conditions, another prompt may not be necessary.

Custom Authentication Strengths

Custom strengths allow administrators to choose supported method combinations that match an organisation's own security and operational requirements.

They are useful when the built-in strengths are broader or narrower than the required control.

Good custom-strength use cases

Require selected hardware-backed methods for administrators.
Permit a controlled transitional set during migration.
Protect a sensitive application with a dedicated method policy.
Differentiate workforce, contractor and external-user access.

Designing a custom strength

Design question	Why it matters	Recommended approach
Which users are targeted?	Privileged users may require stronger controls than general users.	Start with clearly defined groups and maintain emergency-access exclusions.
Which applications are protected?	Critical systems justify stricter authentication.	Prioritise administration portals, finance, security and sensitive data.
Which methods are operationally ready?	Users cannot satisfy a strength with methods they have not registered.	Complete registration and recovery planning before enforcement.
How will recovery work?	Lost devices or keys can block legitimate users.	Use verified recovery and tightly controlled bootstrap methods.
How will exceptions expire?	Permanent exclusions weaken the intended control.	Document, approve, monitor and time-limit exceptions.

Authentication Methods Policy dependency

An Authentication Strength does not by itself register a method or make it available to a user.

The required methods must also be enabled and targeted appropriately through Authentication Methods Policies.

Registration readiness

Before enforcement, confirm that targeted users have at least one allowed method and understand how to use it.

Report-only deployment, pilot groups and registration reporting reduce lockout risk.

Passkeys and FIDO2

Passkeys and FIDO2 security keys use public-key cryptography and bind authentication to the legitimate service.

They are strong candidates for phishing-resistant access, especially for administrators and high-risk personnel.

Windows Hello for Business

Windows Hello for Business uses a device-bound key unlocked by a local PIN or biometric gesture.

It avoids transmitting a reusable password and can satisfy strong authentication requirements in supported scenarios.

Certificate-based authentication

Microsoft Entra certificate-based authentication can support strong authentication where certificate deployment, protection and lifecycle management are mature.

Certificate configuration and protection determine the assurance that the method provides.

Temporary Access Pass

Temporary Access Pass supports bootstrap and recovery, but it should not be confused with every final Authentication Strength requirement.

Use it through a verified, short-lived process to help users register an approved strong method.

Deployment process

1. Identify users and protected resources ↓ 2. Select a built-in or custom strength ↓ 3. Confirm required methods are enabled ↓ 4. Register pilot users ↓ 5. Create Conditional Access policy ↓ 6. Exclude emergency-access accounts ↓ 7. Run in Report-only mode ↓ 8. Review sign-in results and support impact ↓ 9. Enforce in controlled stages ↓ 10. Monitor failures, exceptions and method changes

Sign-in log evidence

Authentication requirement and method details.
Conditional Access policy result.
Authentication Strength requirement and satisfaction.
Failure or interruption reason.
Application, device, IP address and location.
Risk detections and session context.

Report-only validation

Report-only mode shows how a policy would evaluate without enforcing the control.

Review successful, failed, interrupted and not-applied outcomes before moving to enforcement.

Authentication investigation process

1. Identify the user, application and sign-in ↓ 2. Review Conditional Access policies in scope ↓ 3. Identify the required Authentication Strength ↓ 4. Review the method combination actually used ↓ 5. Determine whether step-up was requested ↓ 6. Confirm whether the user owned and approved the method ↓ 7. Check registration, device, risk and session events ↓ 8. Contain suspicious access and preserve evidence

Real-world scenario: MFA was required, but SMS was not enough

1. An administrator accesses a sensitive management portal ↓ 2. Conditional Access requires phishing-resistant MFA ↓ 3. The administrator's earlier SMS-based MFA session is evaluated ↓ 4. The existing authentication does not satisfy the required strength ↓ 5. Microsoft Entra requests step-up authentication ↓ 6. The administrator signs in with a FIDO2 security key ↓ 7. The Authentication Strength requirement is satisfied ↓ 8. Agent Foskett confirms the policy prevented weaker authentication

Immediate containment

Revoke suspicious sessions.
Remove unrecognised authentication methods.
Reset compromised credentials where required.
Review changes to Conditional Access and strength policies.
Confirm privileged-role activity.
Preserve sign-in and audit evidence.

Operational monitoring

Track users unable to satisfy the required strength.
Alert on unusual authentication-method registration.
Review policy exclusions regularly.
Monitor emergency-access account activity.
Measure migration away from weaker methods.
Validate policies after authentication changes.

Common mistakes

Mistake	Why it creates risk	Better practice
Assuming all MFA is equally strong	Phishable methods may remain available for sensitive access.	Match the strength to the account and resource risk.
Enforcing before registration	Legitimate users may be unable to satisfy the policy.	Pilot, register and validate first.
Leaving broad exclusions	Attackers may target accounts outside enforcement.	Keep exclusions minimal, reviewed and documented.
Skipping Report-only mode	Unexpected application and user impact may appear during enforcement.	Review policy evaluation before enabling.
Using one strength for every scenario	The control may be too weak for some resources and impractical for others.	Use a risk-based policy design.
No recovery design	Lost credentials can create emergency exceptions and unsafe workarounds.	Implement verified, tested recovery procedures.

Key takeaways

Authentication Strengths define which method combinations are acceptable for access.
Microsoft Entra provides built-in MFA, passwordless MFA and phishing-resistant MFA strengths.
Custom strengths support specialised organisational requirements.
Authentication Strengths are enforced through Conditional Access grant controls.
Required methods must also be enabled and registered.
Step-up authentication occurs when the existing session does not satisfy the required strength.
Report-only deployment and pilot groups reduce operational risk.
Phishing-resistant MFA should be prioritised for privileged and sensitive access.

Related Agent Foskett resources

Continue developing Microsoft Entra authentication, Conditional Access and investigation skills.

Lesson 15 — Authentication Methods Policies Lesson 4 — MFA and Authentication Methods Lesson 3 — Conditional Access Fundamentals Lesson 5 — Risky Users and Risky Sign-ins OAuth Consent Grant Investigation Microsoft Identity and Access Services

Continue learning

Continue through Microsoft Entra account recovery and identity security, or return to the academy roadmap.

⬅ Previous lesson

Lesson 15 — Authentication Methods Policies in Microsoft EntraUnderstand method availability, registration, passkeys, FIDO2 and Temporary Access Pass.

🏠 Academy home

Microsoft Entra AcademyReview the roadmap and continue through the identity security learning path.

📘 Next lesson

Lesson 17 — Self-Service Password Reset in Microsoft EntraLearn how SSPR registration, verification, writeback and recovery controls protect account access.

Microsoft Entra Authentication Strengths and Conditional Access

Microsoft Entra Authentication Strengths define acceptable authentication method combinations for Conditional Access policies, including multifactor authentication, passwordless MFA and phishing-resistant MFA.

Microsoft Entra Academy Lesson 16 — Authentication Strengths

This Agent Foskett lesson explains built-in and custom Authentication Strengths, passkeys, FIDO2 security keys, Windows Hello for Business, step-up authentication, report-only deployment and sign-in investigation.