Protect Microsoft Entra ID Sign-Ins from Phishing & Session Theft

This guide shows you how to harden Microsoft Entra ID (formerly Azure AD) sign-ins against phishing and session theft. You’ll learn to configure phishing-resistant authentication, enforce conditional access policies, and monitor for suspicious activity. These steps are essential for any organization using Microsoft 365 or other Entra ID-connected apps.

What You’ll Need

Global Administrator or Conditional Access Administrator role in Entra ID.
Access to the Microsoft Entra admin center (entra.microsoft.com).
A test user account (non-admin) to validate policies before rolling out broadly.
If using FIDO2 security keys or Windows Hello for Business, have the hardware/software ready.

Step-by-Step

Enable phishing-resistant authentication methods. Go to Protection > Authentication methods > Policies. For each method (e.g., FIDO2 security keys, Windows Hello for Business, Microsoft Authenticator), click “Enable” and target specific users or groups. Start with a pilot group. Phishing-resistant methods like FIDO2 keys and certificate-based authentication (CBA) are the gold standard because they don’t rely on shared secrets that can be phished.
Disable or restrict legacy authentication. Legacy protocols (IMAP, POP, SMTP, etc.) don’t support modern MFA and are a common vector for password spray and session token replay. In Conditional Access > Policies, create a new policy: Name it “Block Legacy Auth”. Under Assignments > Users, select “All users”. Under Cloud apps or actions, select “All cloud apps”. Under Conditions > Client apps, check “Exchange ActiveSync clients” and “Other clients” (which includes legacy auth). Set Access controls > Grant to “Block access”. Enable the policy and save.
Create a Conditional Access policy requiring MFA for all users. This is your baseline. Create a new policy: Name “Require MFA for all users”. Assign to “All users”. Under Cloud apps, select “All cloud apps”. Under Access controls > Grant, check “Require multi-factor authentication” and select “Require one of the selected controls”. Enable and save.
Add a sign-in risk policy to block risky sessions. In Protection > Conditional Access > Policies, create “Sign-in risk policy”. Assign to all users. Under Conditions > Sign-in risk, select “High” (and optionally “Medium”). Under Access controls, choose “Block access” for high risk, or “Require MFA” and “Require password change” for medium. This uses Entra ID’s risk detection to block sessions that show signs of compromise, like impossible travel or anonymous IP addresses.
Implement a user risk policy to remediate compromised accounts. Create another policy: “User risk policy”. Assign to all users. Under Conditions > User risk, select “High”. Under Access controls, select “Block access” and “Require password change” (if available). This forces users with compromised credentials to reset their password before they can sign in again.
Set token lifetime and session controls. In your MFA policy (or a separate session policy), under Session, set “Sign-in frequency” to a value like “1 hour” or “8 hours” depending on your security needs. Also set “Persistent browser session” to “Never”. This reduces the window in which a stolen session token can be used.
Enable Conditional Access authentication strength. In Protection > Conditional Access > Authentication strengths, create a new authentication strength. Name it “Phishing-resistant”. Select the methods: “FIDO2 security keys”, “Windows Hello for Business”, and “Certificate-based authentication” (if you have it). Then in your MFA policy, under Access controls > Grant, select “Require authentication strength” and choose this policy. This ensures users must use a phishing-resistant method, not just any MFA.
Use Microsoft Entra ID Protection to monitor and respond. Go to Protection > Identity Protection. Review the “Risky users” and “Risky sign-ins” reports regularly. Set up automated responses via the policies you created. You can also export logs to Sentinel or your SIEM for further analysis.
Educate users about phishing. Security settings alone aren’t enough. Train users to recognize phishing attempts, never enter passwords on untrusted sites, and report suspicious emails. Use Attack Simulation Training in Microsoft 365 Defender to run simulated phishing campaigns.
Monitor and audit sign-in logs. In Monitoring > Sign-in logs, review for anomalies like failed MFA attempts, unfamiliar locations, or unusual device fingerprints. Set up alerts for these activities using Azure Monitor or Microsoft Sentinel.

Common Mistakes

Not excluding emergency access accounts. You must exclude at least one break-glass account from all Conditional Access policies to avoid being locked out. Create a dedicated emergency account with a long, complex password and no MFA, and store it securely.
Applying policies to all users at once without testing. Always pilot with a small group first to avoid locking out legitimate users.
Leaving legacy authentication enabled. Even with MFA, legacy protocols can bypass it. Make sure your block policy is comprehensive.
Ignoring sign-in risk policies. Risk policies are powerful but require tuning. Start with High risk only and gradually include Medium if you have a good user experience.
Using SMS or voice call as the only MFA method. These are vulnerable to SIM swapping and phishing. Prefer app-based or hardware-based methods.

Tips

Use Conditional Access “Report-only” mode to test policies before enforcing them. You can see the impact without blocking users.
Combine sign-in frequency with token protection. Token protection (in preview) binds tokens to the device, making session theft harder. Enable it for sensitive apps.
Leverage device compliance. Require devices to be compliant (Intune managed) in your MFA policy to prevent access from unmanaged devices.
Regularly review your authentication methods. Remove old or unused methods like app passwords.
Enable self-service password reset (SSPR) to reduce helpdesk calls, but ensure it also requires MFA.

Troubleshooting

Users are locked out: Check the sign-in logs to see which policy is blocking them. Temporarily disable the policy in Report-only mode, or add the user to an exclusion group. Verify they have a registered authentication method.
MFA prompts not appearing: Ensure the user has registered a method in the Security Info page. Also check that the Conditional Access policy is applied to the correct apps and users.
FIDO2 keys not working: Check if the browser supports WebAuthn. Some older browsers don’t. Also ensure the key is registered in the user’s security info.
Policy conflicts: Conditional Access policies are evaluated in order. If you have multiple policies, the most restrictive applies. Use the “What If” tool in Conditional Access to simulate sign-ins and see which policies would apply.
High false positives in risk policies: Adjust the risk thresholds or exclude trusted locations (like your office IP ranges) from the risk conditions.

Frequently Asked Questions

What is the best MFA method to prevent phishing?

FIDO2 security keys and Windows Hello for Business are the most phishing-resistant because they use public-key cryptography and don’t transmit passwords or codes that can be intercepted. Certificate-based authentication is also strong.

Do I need a third-party MFA provider?

No, Microsoft Entra ID includes robust MFA capabilities. Third-party providers may be useful for legacy apps, but for most organizations, the built-in methods suffice.

How often should users be prompted for MFA?

It depends on your risk tolerance. For high-security environments, set sign-in frequency to 1 hour. For general use, 8-24 hours is common. Remember that session tokens can be stolen, so shorter is safer.

What is token protection and how does it help?

Token protection (preview) binds tokens to the device they were issued to, so if a token is stolen, it can’t be used from another device. Enable it for sensitive apps in Conditional Access.

Can I block sign-ins from specific countries?

Yes, use Conditional Access with a condition on the location. Be careful to exclude trusted locations like your headquarters to avoid blocking legitimate users.

How do I handle users who don’t have smartphones?

Use FIDO2 security keys or hardware OATH tokens. Alternatively, you can use temporary access passes (TAP) for onboarding, but for regular use, a hardware key is the best option.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →