Security Defaults vs. Conditional Access: Which Your Business Actually Needs

Microsoft 365 gives businesses two main ways to apply baseline identity protection: Security Defaults and Microsoft Entra Conditional Access.

Both can require multi-factor authentication and block older authentication methods, but they are designed for different types of organisation.

Security Defaults provides a free, Microsoft-managed security baseline with very little configuration. Conditional Access provides detailed control over who can sign in, which devices they can use, which applications they can access and what should happen when a sign-in appears risky.

The important question is not simply which option is “better.”

It is:

Which option gives your business the protection it needs without creating unnecessary complexity or leaving important access routes exposed?

This guide compares Security Defaults and Conditional Access, explains their licensing requirements and helps you decide which approach fits your organisation.

What Are Security Defaults?

Security Defaults is a set of preconfigured identity-security protections built into Microsoft Entra ID.

It is designed for organisations that want a basic security baseline without building and maintaining their own Conditional Access policies.

When Security Defaults is enabled, Microsoft applies protections intended to:

• Require users to register for multi-factor authentication
• Require administrators to use MFA
• Prompt users for MFA when Microsoft considers it necessary
• Block legacy authentication protocols
• Protect privileged administrative activity
• Reduce common password-based attacks

Microsoft provides Security Defaults to tenants without additional Microsoft Entra premium licensing. It is intended primarily for organisations that need straightforward protection and do not require granular policy control. 

What Is Conditional Access?

Conditional Access is Microsoft Entra’s policy engine for controlling access to cloud applications and resources.

It evaluates signals associated with a sign-in and then decides whether to:

• Allow access
• Block access
• Require MFA
• Require a particular authentication strength
• Require a compliant or managed device
• Require an approved application
• Restrict the user’s session
• Require a password change
• Apply different controls according to risk

Microsoft describes Conditional Access as its Zero Trust policy engine because it combines identity, device, application, location and risk signals before granting access. 

Conditional Access is not one security setting. It is a framework for building several policies around your organisation’s requirements.

Security Defaults and Conditional Access Cannot Be Used Together

Security Defaults and Conditional Access are alternative approaches.

They are not intended to operate together.

When an organisation starts creating Conditional Access policies, Security Defaults must be disabled. Microsoft explains that Conditional Access can recreate the protections provided by Security Defaults while adding much greater granularity. 

This means moving from Security Defaults to Conditional Access is not simply a matter of switching on extra features.

You must make sure your Conditional Access policies replace the protections you are removing.

Otherwise, disabling Security Defaults can create gaps in:

• MFA coverage
• Administrator protection
• Legacy authentication blocking
• User registration
• Application access
• Guest security

Security Defaults vs. Conditional Access at a Glance

The Main Advantage of Security Defaults

The main advantage of Security Defaults is simplicity.

A small organisation can enable one setting and receive a reasonable identity-security baseline without designing a complete policy architecture.

This reduces the likelihood of mistakes such as:

• Forgetting to protect an application
• Leaving a group outside MFA coverage
• Configuring conflicting policies
• Accidentally excluding an administrator
• Leaving legacy authentication enabled
• Creating policies that nobody monitors

Security Defaults is particularly valuable when an organisation has:

• A small number of users
• No dedicated IT or security team
• Basic Microsoft 365 requirements
• No complex external access
• No device-management strategy
• No special application exceptions
• No requirement for location-based controls

For these businesses, a Microsoft-managed baseline may be safer than a badly maintained set of custom policies.

The Main Limitation of Security Defaults

Security Defaults does not provide meaningful customisation.

You cannot use it to define rules such as:

• Require a compliant device for payroll
• Block access from selected countries
• Require a security key for administrators
• Allow web-only access from personal computers
• Require stronger MFA for finance employees
• Apply different controls to guests
• Restrict access to one sensitive application
• Block one authentication flow while allowing another
• Require reauthentication for high-risk sessions

Security Defaults applies Microsoft’s standard approach to the tenant.

That is useful when your needs are simple, but restrictive when different users, devices and applications carry different levels of risk.

The Main Advantage of Conditional Access

Conditional Access allows security controls to reflect the actual context of an access request.

