Microsoft has been steadily tightening identity security across Microsoft Entra, and over the last while, one thing has become very clear to me:
MFA is no longer optional — and Conditional Access is where it’s expected to be enforced.
This isn’t a single announcement or a breaking change.
It’s a direction Microsoft has been moving in consistently, and it’s already affecting how tenants behave in the real world.
Here’s what I’m personally checking in tenants because of this shift.
Microsoft Keeps Tightening Identity Security (Quietly)
Microsoft doesn’t always make one big announcement saying “do this now”.
Instead, changes show up as:
Stronger default security recommendations
More prompts pushing admins toward Conditional Access
Risk-based protections becoming more visible
Older authentication methods slowly becoming liabilities
From an admin point of view, the message is clear:
👉 Identity is the primary security boundary now.
MFA Enforcement Is Becoming Less Optional
I still see environments where MFA is:
Enabled only for admins
Handled purely by Security Defaults
Disabled for “temporary” reasons
Inconsistent across users
That approach is getting riskier every year.
Attack patterns today rely heavily on:
Credential theft
MFA fatigue
Token abuse
So when I look at a tenant, I no longer ask “Is MFA enabled?”
I ask:
Where is MFA enforced, and how predictable is it?
That almost always leads me back to Conditional Access.
What I Always Double-Check First
When reviewing or inheriting a tenant, these are the first things I look at.
1️⃣ Is MFA Enforced via Conditional Access?
If MFA is still relying only on Security Defaults, that’s a red flag for me.
I want:
A clear Conditional Access policy
MFA explicitly required
Scope I can audit and adjust
Predictability matters more than “it kind of works”.
2️⃣ Who Is Excluded (and Why)?
Every tenant has exclusions — but many don’t age well.
I always review:
Break-glass accounts (expected)
Service accounts (sometimes necessary)
Users excluded “temporarily” months or years ago
Exclusions are one of the most common weak points I see.
3️⃣ Are Sign-In Logs Being Used to Validate MFA?
I don’t trust a policy just because it’s enabled.
I check:
Sign-in logs
Conditional Access results
MFA challenges actually being triggered
This step catches mistakes before users or auditors do.
What Still Gets Overlooked (Too Often)
Even in fairly mature tenants, I still see these missed.
Legacy Authentication
Legacy authentication is still one of the easiest attack paths if it’s left open.
If MFA is enforced but legacy auth is allowed:
MFA can be bypassed
Password-only attacks still work
This needs to be checked explicitly — not assumed.
Overconfidence in “We Have MFA”
This is probably the biggest issue.
Having MFA:
Doesn’t mean it’s enforced everywhere
Doesn’t mean it’s enforced consistently
Doesn’t mean it’s enforced correctly
That’s why I prefer simple, clear Conditional Access policies over assumptions.
Why I Keep Coming Back to Conditional Access
For me, Conditional Access is where:
MFA becomes enforceable
Exceptions are visible
Risk can be reduced incrementally
Changes can be tested safely
Security Defaults are fine to start with —
but Conditional Access is how I make MFA reliable.
If You’re Reviewing Your Tenant Right Now
If you’re already thinking about this, I’d start with:
Confirming how MFA is enforced
Checking exclusions
Reviewing sign-in logs
Verifying legacy authentication status
Small checks here prevent big problems later.
Related Guide (Step-by-Step)
I recently documented exactly how I enforce MFA using Conditional Access, including:
Disabling Security Defaults
Creating the MFA policy
Validating everything using sign-in logs
👉 Step-by-step guide available on ITBlogs.ca
Final Thought
Microsoft isn’t making MFA optional —
they’re making weak identity security uncomfortable.
Conditional Access is how I stay ahead of that curve without breaking user experience.