Conditional Access Best Practices Every Regulated Business Should Follow

In January 2024, Russian state-backed hackers compromised Microsoft’s own corporate network. The method was simple. They password-sprayed a legacy test account that had no MFA, then used that access to read emails from senior executives and security teams. A single account, not covered by Conditional Access policies, opened the door.

If Microsoft’s own tenant was vulnerable because one account slipped through, what does that mean for a 25-person healthcare practice or wealth management firm?

Adelia Risk works with regulated businesses in healthcare, financial services, and government contracting, and conditional access best practices are one of the first Microsoft 365 security configurations we set up for every client. This article walks through the policies that actually matter, why basic MFA isn’t enough anymore, and how to roll them out without locking anyone out. We’ve also built a free checklist you can hand to your IT team.

What Conditional Access Actually Does (and Why Basic MFA Isn’t Enough)

Most people think MFA and Conditional Access are the same thing. They’re not. MFA is a single requirement: prove your identity a second way. Conditional Access is the policy engine in Microsoft Entra ID (formerly called Azure AD) that decides when to require MFA and what else to check before granting access.

With Security Defaults (the free, one-click option Microsoft includes with every tenant), every user gets prompted for MFA on every login. That’s a decent starting point. But Security Defaults can’t be customized. You can’t separate admin accounts from regular users, can’t require stronger authentication for risky sign-ins, can’t enforce device compliance, and can’t block access from countries your company doesn’t operate in.

What is conditional access in Azure? Think of it as a set of “if/then” rules. An admin logging in from an unknown device gets prompted for a passkey. Someone outside the United States gets blocked entirely. And if Microsoft detects a risky sign-in pattern, the user has to re-authenticate. Security Defaults gives you a light switch. Conditional Access gives you a control panel.

Here’s the part most businesses miss: MFA alone doesn’t make you safe. Attackers now use phishing kits that sit between you and Microsoft’s real login page, intercepting your session token after you complete MFA. Microsoft calls these “adversary-in-the-middle” (AiTM) attacks and reports blocking more than 10,000 of them per month. The phishing kits cost as little as $200 on a subscription.

We see this constantly with clients who think enabling MFA has checked the box. It checked a box. The right conditional access best practices check all of them.

The Policies Every Regulated Business Needs

Azure AD conditional access starts with separating your admin accounts from your regular users. Admins are the highest-value targets. If an attacker compromises an admin account, they own your entire tenant. That’s why your admin MFA policy should be stricter than what you require from everyone else.

At a minimum, here’s what every regulated business should configure:

MFA for Admins. A dedicated policy covering all admin directory roles, requiring your strongest authentication method (passkeys, which we’ll get to in a moment). Keep this separate from the user policy so you can tighten settings for admins without disrupting everyone.

MFA for All Users. A second policy covering all users, with exclusions for your break-glass accounts and your IT provider’s admin accounts. Same authentication strength requirement. Target all resources so new apps get covered automatically.

Sign-in Risk and User Risk. These are where conditional access policy examples get interesting. If Microsoft detects something unusual about a login (unfamiliar location, impossible travel, known attacker infrastructure), a sign-in risk policy forces re-authentication. A user risk policy does the same when Microsoft flags something unusual about a user’s recent history. These require Entra ID P2 (which includes Identity Protection) or Microsoft 365 E5 licensing, which costs $9/user/month as a standalone add-on.

The compliance angle matters here.

HIPAA’s proposed 2025 Security Rule update makes MFA mandatory for all access to electronic protected health information, removing the old “addressable” loophole.

The FTC Safeguards Rule already requires MFA for anyone accessing customer financial data, with penalties up to $51,000 per violation.

CMMC Level 2 mandates MFA for all privileged and non-privileged network access. And SOC 2 auditors treat the absence of MFA and access controls as a finding under CC6.1 and CC6.2.

Conditional access best practices aren’t optional for regulated businesses. They’re what auditors check.

Why We Stopped Recommending Number-Matching MFA

Until recently, Adelia Risk recommended number-matching MFA through Microsoft Authenticator to every client. It was the best option available. Then some of our clients were breached.

The attacker used what was likely a highly automated man-in-the-middle attack to harvest not just the username and password, but also the number-matching approval. The user did everything right: they opened the Authenticator app, confirmed the two-digit number, and approved the login.

But the attacker’s proxy server captured the session token the moment Microsoft issued it. The user never knew anything was wrong. Fully authenticated session. Full access.

This is the attack pattern behind the Tycoon 2FA phishing platform, which accounted for roughly 62% of the phishing volume Microsoft blocked by mid-2025. Subscription price for attackers: $200. (We wrote a separate article on types of MFA that can’t protect you from phishing if you want the deeper technical breakdown.)

That experience is why we now require phishing-resistant authentication for every client. Passkeys (FIDO2) resist this attack because the phone confirming the login uses Bluetooth Low Energy to verify it’s physically near the computer making the request. An attacker’s proxy server, sitting in a data center somewhere, can’t fake that proximity check. The MFA approval only works if your phone and your computer are in the same room.

Industry-wide, only about 14% of organizations have adopted phishing-resistant MFA. If you implement it, you’re ahead of 86% of the market.

