Security Defaults vs Conditional Access: Which Does Your Business Actually Need?
Microsoft 365 gives businesses two very different ways to protect sign-ins:
Security Defaults
and:
Conditional Access
Both can improve security.
Both can enforce multi-factor authentication.
But they are not the same product, and they are not designed for the same type of organisation.
The simplest distinction is:
Security Defaults = Microsoft decides the baseline rules for you.
Conditional Access = you decide the access rules based on your business requirements.
For a very small organisation with basic licensing and simple requirements, Security Defaults may be perfectly reasonable.
For a business using Microsoft 365 Business Premium, Intune, managed devices, multiple locations or more sophisticated security controls, Conditional Access is usually the better long-term model.
What Are Security Defaults?
Security Defaults are Microsoft's free, preconfigured identity-security settings in Microsoft Entra ID.
Microsoft says they are intended to give every organisation at least a basic level of identity protection without requiring additional licensing or detailed policy design.
Current Security Defaults protections include:
requiring users to register for MFA
requiring administrators to use MFA
prompting users for MFA when Microsoft determines it is necessary
blocking legacy authentication
protecting privileged Azure management activity
blocking device code flow in applicable tenants
That is a useful baseline.
And it is dramatically better than leaving Microsoft 365 protected by passwords alone.
Security Defaults Are Deliberately Simple
The main advantage is simplicity.
You do not need to design:
user groups
location rules
device-compliance policies
app-specific controls
authentication strengths
complex exclusions
You essentially turn the feature on.
Microsoft manages the baseline behaviour.
That makes Security Defaults particularly suitable for organisations that:
use Entra ID Free
have a simple Microsoft 365 environment
have no requirement for granular access policies
want strong baseline protection quickly
Microsoft itself says Security Defaults are aimed at organisations that want to improve their posture but do not know where to start, particularly those using the free Entra tier.
What Security Defaults Cannot Do
The simplicity is also its limitation.
Security Defaults are largely:
on or off.
You cannot build detailed rules such as:
Require stronger authentication only for administrators.
Require a compliant company laptop for SharePoint.
Block access from selected countries.
Allow a specific device-code application but block device code everywhere else.
Apply different controls to finance than to ordinary users.
For that level of control, you need Conditional Access.
What Is Conditional Access?
Microsoft describes Conditional Access as its Zero Trust policy engine.
It works using:
if this condition occurs → enforce this control
For example:
If an administrator signs into Microsoft 365 → require phishing-resistant MFA.
Or:
If a user accesses company data from an unmanaged device → block access.
Or:
If a mobile user accesses Outlook → require an approved application.
Conditional Access can consider signals such as:
user
group
application
device
location
authentication method
device compliance
platform
risk, with appropriate licensing
This allows security controls to reflect the actual context of the sign-in rather than applying one identical rule to everyone.
Security Defaults vs Conditional Access
Security Defaults Conditional Access
Free baseline Requires appropriate licensing
Microsoft-defined protections Administrator-defined policies
Little customisation Highly customisable
Broad tenant-wide rules Target users, groups, apps and conditions
MFA protection Advanced MFA policy
Blocks legacy authentication Can explicitly control authentication flows
Device code broadly blocked in applicable tenants Device code can be controlled granularly
No managed-device requirement Can require compliant devices
No location-based policy design Can use named locations
Simple to administer Requires planning and testing
The important point is not:
Conditional Access is always better because it has more buttons.
It is:
Conditional Access lets security match business risk much more precisely.
Can You Use Security Defaults and Conditional Access Together?
Not in the normal sense.
Microsoft says organisations moving to Conditional Access should disable Security Defaults and immediately replace the baseline protections with appropriate Conditional Access policies.
That transition needs care.
The dangerous sequence is:
1. Disable Security Defaults.
2. Start planning Conditional Access next week.
You may create a period where protections that previously existed are no longer enforced.
Instead:
1. Design the replacement Conditional Access policies.
2. Test them.
3. Prepare emergency access accounts.
4. Disable Security Defaults.
5. Enable the replacement controls immediately.
6. Verify sign-ins.
Do not create an identity-security gap during migration.
What Changed in Security Defaults in 2026?
There is one particularly important update.
Microsoft says that from 1 July 2026, new Microsoft Entra tenants block device code flow as part of Security Defaults.
Device code flow is legitimate and useful in some scenarios where a device has limited input capability.
Unfortunately, attackers can also abuse it.
An attacker can generate a legitimate Microsoft device code and persuade a victim to enter it on Microsoft's real sign-in page.
The victim may then authenticate the attacker's session.
Blocking device code by default helps reduce this attack route.
However, some organisations genuinely need device code flow for:
command-line utilities
development tooling
shared devices
specialised applications
If you need exceptions, Conditional Access gives you much better control than Security Defaults. Your own current Hamilton Group guidance on device-code phishing already makes exactly that distinction.
Conditional Access Licensing
Conditional Access requires at least:
Microsoft Entra ID P1
for users benefiting from the policies. Microsoft 365 Business Premium includes Entra ID P1 and therefore includes Conditional Access capabilities.
That makes the decision particularly relevant to SMEs.
If the business already pays for:
Microsoft 365 Business Premium
then Conditional Access is not necessarily an additional product you need to buy.
You may already own it.
You simply need to design and configure it correctly.
What Requires Entra ID P2?
Not every Conditional Access capability is included in P1.
Microsoft says risk-based Conditional Access, using user risk and sign-in risk through Microsoft Entra ID Protection, requires Entra ID P2.
That enables policies such as:
If Microsoft identifies the sign-in as high risk → block it.
or:
If the user account is considered risky → require remediation.
That is more sophisticated than ordinary P1 Conditional Access.
So:
Business Premium → strong Conditional Access capability
but:
some advanced risk-driven controls → additional P2 licensing.
Why Conditional Access Matters for Managed Devices
This is one of the strongest reasons for businesses to move beyond Security Defaults.
Imagine an employee signs into Microsoft 365 from:
a personal Windows laptop with no encryption, old patches and unknown security software.
Security Defaults can challenge the identity.
They cannot create the same granular policy model as:
Only permit access when the device is marked compliant by Intune.
Conditional Access can work with Microsoft Intune so access depends on device compliance.
That means a business can require that devices meet standards such as:
encryption enabled
supported operating system
appropriate security configuration
centrally managed
before accessing important organisational resources.
That is a much stronger Zero Trust model.
Should You Exempt the Office From MFA?
Conditional Access makes it technically possible to treat trusted office locations differently.
That does not mean you should automatically create:
If office IP → no MFA.
IP address does not prove:
the correct person is using the account
the device is secure
the network itself has not been compromised
A trusted location can be useful as one signal.
It should not automatically become:
the office is trusted, therefore authentication security no longer matters.
Modern Zero Trust architecture deliberately moves away from that assumption.
Protect Administrators More Strongly
Administrators should not necessarily receive exactly the same access policy as ordinary employees.
They can change:
users
security settings
mailbox configuration
Conditional Access
applications
Microsoft 365 services
That makes administrative identities high-value targets.
Conditional Access allows businesses to create stronger controls around privileged accounts.
For example:
administrator → require strong MFA
administrator → block unsupported authentication
administrator → restrict access conditions
Microsoft's current Security Defaults baseline already requires MFA for a long list of privileged roles, showing how important Microsoft considers administrator protection.
Conditional Access lets you take that principle further.
Use Authentication Strengths Where Appropriate
Not all MFA methods provide equal protection.
A business may decide that ordinary users can use a broader set of approved methods while:
Global Administrators
finance
executives
must use stronger phishing-resistant authentication.
Examples may include:
FIDO2 security keys
passkeys
Windows Hello for Business
Conditional Access can enforce authentication-strength requirements much more precisely than Security Defaults.
This is another good example of why Conditional Access is not simply:
“Security Defaults with more settings.”
It is a policy engine.
Conditional Access and BYOD
Businesses often do not want to block all personal-device access.
But they also may not want company data downloaded freely onto any unmanaged phone.
Conditional Access can work with Intune App Protection policies to create rules such as:
Personal phone can access Outlook, but only through an approved application with corporate-data protections.
That can allow productivity without requiring the organisation to manage every part of an employee's personal device.
Security Defaults cannot provide that level of nuance.
Country Blocking: Useful, but Don't Treat It as Perfect Security
Conditional Access can use named locations.
Businesses may therefore choose to block or restrict sign-ins from countries where they do not operate.
This can reduce attack surface.
But location policies have limitations.
Attackers can use:
VPNs
compromised devices
infrastructure in permitted countries
So:
country blocking = useful additional control
not:
country blocking = account cannot be compromised.
Identity and device controls remain more important.
Emergency Access Accounts Are Essential
A badly designed Conditional Access policy can lock administrators out of the tenant.
Microsoft recommends maintaining two cloud-only emergency access accounts with permanent Global Administrator assignments for break-glass situations.
These accounts should:
not be used for ordinary administration
be strongly protected
be monitored
have credentials stored securely
be tested appropriately
Do this before rolling out restrictive Conditional Access policies.
Do not create the break-glass account after you have already locked everybody out.
Use Report-Only Mode Before Enforcing Policies
Conditional Access should not normally be developed directly against live users by:
create policy → switch On → see who complains.
A better deployment process is:
design → report-only → review impact → pilot → enforce.
Microsoft provides report-only capability specifically so organisations can assess how a Conditional Access policy would affect sign-ins without immediately enforcing the result.
That is especially important for policies involving:
device compliance
locations
authentication strength
legacy workflows
administrators
Test first.
Start With a Small Baseline
Do not build 35 policies on day one.
For a typical SME with the right licensing, a sensible baseline may include controls around:
1. Require MFA appropriately for users.
2. Apply stronger controls to administrators.
3. Block legacy authentication.
4. Control risky authentication flows such as device code where not needed.
5. Require suitable device controls for sensitive resources.
6. Protect emergency access accounts from accidental policy targeting.
7. Add location or application-specific rules only where they solve a genuine requirement.
Microsoft now supplies Conditional Access templates and Microsoft-managed policies covering several of the baseline protections previously supplied by Security Defaults.
Start from a secure foundation.
Then customise.
What About Microsoft-Managed Conditional Access Policies?
This is another increasingly relevant middle ground.
Microsoft provides managed Conditional Access policies covering areas such as:
MFA for administrators
MFA for users
legacy authentication protection
Azure management access
Microsoft's current Security Defaults migration guidance explicitly refers to these managed policies as replacements for baseline protections when Security Defaults is disabled.
That can reduce some of the complexity of moving towards Conditional Access while still giving the organisation more flexibility than Security Defaults.
What About Per-User MFA?
If your tenant has been around for years, you may still see users shown as:
Enabled
Enforced
Disabled
in the old per-user MFA interface.
Do not assume:
Disabled = MFA is not protecting the account.
Microsoft explicitly says that Disabled is the correct per-user status where MFA is being enforced through Security Defaults or Conditional Access.
The old per-user MFA model should not be your strategic approach for a modern Microsoft 365 environment.
Use:
Security Defaults
or:
Conditional Access
as the central policy model.
Which Should a Small Business Choose?
A useful rule is:
Use Security Defaults when:
you have simple requirements
you use Entra ID Free
you do not have Conditional Access licensing
you want a strong baseline with minimal administration
you do not require exceptions or device-based rules
Use Conditional Access when:
you have Microsoft 365 Business Premium or Entra ID P1/P2
you use Intune
you need managed-device requirements
administrators need stronger controls
you need app-specific policies
you need authentication-strength requirements
you need location or platform-based restrictions
your environment has exceptions that Security Defaults cannot accommodate
Microsoft itself says that organisations with P1/P2 licences or complex security requirements should consider Conditional Access rather than Security Defaults.
My Recommendation for Most Business Premium Customers
If a business already has:
Microsoft 365 Business Premium
I would normally prefer a properly designed Conditional Access baseline over relying solely on Security Defaults.
Why?
Because Business Premium already includes:
Entra ID P1
Intune
other security capabilities
and Conditional Access lets those components work together much more effectively.
For example:
Intune knows device compliance
↓
Conditional Access uses that information
↓
Microsoft 365 decides whether the device should receive access
That is considerably more useful than applying only one broad tenant-wide security configuration.
But Security Defaults Are Far Better Than Nothing
Do not read this as:
Security Defaults are weak.
They are not.
Microsoft's 2026 configuration now covers:
MFA registration
administrator MFA
contextual user MFA
legacy authentication blocking
Azure management protection
device-code blocking in applicable tenants.
For a small organisation without premium identity licensing, this is an extremely valuable baseline.
The mistake is not using Security Defaults.
The mistake is assuming Security Defaults provide the same control as a properly designed Conditional Access environment.
The Decision in One Minute
Ask:
Do we have Entra ID P1/P2 or Business Premium?
No
Use Security Defaults unless there is a very specific reason not to.
Yes
Ask:
Do we need device compliance, stronger administrator policies, application-specific access, authentication strengths or exceptions?
If yes:
Conditional Access.
For most managed Business Premium environments, the answer will eventually be Conditional Access.
Migration Checklist: Security Defaults to Conditional Access
Before switching:
1. Confirm appropriate licensing.
2. Review current authentication methods.
3. Identify legacy applications.
4. Identify device-code dependencies.
5. Create two emergency access accounts.
6. Design replacement baseline policies.
7. Use report-only mode.
8. Pilot with a controlled user group.
9. Review sign-in logs.
10. Disable Security Defaults.
11. Immediately activate the replacement Conditional Access controls.
12. Confirm administrators and normal users can authenticate.
13. Monitor failures closely after rollout.
The key rule is:
Never switch Security Defaults off first and design the replacement later.
How Hamilton Group Can Help
Hamilton Group can help businesses move from basic Microsoft 365 identity protection to a properly designed Conditional Access environment.
We can assist with:
Microsoft Entra ID
Security Defaults
Conditional Access
Microsoft 365 Business Premium
MFA
phishing-resistant authentication
Microsoft Intune
compliant-device access
administrator protection
device-code phishing
Microsoft 365 security reviews
The objective is not to create as many Conditional Access policies as possible.
It is to create a small, understandable and tested set of policies that materially reduce risk without unnecessarily disrupting legitimate work.
Visit hgmssp.com or call 0330 043 0069 to discuss Microsoft 365 and identity security.