In the first part of this series, we laid the foundation for securing Microsoft Business Premium environments, covering the core security principles and configurations. Now, we shift our focus to authentication—the frontline of identity protection.
Authentication is at the heart of securing any environment, and with evolving threats like phishing, credential stuffing, and AiTM attacks, ensuring robust authentication is non-negotiable. A compromised identity can grant an attacker unrestricted access, making it one of the most common attack vectors.
This post will guide you through the essential authentication configurations in Microsoft Entra, helping SMBs transition towards a secure, passwordless future while enforcing strong authentication methods and eliminating outdated, insecure options.
Without further ado, let’s dive in!
Table of Contents
Why Passwords Aren’t Enough
For decades, passwords have been the default authentication method, but research and real-world attacks have proven that they are one of the weakest links in cybersecurity. No matter how complex a password is, it remains vulnerable to phishing, leaks, and brute-force attacks.
Attackers don’t need to guess passwords when they can simply steal them. That’s why Microsoft, NIST, and cybersecurity experts agree: The safest password is no password at all.
The Data Doesn’t Lie: Passwords Are a Hacker’s Best Friend
Credential-based attacks remain a leading cause of security breaches, and the numbers speak for themselves:
In 2024, the Identity Theft Resource Center reported over 3,200 data breaches, affecting more than 1.7 billion individuals—a staggering 312% increase from the previous year. (The 2024 ITRC Data Breach Report)
The average cost of a data breach reached an all-time high in 2024 of $4.88 million, a 10% increase from 2023. (110 of the Latest Data Breach Statistics)
Reports from Microsoft and Troy Hunts' Have I Been Pwned further validate these concerns:
99.9% of account compromise attacks could be stopped by strong MFA, yet passwords remain the primary form of authentication (Microsoft Security Intelligence).
More than 14 billion passwords have been exposed in data breaches, many of which are still actively used (Have I Been Pwned database).
Once an attacker obtains a password—through phishing, data breaches, or brute force—they can bypass security controls and gain full access to accounts and data.
Passwords Are Only Secure in Theory
Many organizations attempt to improve password security by enforcing complex policies. But does this actually work?
Not really.
Research from Hive Systems’ 2024 Password Security Report demonstrates that modern computing power can crack passwords alarmingly fast.
Here’s how long it takes to brute-force a random bcrypt-encrypted password in a black box scenario (i.e., one that has never been leaked or reused):
While this looks good in theory, these numbers are only accurate for completely random bcrypt-encrypted passwords that have never been leaked or reused.
The reality?
Even an 18-character password that follows best practices could be instantly compromised if it has been leaked in a data breach.
And that’s the real problem: The moment a password is leaked, shared, or stolen, it becomes worthless as a security measure.
The Real Threat: Phishing & AiTM Attacks
Even the most complex passwords can’t protect against phishing.
Attackers don’t need to crack passwords if they can simply trick users into handing them over. Common tactics include:
Phishing Attacks: Deceptive emails or websites that lure users into providing their login information.
Adversary-in-the-Middle (AiTM) Attacks: Intercepting authentication processes to steal session tokens, effectively bypassing multi-factor authentication.
Social Engineering: Manipulating individuals into divulging confidential information through impersonation or psychological tactics.
These attack methods render passwords ineffective—even if they are long and complex.
The solution? Stop using passwords altogether.
The Future: Passwordless Authentication
Because passwords are inherently weak, the industry is shifting toward passwordless authentication, which replaces passwords with phishing-resistant methods such as:
Passkeys (FIDO2): Device-bound authentication method that eliminates passwords entirely.
Temporary Access Passes (TAPs): Time-limited codes that facilitate secure access without the need for permanent passwords.
Certificate-Based Authentication (CBA): A cryptographic authentication method that requires a valid certificate, making impersonation nearly impossible.
By replacing passwords with strong, phishing-resistant authentication, we remove the biggest attack vector while improving security and usability for end users.
What’s Next? Choosing the Right Authentication Methods
Now that we’ve established why passwords alone are not enough, let’s explore:
The authentication methods that truly protect your organization.
The outdated methods that should be disabled immediately.
Other authentication methods that have limited, but valid, use cases.
Let’s dive in.
Microsoft Entra Tenant-Wide Configurations
Building upon our foundation, built in the first part of the series, there are several tenant-wide configurations that every BP environment should implement to strengthen authentication.
Microsoft Business Premium Authentication Configurations
Over the years IAM has evolved, emphasizing the Zero Trust principle of Verify Explicitly.
In a Business Premium environment, we have multiple authentication options to enforce these principles. Let’s explore them.
Authentication Methods: Migrating to Unified Policies
Depending on your tenants status, you’re either:
Migrating from per-user MFA & SSPR settings (as covered in Part 01), or
Already using the unified Authentication Method Policies in Entra.
New tenants automatically support passwordless authentication by default, enabling:
Software OATH
This includes third-party apps, such as Google Authenticator
TAP
Microsoft Authenticator
This is a great starting point, but if you’re migrating, you might need to adjust your configurations. Either way, we still have options to strengthen our authentication.
Recommended Authentication Methods
While the default authentication options offer a good starting point, not all authentication methods are created equal. Let’s explore the best methods for securing Microsoft Entra.
Passkeys (FIDO2) – The Gold Standard
Passkeys should be the default authentication method for any modern environment. Unlike passwords, passkeys are:
Phishing-resistant – Attackers cannot trick users into revealing credentials.
Device-bound – Stored securely on the device and cannot be used elsewhere.
Highly secure – Resistant to brute-force attacks and credential theft.
Microsoft GA’d Passkeys via Microsoft Authenticator in December 2024, and recently removed the requirement for setting up key restrictions, making deployment even simpler.
Passkeys in Microsoft Entra are currently supported for either hardware security keys, such as Yubico Yubikeys or software based via Microsoft Authenticator.
For a deeper dive, check out my post: Passkeys 101: How Microsoft Entra Simplifies Passwordless Authentication
Temporary Access Pass (TAP) – A Bridge to Passwordless
A TAP is a time-limited, password-free authentication method that allows users to securely set up their authentication methods without needing a password. TAPs are especially useful in scenarios such as:
Initial device setup – Allows users to enroll new devices without entering a password.
Security info registration – Enables users to register authentication methods (e.g., Passkeys, Microsoft Authenticator or WH4B) without requiring password input.
Password recovery and reset – Eliminates reliance on passwords when recovering accounts.
By leveraging TAPs, organizations can gradually phase out password-based authentication without impacting usability or security.
Recommended TAP Configuration
Do not enforce One-Time Use TAPs, as it will break device enrollment.
Do issue One-Time TAPs wherever possible though for better security.
Microsoft Authenticator – A Necessary Security Layer
While Passkeys are the preferred authentication method, Microsoft Authenticator Push Notifications remains an essential tool for organizations transitioning towards a passwordless future. It provides multi-factor authentication (MFA) and passwordless sign-in while offering additional security features that can enhance user awareness and prevent MFA fatigue attacks.
Key Configurations for Microsoft Authenticator
Enable Application Name & Geographic Location in Push Notifications
Adding app names in notifications helps users identify where an authentication request is coming from.
Displaying geographic location allows users to spot unauthorized login attempts and reject them immediately.
Disable OTP for Entra Authentication
OTPs within Microsoft Authenticator should be disabled for Entra authentication to prevent users from choosing weaker, phishable authentication methods.
This setting only affects sign-ins where Entra is the identity provider (IdP), meaning it won’t interfere with OTP usage for third-party applications.
Microsoft Authenticator in Companion Applications
Microsoft Authenticator has a companion application feature, which allows MFA prompts and authentication to be handled directly within Office applications on a mobile device—such as Excel, Outlook, or Teams.
This removes the need for the standalone Microsoft Authenticator app, simplifying the user experience.
However, this feature comes with trade-offs:
While it improves usability, it removes the ability to use Passkeys, which should be the ultimate goal for authentication security.
If an organization is focused on a passwordless future, disabling this option is recommended, unless there’s a specific business need for it.
Recommendations
Disable the companion application feature unless absolutely necessary.
Prioritize Passkeys over any authentication method that still involves a user interaction vulnerability.
These 3 authentication methods are my recommendations for any and all organizations as they are highly secure, especially passkeys, on top of being both easy and quick to implement, while CBA is also highly secure, though much more complex to implement and manage.
Discouraged Authentication Methods
Some authentication methods are fundamentally insecure due to their susceptibility to various attacks, including SIM swapping, SS7 attacks, social engineering, phishing, and AiTM attacks. These methods should be disabled outright as soon as possible.
If a C-level executive or a software vendor insists on keeping these methods, it is critical to challenge their necessity and push for stronger alternatives.
SMS-Based Authentication
Sends a time-based OTP to the user’s phone number.
Insecure due to multiple vulnerabilities:
Unencrypted transmission: Makes it susceptible to interception by attackers.
SIM swapping attacks: Allows an attacker to transfer the victim’s phone number to a new device, gaining control over SMS messages.
SS7 attacks: Exploits weaknesses in telecom networks to redirect or intercept messages directly, without the original recipient ever being aware.
Due to these security risks, SMS authentication should be disabled entirely in favor of phishing-resistant methods.
Voice Call-Based Authentication
This method sends an automated call to the users phone, with no user validation.
Attackers can bypass verification if they gain control of the phone number through SIM swapping or SS7 attacks.
No user identity verification—it only requires the victim to press the “#” key, which makes it easily exploitable.
Voice-based authentication should also be disabled completely.
Other Authentication Methods
Some authentication methods do not meet the highest security standards but may still be required for specific use cases, business decisions or regulatory requirements. These methods are neither recommended nor discouraged outright but should be used only when necessary and in a limited scope.
Hardware OATH Tokens
Generates a TOTP that users enter during authentication.
Useful in environments where passwordless authentication is not feasible (e.g., legacy systems or VPNs that do not support modern authentication).
More secure than SMS or voice authentication, as the token is physically possessed by the user.
Risks and Limitations
Does not verify user identity—if an attacker steals the token, they can authenticate without additional security measures.
Susceptible to social engineering attacks, where a user is tricked into providing their OTP to an attacker.
Use Case: Organizations with strict hardware security policies where passwordless methods are not yet an option.
Recommendation: Avoid using this method when phishing-resistant options like Passkeys are available.
Email OTP
Sends an OTP via email for authentication.
Commonly used for guest access in Microsoft Entra B2B scenarios, in scenarios where guests doesn't use Microsoft, and federated accounts from third-party IdPs aren't configured.
Risks and Limitations
Susceptible to AiTM attacks, where attackers steal session tokens and bypass MFA.
Risk of unauthorized email access due to credential stuffing or phishing attacks.
Susceptible to social engineering attacks, where a user is tricked into providing their OTP to an attacker.
Can be intercepted in business email compromise attacks.
Use Case: Only for external B2B users who do not have a Microsoft account.
Recommendation: Limit usage as much as possible and prefer stronger authentication for external access.
Certificate-Based Authentication (CBA)
Very secure—requires a valid cryptographic certificate for authentication. Phishing-resistant authentication method.
Commonly used in environments with a PKI.
Why It’s Not a Primary Recommendation
Requires costly and complex PKI infrastructure, with high administrative overhead.
Does not provide additional security benefits over Passkeys or WH4B.
Use Case: Organizations that already have a PKI in place and want to leverage existing infrastructure.
Recommendation: Do not implement PKI solely for authentication—use Passkeys instead.
Utilizing these configurations allows us to micro manage our organizations allowed methods for authentication requirements.
Authentication Strengths
Since we have established which authentication methods to allow and which to disable, the next step is grouping them into logical authentication strength policies.
Microsoft Entra provides three built-in authentication strengths that can be used in Conditional Access policies:
Multifactor Authentication
Allows all enabled authentication methods, including:
Passwords + MFA, Singlefactor + MFA etc.
Passwordless authentication
Phishing-resistant authentication
Passwordless Authentication
Includes:
Microsoft Authenticator phone sign-in
Phishing-resistant authentication methods
Phishing-Resistant Authentication (Most Secure)
Includes only:
Windows Hello for Business
Passkeys (FIDO2 security keys)
Certificate-Based Authentication (CBA)
Custom Authentication Strength Scenarios
While built-in authentication strengths cover many scenarios, there are cases where custom authentication strength policies are needed.
(Recommended) Scenario 1 – Breakglass Accounts
Require hardware security keys (Passkeys with key restrictions).
Ensures breakglass accounts have the highest level of security while preventing compromise in critical situations.
(Recommended) Scenario 2 – Secure Security Info Registration
Require TAP, Phishing-Resistant or Passwordless methods to register, delete, or modify authentication methods.
Prevents attackers from registering their own MFA methods if they compromise an account.
(Optional) Scenario 3 – Hardware OATH Tokens for Limited Users
For environments that cannot use Microsoft Authenticator or Passkeys.
Common in countries where the Microsoft Authenticator app is restricted (e.g., mainland China).
(Optional) Scenario 4 – High-Security Conditional Access for Authentication Context
Require Passkeys or Microsoft Authenticator phone sign-in for accessing privileged actions, such as PIM elevation or Protected actions.
Step-by-Step Guide: Configuring Authentication Strength in Entra
Configuration of auth strength is handled in the Microsoft Entra portal
Access the authentication strength menu
Navigate to the Microsoft Entra portal.
Go to Protection → Conditional Access.
Select Authentication Strength.
Click New Authentication Strength.
Create the authentication strength policy
In the fly-out menu provide a name and description for the policy.
Choose the authentication methods to be enforced.
In case of specific configurations eg. key restriction for passkeys, configure the settings under Advanced options:
Review & create the policy On the review panel, double check the auth methods and advanced options
For each of the scenarios, the policies would look like this:
Scenario 1 Policy
Breakglass policy enforcing passkeys with key restrictions
Scenario 2 Policy
Security registration policy allowing TAP, PSI or phishing-resistant auth methods
Scenario 3 Policy
Hardware OATH token policy scoping auth methods
Scenario 4 Policy
Auth context policy enforcing passkey or PSI
Authentication strengths for external users
External (B2B) users follow a different authentication model depending on whether cross-tenant trust is enabled:
Scenario 1: Cross-Tenant Trust is Enabled for MFA Claims
When cross-tenant MFA trust is enabled, authentication happens in the external user’s home tenant, meaning:
All authentication methods enabled in their home tenant are accepted.
If their MFA claim meets your Authentication Strength policy, the sign-in attempt is approved without additional MFA prompts.
Your tenant does not re-prompt for MFA unless explicitly required in a Conditional Access policy.
This model leverages existing MFA configurations in the external tenant, reducing login friction while still ensuring security.
Scenario 2: Cross-Tenant Trust is NOT Enabled for MFA Claims
When cross-tenant trust is NOT enabled, authentication is fully enforced within your tenant, meaning:
The external user’s MFA setup is ignored.
Only a restricted set of authentication methods (configured in your tenant) is available for MFA.
Users must complete MFA again inside your environment, even if they authenticated securely in their home tenant.
This adds friction but ensures full control over authentication methods.
Supported Authentication Methods for External Users
The table below outlines which authentication methods are supported based on where authentication occurs:
Authentication method | External tenant | Resource tenant |
Text message as second factor | ✅ | ✅ |
Voice call | ✅ | ✅ |
Microsoft Authenticator push notification | ✅ | ✅ |
Microsoft Authenticator phone sign-in | ✅ | |
OATH software token | ✅ | ✅ |
OATH hardware token | ✅ | |
FIDO2 security key | ✅ | |
Windows Hello for Business | ✅ | |
Certificate-based Authentication | ✅ |
Recommended Approach
I strongly recommend enabling cross-tenant MFA trust while still enforcing specific authentication strengths through Conditional Access scoped for all external users.
This allows you to trust secure authentication methods from external tenants while ensuring that MFA is handled by a more secure authentication method than if not.
If MFA trust is enabled, authentication is handled in the external user’s home tenant, ensuring compatibility with their strongest available method.
If MFA trust is NOT enabled, authentication is handled in your tenant, with stricter control but a more limited set of supported methods.
GDAP (Granular Delegated Admin Privileges) Considerations
It’s important to note that GDAP users are not affected by the above settings.
GDAP access is always treated as if MFA claims are trusted, meaning Conditional Access policies must be used to enforce stricter authentication methods if required.
Example Scenarios
Fabrikam – Cross-Tenant MFA Trust Enabled
Fabrikam collaborates with Contoso and has a strict phishing-resistant MFA policy.
UserA@fabrikam uses a hardware security key (Passkey) to authenticate in their home tenant.
Since Contoso trusts MFA claims, UserA is granted access without needing to authenticate again.
What Happens If UserA Loses Their Security Key?
UserA attempts to sign in using phone sign-in (PSI).
PSI does not meet Contoso’s authentication strength policy, so MFA is required again.
UserA is forced to configure a new hardware security key or configure a software passkey in Microsoft Authenticator to complete authentication before access is granted.
Woodgrove – Cross-Tenant MFA Trust NOT Enabled
UserB@woodgrove needs access to a Contoso Teams site for a project.
Woodgrove uses Windows Hello for Business and enforces device compliance.
Since Contoso does not trust MFA claims, UserA must authenticate again within Contoso’s tenant, even though the MFA from WH4B does fulfill the authentication strength policy.
Authentication Process
UserB logs into Teams using Windows Hello for Business in Woodgrove’s tenant.
Despite strong authentication, Contoso prompts for MFA again.
UserB completes authentication using Microsoft Authenticator push notification, even though it’s a weaker method than their original login.
How to Configure Cross-Tenant Trust in Microsoft Entra
Properly managing cross-tenant authentication trust is essential to balancing security and usability.
Access Cross-Tenant Collaboration Settings
Open the Microsoft Entra portal
Navigate to External Identities → Cross-Tenant Access Settings
Configure Trust Settings
Edit default settings (applies to all external tenants) OR
Select specific organizations under Organizational Settings.
Modify Trust Settings
Click Edit inbound access.
Navigate to the Trust Settings section.
Enable “Trust multifactor authentication from Microsoft Entra tenants”.
Review, Change and Save the policy
Review changes carefully.
Click Save to enforce the updated trust settings.
Security Considerations: Why You Should NOT Trust Compliant Devices
I do not recommend trusting compliant devices from external tenants.
Here’s why:
You cannot enforce or validate compliance policies from external tenants.
By default, device compliance in Microsoft Intune is set to “Compliant” if no policy exists, meaning an external device may not actually meet security requirements.
Instead of trusting external devices, enforce authentication strengths to ensure phishing-resistant MFA is used.
Authentication Context: Enforcing Granular Access Control
Authentication Context in Microsoft Entra Conditional Access provides a more granular way to control access by allowing security policies to be applied directly to specific applications, data, and administrative actions.
Rather than applying broad CA policies to all users and applications, Authentication Contexts work like security tags, enabling fine-tuned restrictions based on specific scenarios.
Use Cases for Authentication Context
Authentication Context is supported across various security and identity governance features, allowing organizations to apply additional security layers to high-risk actions or sensitive data.
Where Authentication Context Can Be Applied:
Feature / Resource | Availability in BP |
Sensitivity Labels | ❌ Not available |
Protected Actions | ✅ Available |
MDCA Session Policies | ❌ Not available |
Privileged Identity Management | ❌ Not available |
Entitlement Management (Access Reviews) | ❌ Not available |
Custom Apps | ✅ Available |
Although most Authentication Context use cases requires higher licensing, BP tenants can still leverage it for Protected Actions and securing custom applications.
Configuring Microsoft Entra Conditional Access Authentication Context
To take advantage of Authentication Context, you must first define the context in Entra, then apply it to resources using Conditional Access.
Access the Authentication Context Menu
Sign in to the Microsoft Entra portal
Navigate to Protection → Conditional Access
Click Authentication Context
Click New Authentication Context
Create the Authentication Context Policy
Provide a name and optional description for the context.
Select a unique identifier (ID) for the context
Enable “Publish to apps” to make the context available for Conditional Access policies
Click Save
At this point, the Authentication Context is created but is not yet enforced on any resource. To apply it, proceed with Conditional Access configuration
Applying Authentication Context in Conditional Access
Managing granular access via the newly created and assigned Authentication context is handled via CA. We target the context as we would with other resources, allowing us the full capabilities of CA, or at least the capabilities included in Microsoft Entra Premium P1.
To target the authentication context select Authentication context in the Target resources menu. Configure the conditions as required, as you would for any other CA policy.
This enforces the requirements for all resources tagged with the authentication context.
Microsoft Entra Protected Actions: Locking Down Critical Admin Tasks
In any Microsoft Entra environment, some administrative actions are too sensitive to be left unprotected—even for privileged users.
While PIM offers time- and approval-based role assignment in Microsoft Entra P2, it is not available in Microsoft BP. Even if PIM were available, it does not provide the same level of granular protection for specific high-risk actions.
This means that in a BP environment, we need an alternative method to secure administrative operations without relying on PIM. That’s where Protected Actions come in.
Why Protected Actions Are Necessary in Business Premium
Since BP tenants don’t have PIM, privileged users maintain persistent admin access rather than temporary role activation. This increases the risk that a compromised admin account or insider threat could make unauthorized changes to critical security settings.
Protected Actions enforce security per action, requiring authentication every time a sensitive task is performed, depending on the CA policies.
Protected Actions allow us to:
Enforce phishing-resistant MFA for specific high-risk admin tasks
Apply real-time session controls, requiring frequent re-authentication
Prevent malicious insiders or compromised accounts from making critical changes
Examples of High-Risk Protected Actions
Action | Why It’s Critical |
|---|---|
Deleting Conditional Access Policies | Could disable MFA, exposing all accounts. |
Modifying Cross-Tenant Access Settings | Could allow unintended external access. |
Changing B2B Collaboration Settings | Could weaken external identity security. |
Modifying Authentication Methods Policies | Could allow insecure authentication methods. |
How It Works
Protected Actions are tagged with an Authentication Context, allowing Conditional Access policies to enforce additional security before an admin can:
Modify security-critical configurations
Adjust external collaboration settings
Delete key security policies
Even if a privileged account is compromised, attackers cannot make critical changes without passing additional authentication requirements.
Next Steps: Configuring Protected Actions
I’ve covered the full setup process—including step-by-step implementation and best practices—in my dedicated blog post:
Conclusion: Locking Down Authentication Like a Pro
Authentication is the frontline of security, and in a Microsoft Business Premium environment, getting it right means embracing phishing-resistant methods, eliminating outdated options, and enforcing strong authentication policies. By configuring Passkeys, TAP, and Conditional Access Authentication Strength, you’re not just securing accounts—you’re future-proofing your identity protection.
These aren’t just best practices; they’re necessities in a world where attackers are constantly looking for the weakest link. Taking control of authentication now means fewer security incidents later.
And now, to take a break from all the serious security talk, here’s a bad joke for you:
Why did the PowerPoint presentation cross the road?
To get to the other slide. 😎
In the next part of this series, we’ll move beyond authentication and tackle authorization—making sure the right people have access to the right resources at the right time. Stay tuned, and until then, lock down your authentication before hackers do it for you! 🚀
🔗 Securing Microsoft Business Premium Series Post Index
Part 02: Your Authentication is Broken—Here’s How to Fix It (You're here!)