A policy can evaluate:

• Who the user is
• Which group they belong to
• Which application they are accessing
• Whether they hold an administrative role
• Whether the device is managed
• Whether the device is compliant
• Where the connection originates
• Whether the sign-in appears risky
• Which authentication method was used
• Whether the user is internal or external

This allows the organisation to apply stronger protection where it matters most.

For example:

IF:

A finance employee accesses the accounting platform

AND:

The device is not compliant

THEN:

Block access

Another policy might say:

IF:

An administrator accesses an administrative portal

THEN:

Require phishing-resistant MFA

A third might say:

IF:

A user accesses Microsoft 365 from a personal device

THEN:

Allow browser access but prevent downloads

Security Defaults cannot provide this level of control.

Conditional Access Licensing

Conditional Access generally requires Microsoft Entra ID P1 or a licence that includes it.

Microsoft 365 Business Premium includes Microsoft Entra ID P1 and therefore includes Conditional Access. Microsoft’s current licensing guidance also confirms that customers with qualifying Microsoft Entra premium licences can use Conditional Access features. 

Licences that may include Conditional Access depend on the current Microsoft product structure, but common examples include:

• Microsoft Entra ID P1
• Microsoft Entra ID P2
• Microsoft 365 Business Premium
• Microsoft 365 E3
• Microsoft 365 E5
• Enterprise Mobility + Security E3 or E5

Microsoft licensing changes over time, so verify the exact rights attached to your subscription before deployment.

Users benefiting from Conditional Access policies must be licensed appropriately.

What Does Security Defaults Cost?

Security Defaults is available without the extra premium licence required for Conditional Access.

That makes it appropriate for businesses using plans such as Microsoft 365 Business Basic or Business Standard that do not otherwise include Microsoft Entra ID P1.

However, the correct comparison is not simply:

Free vs. paid

It is:

Simple baseline vs. policy-driven access security

Conditional Access may justify its cost when the organisation needs to protect:

• Sensitive customer data
• Financial systems
• Remote workers
• Personal devices
• Administrators
• Contractors
• Multiple business applications
• Regulated information
• Hybrid environments

A lower licence cost is not a saving when it leaves the business unable to enforce necessary controls.

When Security Defaults Is Usually Enough

Security Defaults may be appropriate when all of the following are broadly true:

• The business is small.
• The Microsoft 365 environment is simple.
• Users access similar applications.
• Most devices and users have comparable risk.
• The business does not need location-based policies.
• There are no complex guest or contractor requirements.
• No applications require special exclusions.
• The organisation does not need managed-device enforcement.
• There is no dedicated team to maintain Conditional Access.
• The current licence does not include Microsoft Entra ID P1.

A small business with ten employees using Outlook, Teams, OneDrive and SharePoint from company laptops may receive meaningful value from Security Defaults.

It is far better than leaving MFA and legacy authentication unmanaged.

When Security Defaults Is Not Enough

Security Defaults is unlikely to be sufficient when the organisation needs any of the following.

Different Rules for Different Users

Examples include:

• Stronger controls for administrators
• Different treatment for contractors
• Restrictions for temporary workers
• Additional protection for finance or HR
• Exemptions for specific service or resource accounts

Managed-Device Requirements

You may want to allow access only from:

• Intune-compliant devices
• Microsoft Entra joined computers
• Hybrid-joined business devices
• Approved mobile applications

Security Defaults cannot build these device-specific policies.

Location-Based Controls

Some businesses need to:

• Block access from countries where they do not operate
• Apply additional checks outside trusted networks
• Restrict administrative access to defined locations
• Treat anonymous proxies or unusual networks differently

Conditional Access provides named locations and network-based conditions, although location should never be treated as the only security control.

Phishing-Resistant Authentication

Administrators and high-risk employees may need to use:

• Passkeys
• FIDO2 security keys
• Windows Hello for Business
• Certificate-based authentication

Conditional Access authentication strengths can require specified categories of authentication instead of accepting any method that technically qualifies as MFA.

Application-Specific Protection

Payroll may require a compliant device, while normal email may remain available through a restricted browser session.

Conditional Access can apply different policies to different resources.

Risk-Based Access