The conditional access best practices we deploy for clients always include a custom Authentication Strength set to passkeys only. It’s a configuration step in Entra ID that takes about five minutes but makes AiTM attacks significantly harder to pull off. If you’re not sure whether your current MFA setup is vulnerable to this kind of attack, our Microsoft 365 Security Audit checks your authentication methods, Conditional Access policies, and every other configuration that matters.

The Rollout That Doesn’t Lock Everyone Out

The single biggest risk with Conditional Access isn’t getting the policies wrong. It’s getting locked out of your own tenant because you deployed too fast. We’ve seen tenants locked out for days when break-glass accounts get skipped.

Here’s the correct rollout sequence.

Step 1: Set up break-glass accounts. Two cloud-only Global Admin accounts, excluded from every Conditional Access policy you create. Store their passwords somewhere secure (not in a password manager tied to the same Microsoft 365 tenant you might lock yourself out of). Set up alerts so you know if anyone ever logs into them.

Step 2: Build policies in Report-Only mode. Report-Only is a testing mode where Conditional Access evaluates every sign-in against your policies but doesn’t actually enforce anything. You can see what would have been blocked without actually blocking anyone. Run each policy in Report-Only for at least two weeks.

Step 3: Review sign-in logs, then enforce one policy at a time. Don’t flip all your policies from Report-Only to On at once. Turn on the admin MFA policy first. Watch for a few days. Then the user MFA policy. Then the blocking policies.

Common mistake: leaving policies in Report-Only forever. A policy that’s been in Report-Only for two years provides zero protection. Nobody’s going to send you a reminder.

Another common mistake: “All Users” includes guests and service accounts. If you don’t explicitly exclude your break-glass accounts from every policy, a risk-based policy can lock you out of your own tenant. Check your exclusions before saving any policy.

For azure ad security defaults migration specifically, remember that Security Defaults and Conditional Access can’t coexist. The correct order is: create your CA policies in Report-Only, test them, confirm they’re working as expected, then disable Security Defaults. If you disable defaults first, you’ve got a gap where nobody has MFA.

Two Microsoft deadlines worth knowing: per-user MFA settings are being deprecated as of September 30, 2025, and legacy risk policies in Entra ID Protection retire on October 1, 2026. Both need to be migrated to Conditional Access policies before those dates.

Conditional Access Policies That Reduce Your Attack Surface

Once your MFA policies are enforced, the next round of conditional access best practices focuses on blocking the things you don’t need.

Block legacy authentication. Of all the blocking policies, this one matters most. More than 97% of credential stuffing attacks use legacy authentication protocols like POP, IMAP, and SMTP AUTH. These protocols can’t support MFA, which is exactly why attackers love them. Run this policy in Report-Only for two weeks first. In our experience, multifunction printers and older accounting software are the usual culprits when legacy auth blocking breaks something. Find those first, fix them, then enforce.

Block access from outside the United States. Create Named Locations in Conditional Access with allowed countries, then create a policy that blocks everything else. This won’t keep out a determined attacker with a VPN, but it cuts down a massive volume of automated attacks. If your IT provider works from outside the US, exempt their accounts.

Block unsupported operating systems, authentication transfer, and device code flow. If your company only uses Windows and macOS, block sign-ins from platforms you don’t support. While you’re at it, block authentication transfer (which lets users move a signed-in session between devices) and device code flow (used by devices without browsers, like smart TVs). Both have been exploited by attackers, and most businesses don’t need either one.

Stolen session tokens don’t expire on their own. A sign-in frequency policy forces periodic re-authentication, so even if an attacker captures a token, it stops working within hours. Set this as short as your team can tolerate, but no less than 12 hours. Shorter is better for healthcare organizations or financial services firms handling sensitive data.

Require device compliance (if using Intune). If you manage devices through Microsoft Intune, you can require that only compliant devices access Microsoft 365. This is where Conditional Access and device management work together, and it’s the first step toward a zero-trust architecture where only known, trusted computers can log in.

Conditional Access Implementation Timeline

Not everything has to happen at once. Here’s a realistic pace for conditional access best practices at a small or mid-sized business.

Do Today

Do This Week

Do This Month

When Professional Help Makes Sense

The basic conditional access best practices in this article are manageable with Microsoft’s built-in templates and careful testing. If you follow the Report-Only process and don’t skip break-glass accounts, your IT team or MSP can handle it.

The advanced controls are where it gets complex. Device compliance through Intune, zero-trust policies that restrict access to company-managed devices only, hardware security keys for executives, and risk-based policies that require P2 licensing and tuning. These are the policies that produce the biggest security gains but also the most disruption if misconfigured.

We’re not going to pretend every business needs a consultant for this. But if your practice handles protected health information, manages client assets under SEC or FTC oversight, or processes controlled unclassified information for defense contracts, the stakes for getting it wrong are real. Fines, audit findings, and breach notification obligations aren’t abstract risks for HIPAA-covered entities and SEC-registered advisors.

At Adelia Risk, this is the tenant security work we do every day. Whether you work through our free checklist yourself or bring in help, the important thing is getting these policies enforced. If you want a one-time assessment, our Microsoft 365 Security Audit reviews your Conditional Access policies, authentication methods, and 50+ other configuration points. If you want ongoing help, our Virtual CISO service covers the full deployment, from policy design through enforcement and ongoing monitoring.