Organisations with the appropriate licensing can use risk signals to block or challenge suspicious users and sign-ins.

Examples include:

• Leaked credentials
• Unusual sign-in properties
• Suspicious IP addresses
• Atypical travel
• Known malicious activity

Controlled Personal-Device Access

A business may want employees to read email from a personal phone without allowing them to download confidential documents onto an unmanaged laptop.

Conditional Access can combine device state, application controls and session restrictions.

The Risk of Moving to Conditional Access Too Early

Conditional Access is more capable, but it is also easier to configure incorrectly.

A badly designed deployment can:

• Lock out administrators
• Leave users without MFA
• Exclude important applications
• Break business systems
• Permit unmanaged devices accidentally
• Create conflicting rules
• Depend on permanent exceptions
• Generate support problems
• Provide a false sense of security

Conditional Access should not be enabled simply because it sounds more advanced.

It requires:

• Appropriate licences
• Policy planning
• Sign-in-log analysis
• Emergency access accounts
• Testing
• Documentation
• Ongoing monitoring
• Named ownership

A simple Security Defaults configuration may be safer than a complex Conditional Access environment that nobody understands.

The Risk of Staying With Security Defaults Too Long

The opposite problem also exists.

As a business grows, Security Defaults may become too limited.

Warning signs include:

• Broad use of personal devices
• More remote or international access
• Several external contractors
• Increased administrative roles
• Sensitive cloud applications
• Compliance obligations
• Cyber-insurance requirements
• More complex Microsoft 365 licensing
• Need for passkeys or security keys
• Repeated demand for exceptions
• Difficulty controlling downloads
• Greater concern about token theft

When the business begins asking for exceptions, conditions and different treatment for different user groups, it has probably outgrown Security Defaults.

Security Defaults and MFA

Security Defaults requires MFA registration and applies MFA according to Microsoft’s managed security logic.

However, it does not provide the same detailed control over:

• Which users are included
• When MFA is required
• Which applications trigger MFA
• Which methods satisfy the requirement
• Which sessions require reauthentication
• Whether a managed device can reduce prompts
• Whether high-risk access should be blocked

Conditional Access can require MFA for all users and all resources, or apply stronger controls to particular scenarios.

Microsoft recommends that organisations using Conditional Access establish an all-user MFA baseline and begin in report-only mode before enforcement. 

Security Defaults and Legacy Authentication

Security Defaults blocks legacy authentication, which is a major benefit.

Older authentication protocols may not support modern MFA and can provide attackers with a route around stronger sign-in controls.

When moving to Conditional Access, you must create an equivalent policy that blocks legacy authentication.

Do not assume Conditional Access blocks it automatically.

A transition that disables Security Defaults before creating the replacement policy could reopen older authentication routes.

Before enforcement:

1. Review sign-in logs for legacy authentication.
2. Identify affected applications and users.
3. Upgrade or replace incompatible systems.
4. Create tightly controlled temporary exceptions only when unavoidable.
5. Apply a Conditional Access policy blocking legacy authentication.
6. Monitor failures after activation.

Security Defaults and Administrators

Security Defaults provides specific protections for privileged administrative accounts.

Conditional Access allows a more deliberate design.

For example, you can require administrators to:

• Use phishing-resistant MFA
• Access portals only from compliant devices
• Reauthenticate more frequently
• Avoid access from untrusted locations
• Use separate privileged identities
• Meet stronger session requirements

Administrative accounts have greater potential impact when compromised, so they should not necessarily follow the same policy as ordinary users.

Security Defaults and Guest Users

Businesses increasingly collaborate with:

• Customers
• Suppliers
• Contractors
• Consultants
• Partner organisations

Security Defaults provides basic tenant-wide protection, but Conditional Access gives more control over external identities.

You may need to:

• Require MFA for guests
• Trust MFA claims from selected partner tenants
• Block personal email identities
• Restrict access from unmanaged guest devices
• Apply limited browser sessions
• Review guest access periodically
• Block access after project completion

Guest access often becomes one of the reasons an organisation needs Conditional Access.

Security Defaults and Personal Devices

Security Defaults can require authentication, but it cannot provide a detailed device-access strategy.

Conditional Access can help distinguish between:

• A managed company laptop
• A compliant mobile phone
• An unmanaged home computer
• A partner device
• An unknown browser
• A high-risk endpoint

Possible policies include:

• Full access from compliant company devices
• Web-only access from unmanaged devices
• No downloads from personal computers
• Block access to finance and HR from unmanaged devices
• Require approved mobile applications
• Require application-protection policies

This is especially important for hybrid and remote work.

Security Defaults and Risk-Based Security

Security Defaults uses Microsoft-managed logic but does not provide the organisation with configurable risk policies.

Conditional Access can integrate with risk information when the correct licensing is available.

A policy might:

• Require MFA for medium-risk sign-ins
• Block high-risk sign-ins
• Require a secure password change for risky users
• Require a compliant device after risk detection

Risk-based controls help the organisation respond when a session looks different from the user’s normal behaviour.

Security Defaults and Session Controls

Authentication is only the beginning of a cloud session.

Conditional Access can apply controls such as:

• Sign-in frequency
• Persistent browser-session restrictions
• Application-enforced restrictions
• Conditional Access App Control
• Limited access from unmanaged devices

These controls are relevant because attackers may steal session tokens after MFA has been completed.

Security Defaults does not provide comparable custom session management.

Can You Create Exceptions in Security Defaults?

Security Defaults is intentionally not designed for granular exceptions.

That simplicity is one of its strengths, but it also means organisations with legitimate technical exceptions may struggle.

Conditional Access can exclude:

• Named emergency access accounts
• Specific user groups
• Approved service scenarios
• Particular applications
• Controlled device accounts

Exceptions should always be:

• Narrow
• Documented
• Approved
• Monitored
• Time-limited where possible
• Reviewed regularly

A broad exception can undermine the policy around it.

Emergency Access Accounts

Before deploying Conditional Access, create and test emergency access accounts.

These accounts provide a route back into the tenant when:

• A policy is configured incorrectly
• An authentication provider becomes unavailable
• Administrators lose access to their normal MFA methods
• A device-compliance issue blocks the IT team

Emergency accounts should be:

• Cloud-only
• Separate from normal administrator accounts
• Strongly protected
• Closely monitored
• Excluded only from policies that could cause total lockout
• Stored through a secure recovery process
• Tested periodically

Security Defaults does not give you the same exception design, while Conditional Access places the responsibility for safe exclusions on the administrator.

Report-Only Mode

Conditional Access policies can be created in report-only mode.

This means Microsoft Entra evaluates the policy but does not enforce it.

Administrators can then see:

• Which sign-ins would be blocked
• Who would be required to use MFA
• Which applications would be affected
• Whether device requirements would fail
• Whether exclusions work
• Which legacy applications may break

Report-only mode is one of the most important advantages of Conditional Access.

It allows the organisation to test security controls against real activity before creating disruption.

However, report-only policies provide no actual protection. Every policy should have:

• An owner
• A review period
• A decision date
• A path to enforcement or removal

A Recommended Conditional Access Baseline

A typical small or medium-sized business moving from Security Defaults may consider policies covering:

1. Require MFA for all users and all resources.
2. Block legacy authentication.
3. Require phishing-resistant MFA for administrators.
4. Protect security-information registration.
5. Block high-risk sign-ins where appropriate.
6. Require secure password change for high-risk users.
7. Require compliant devices for sensitive applications.
8. Restrict access from unmanaged devices.
9. Block device code flow unless required.
10. Protect administrative portals.
11. Apply controls to guest users.
12. Exclude and monitor emergency access accounts.

This is only a starting point.

Policies must reflect the organisation’s licences, devices, applications, users and risk tolerance.

Do Not Build One Giant Policy

A single enormous Conditional Access policy becomes difficult to test and troubleshoot.

Use separate policies with clear names.

Examples include:

CA - Require MFA - All Users

CA - Block Legacy Authentication

CA - Require Phishing-Resistant MFA - Administrators

CA - Require Compliant Device - Finance Applications

CA - Block Device Code Flow

CA - Protect Security Information Registration

Clear policy separation makes it easier to understand why a sign-in was allowed or blocked.

Use Clear Naming and Documentation

Every Conditional Access policy should record:

• Purpose
• Included users
• Excluded users
• Target resources
• Conditions
• Grant controls
• Session controls
• Owner
• Approval
• Creation date
• Review date
• Related business requirement

Avoid names such as:

Test Policy

New MFA

Policy 2

Working CA Final

A tenant with unclear policies quickly becomes difficult to support safely.

Security Defaults Is Better Than Bad Conditional Access

Conditional Access should not be seen as automatically superior in every situation.

Security Defaults may be the better choice when:

• There is no qualified administrator.
• Nobody will monitor policy changes.
• The company has very simple requirements.
• Premium licensing is not available.
• There is no reliable emergency-access process.
• The business cannot support policy testing.
• The alternative is a collection of improvised rules.

Microsoft manages and updates the Security Defaults baseline.

A business managing Conditional Access takes responsibility for ensuring its own policy set remains complete.

Conditional Access Is Better Than Outgrown Security Defaults

Conditional Access is usually the better choice when:

• The business has Microsoft 365 Business Premium or Entra ID P1/P2.
• Users work remotely.
• Personal devices are used.
• Sensitive applications require stronger controls.
• Administrators need phishing-resistant MFA.
• Contractors and guests require different treatment.
• The organisation has compliance obligations.
• Device compliance matters.
• Sign-in risk needs to affect access.
• Security exceptions must be managed explicitly.
• The tenant contains several applications and user groups.

In these circumstances, Security Defaults may protect the average sign-in but fail to address the organisation’s most important risks.

Security Defaults vs. Conditional Access for Small Businesses

A small business does not automatically need the simplest option.

The correct decision depends on complexity and risk, not only employee count.

A 15-person legal, financial or healthcare organisation may handle highly sensitive information and require:

• Managed devices
• Restricted personal-device access
• Strong administrator authentication
• Guest controls
• Location policies
• Session restrictions

That business may benefit from Conditional Access despite its small size.

A 50-person organisation with simple access patterns and limited IT management may prefer Security Defaults until it can properly support a more advanced deployment.

Security Defaults vs. Conditional Access for Microsoft 365 Business Premium

Businesses with Microsoft 365 Business Premium already have access to Microsoft Entra ID P1 and Conditional Access. 

That does not mean Security Defaults must immediately be replaced.

It means the business has the option to build a more tailored access strategy.

A planned transition should:

1. Review the current Security Defaults protections.
2. Inventory users, devices and applications.
3. Create emergency access accounts.
4. Design replacement Conditional Access policies.
5. Start policies in report-only mode.
6. Pilot with selected users.
7. Check sign-in logs.
8. Resolve legacy and technical dependencies.
9. Enable policies gradually.
10. Disable Security Defaults only as part of the controlled transition.
11. Verify the replacement policies are enforced.
12. Monitor failures and suspicious activity.

How to Check Whether Security Defaults Is Enabled

In the Microsoft Entra admin centre:

1. Open Microsoft Entra ID.
2. Go to Overview.
3. Select Properties.
4. Find Manage security defaults.
5. Review whether the setting is enabled.

Access to this setting requires an appropriate administrative role.

Do not disable it until replacement protections are ready.

How to Check Whether Conditional Access Is Configured

In the Microsoft Entra admin centre:

1. Open Protection.
2. Open Conditional Access.
3. Review the policy list.
4. Check each policy’s state.
5. Identify policies set to Report-only, On or Off.
6. Review included and excluded users.
7. Review targeted applications.
8. Check grant and session controls.
9. Review policy results in the sign-in logs.

The existence of policies does not prove they provide complete coverage.

Look for:

• Users excluded broadly
• Applications omitted
• Policies left off
• Policies permanently in report-only mode
• Missing legacy-authentication blocking
• No administrator-specific protection
• No emergency account exclusions
• Overlapping or contradictory policies

How to Choose the Right Option

Use these questions.

Choose Security Defaults when:

• You need a straightforward baseline.
• You do not have Entra ID P1 or P2.
• Your user and application environment is simple.
• You do not need granular exceptions.
• You cannot reliably administer Conditional Access.
• You want Microsoft to manage the baseline behaviour.

Choose Conditional Access when:

• You need control over users, devices, applications or locations.
• Your licences include Microsoft Entra ID P1 or P2.
• You need phishing-resistant MFA.
• You have sensitive or regulated applications.
• You allow remote or personal-device access.
• You have guests or contractors.
• You need risk-based or session controls.
• You can test, document and monitor the policies.

Do not choose either option casually when:

• Your environment contains legacy applications.
• User accounts run automation.
• Teams or specialist devices use unusual authentication flows.
• You lack emergency access accounts.
• Nobody owns identity security.
• Your licensing is unclear.

These issues should be resolved as part of the implementation.

Migration Checklist: Security Defaults to Conditional Access

Before migration:

• Confirm the required licences.
• Inventory all users and guests.
• Review authentication-method registration.
• Identify legacy authentication.
• Identify service and automation accounts.
• Inventory applications.
• Review device-management coverage.
• Create emergency access accounts.
• Document current Security Defaults protection.

Build replacement policies:

• Require MFA for all users.
• Block legacy authentication.
• Protect administrators.
• Protect security registration.
• Define device requirements.
• Define guest access.
• Configure risk policies where licensed.
• Create necessary, narrow exceptions.

Test:

• Use report-only mode.
• Review sign-in logs.
• Run a pilot.
• Test emergency access.
• Test mobile and desktop applications.
• Test guests and contractors.
• Test scripts and integrations.
• Communicate with users.

Enforce:

• Enable policies gradually.
• Disable Security Defaults as part of the planned switch.
• Confirm policies apply.
• Monitor failures.
• Remove temporary exceptions.
• Review regularly.

Common Mistakes

Disabling Security Defaults Before Replacement Policies Exist

This can leave users and administrators without equivalent protection.

Assuming Conditional Access Automatically Requires MFA

Conditional Access does nothing until policies are created and enabled.

Targeting Only Administrators

Ordinary users can still provide attackers with email, documents and internal access.

Targeting Only Microsoft 365

Other cloud applications may remain outside the baseline.

Excluding Too Many Users

Large exclusions become permanent attack paths.

Forgetting Legacy Authentication

Modern MFA policies may not protect older authentication protocols.

Requiring Compliant Devices Before Intune Is Ready

Users may be locked out because their devices have not been enrolled or evaluated correctly.

Failing to Create Emergency Accounts

A policy error can lock out the administration team.

Leaving Policies in Report-Only Mode

A report-only result is not enforcement.

Never Reviewing Policies

Applications, devices, users and risks change over time.

Final Thoughts

Security Defaults and Conditional Access both improve Microsoft 365 identity security, but they solve different problems.

Security Defaults is a straightforward Microsoft-managed baseline. It provides valuable MFA and legacy-authentication protection without requiring premium Conditional Access licensing or detailed policy management.

Conditional Access is the better choice when your organisation needs to make access decisions based on users, applications, devices, locations, authentication methods, sessions or risk.

The decision is not simply:

Small business equals Security Defaults, large business equals Conditional Access.

A better rule is:

Simple environment and limited administration: use Security Defaults.
Complex access requirements and the ability to manage them properly: use Conditional Access.

Do not disable Security Defaults until complete replacement policies have been designed, tested and documented.

Conditional Access offers greater security control, but only when it is maintained carefully. Security Defaults offers less flexibility, but its simplicity can be a genuine security advantage.

The correct option is the one your organisation can license, operate, monitor and support reliably.

Not Sure Whether Your Business Needs Security Defaults or Conditional Access?

Hamilton Group can review your Microsoft 365 environment and help you choose the right identity-security approach.

Our experts can help you:

• Review your current Security Defaults configuration
• Audit Conditional Access policies
• Confirm Microsoft Entra licensing
• Design an all-user MFA baseline
• Block legacy authentication
• Protect administrator and finance accounts
• Deploy phishing-resistant MFA
• Restrict access from unmanaged devices
• Secure guest and contractor access
• Configure risk-based policies
• Create and test emergency access accounts
• Plan a safe migration from Security Defaults

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to discuss your Microsoft 365 security requirements.