Conditional Access Policy Sets for a 20-Person Business

A 20-person business does not need 40 Conditional Access policies.

It needs a small, understandable policy set that blocks the most common attack routes without locking employees out of Microsoft 365 every time they change phone, travel or work from home.

Microsoft Entra Conditional Access is the policy engine that evaluates signals such as the user, application, authentication method, device state, risk and location before deciding whether to allow access, require another control or block the sign-in. 

For a small organisation, the best strategy is usually to begin with five or six core policies, test each one in report-only mode and add complexity only when there is a clear business requirement.

What Is Conditional Access?

Conditional Access lets you create rules that follow a simple structure:

If these users access these resources under these conditions, require this control.

For example:

If any employee signs in to Microsoft 365, require multifactor authentication.

Or:

If somebody tries to use an older authentication protocol, block the attempt.

Conditional Access requires Microsoft Entra ID P1 or P2 licensing. Businesses without suitable licensing can use Security Defaults for baseline protections, although Security Defaults offers less flexibility than a custom Conditional Access design. 

Why Small Businesses Should Keep the Policy Set Simple

A large enterprise may need separate policies for countries, departments, workloads, device types, contractors, administrators and privileged applications.

A 20-person company usually does not.

Too many policies can create:

• Overlapping controls
• Confusing exclusions
• Unexpected sign-in prompts
• Difficult troubleshooting
• Increased lockout risk
• Rules that nobody understands six months later

The goal is not to create the most sophisticated configuration possible.

It is to establish a small number of policies that address the organisation’s most realistic risks:

• Stolen passwords
• Phishing
• Legacy authentication
• Administrator compromise
• Unmanaged device access
• Suspicious sign-ins
• Accidental tenant lockout

Before You Create Any Policies

Create Emergency Access Accounts

Before enforcing Conditional Access, create and test emergency access—or break-glass—accounts.

Microsoft recommends excluding emergency access accounts from policies that block or restrict sign-in. Otherwise, a misconfigured requirement for MFA, a compliant device or another control could prevent administrators from recovering the tenant. 

For a small organisation, maintain at least one properly protected emergency account, and preferably follow Microsoft’s broader emergency-access design guidance.

The account should:

• Be cloud-only
• Have a strong, separately stored credential
• Not be used for ordinary administration
• Be monitored for any sign-in
• Be tested periodically
• Be excluded from restrictive Conditional Access policies

Do not exclude normal IT administrator accounts. The emergency account exists for recovery, not convenience.

Inventory Your Users and Devices

Before requiring device compliance or stronger authentication, confirm:

• Which users have Microsoft 365 accounts
• Which accounts are administrators
• Which devices are company-owned
• Whether devices are enrolled in Intune
• Which employees use personal phones
• Whether guests need access
• Whether any legacy applications remain

A policy cannot distinguish between a deliberate exception and an overlooked dependency.

Use Clear Policy Names

A useful naming structure might be:

CA01 – Require MFA – All Users

CA02 – Block Legacy Authentication

CA03 – Require Strong MFA – Administrators

CA04 – Require Compliant Device – Company Data

CA05 – Block High-Risk Sign-Ins

CA06 – Restrict Security Info Registration

Include a number, purpose and audience. Avoid names such as New Policy, Test MFA or Final CA Policy 2.

Policy 1: Require MFA for All Users

The first core policy should require multifactor authentication for everyone accessing Microsoft 365.

Microsoft provides current guidance for requiring MFA across all users and resources, using either the built-in MFA control or an authentication-strength requirement where appropriate. 

A practical configuration is:

Users: All users
Exclude: Emergency access accounts
Resources: All resources
Grant: Require multifactor authentication
Initial state: Report-only

This protects:

• Employees
• Managers
• Administrators
• Remote users
• Guests, depending on your chosen scope

Do not protect only administrators. Ordinary employee accounts can still expose email, files, customer contacts and internal Teams conversations.

Authentication Strength or Standard MFA?

Authentication strengths let you specify which methods satisfy the policy.

For example, you could require phishing-resistant authentication for administrators while allowing standard MFA for ordinary users.

However, Microsoft notes that external authentication methods are currently incompatible with authentication-strength policies, so organisations using an external MFA provider may need the general Require multifactor authentication grant control instead. 

For a small business:

• Require standard MFA for all users.
• Require phishing-resistant authentication for administrators where practical.
• Move other high-risk users, such as finance staff, to stronger methods gradually.

Policy 2: Block Legacy Authentication

Legacy authentication uses older client protocols that may not support modern MFA and Conditional Access controls correctly.

Microsoft provides a dedicated Conditional Access policy design for blocking these requests and recommends starting it in report-only mode. 

A suitable configuration is:

Users: All users
Exclude: Emergency access accounts
Resources: All resources
Conditions: Legacy authentication clients
Grant: Block access
Initial state: Report-only

Review sign-in logs before enforcement to identify:

• Printers
• Scanners
• Old mobile devices
• Monitoring tools
• Business applications
• SMTP dependencies

Do not create broad permanent exclusions for old systems. Give each dependency an owner and a migration plan.

Policy 3: Require Stronger Protection for Administrators

Administrator accounts carry far more risk than ordinary employee accounts.

Create a dedicated policy for users holding privileged Microsoft Entra and Microsoft 365 roles.

A practical configuration might be:

Users: Directory roles or a controlled administrator group
Exclude: Emergency access accounts
Resources: All resources
Grant: Require phishing-resistant MFA or a suitable strong authentication control
Initial state: Report-only

Administrators should ideally use:

• FIDO2 security keys
• Passkeys
• Windows Hello for Business
• Other phishing-resistant methods supported by the organisation

Also consider separate administrator accounts rather than granting Global Administrator rights to the same identity used for email and everyday browsing.

The purpose of this policy is not simply to prompt administrators more frequently. It is to make stolen passwords and ordinary phishing kits less useful.

Policy 4: Require Compliant Devices for Sensitive Access

If the business manages Windows laptops through Microsoft Intune, Conditional Access can require devices to be marked compliant.

Microsoft’s recommended device-compliance policy includes all users, excludes emergency access identities and requires a compliant device before access is granted. 

However, do not enable this policy until devices are enrolled and reliably reporting compliance. Microsoft’s broader Zero Trust guidance states that devices must be enrolled in Intune before compliance requirements can be enforced successfully. 

For a 20-person business, it may be sensible to begin by applying this requirement to:

• Exchange Online
• SharePoint Online
• OneDrive
• Microsoft Teams
• Administrative portals

Possible configuration:

Users: Employees with company-managed devices
Exclude: Emergency access accounts and approved BYOD users
Resources: Microsoft 365 or selected sensitive resources
Grant: Require device to be marked compliant
Initial state: Report-only

For personal mobile devices, Intune app-protection policies may be more practical than requiring full device enrolment.

Policy 5: Block or Challenge Risky Sign-Ins

Microsoft Entra ID Protection can identify user and sign-in risk signals. Risk-based Conditional Access requires Microsoft Entra ID P2 licensing.

Possible responses include:

• Require MFA for medium or high sign-in risk
• Require secure password change for high user risk
• Block high-risk sign-ins

Microsoft recommends excluding emergency access accounts from risk-based Conditional Access policies to prevent recovery lockouts. 

For a small organisation with P2 licensing, a sensible starting point is:

Medium or high sign-in risk: Require MFA
High sign-in risk: Consider block access
High user risk: Require secure password change where supported

Risk-based policies can react to changing threat signals without relying solely on fixed IP addresses or countries.

Do not assume every risky sign-in is malicious. Ensure somebody reviews risk detections and helps legitimate users recover access.

Policy 6: Protect Security-Information Registration

Attackers who compromise an account may try to register their own authentication method.

Create a policy controlling access to security-information registration so that users can update MFA methods only under safer conditions.

Depending on your licensing and device model, you might require:

• MFA
• A trusted or compliant device
• An approved network location
• Strong authentication

This policy is especially useful when users register new Authenticator methods, passkeys or security keys.

Test carefully because an overly restrictive registration policy can make onboarding and lost-phone recovery unnecessarily difficult.

Should You Block Countries?

Country-based blocking can be useful when a small company operates only in one or two regions and never expects sign-ins from elsewhere.

Microsoft’s deployment guidance describes using named locations to block countries or regions from which the organisation does not expect sign-ins, while excluding emergency access accounts. 

However, location policies can cause problems when employees:

• Travel
• Use mobile networks
• Connect through corporate VPNs
• Work with international suppliers
• Use cloud services that appear from unexpected locations

Treat country blocking as an additional control—not the foundation of the policy set.

A suspicious sign-in can still originate from the same country as your business.

What About Guests?

Decide deliberately how guest users should be handled.

Common options include:

• Require MFA for all guests
• Trust MFA claims from approved partner tenants
• Block guests from sensitive applications
• Require acceptance of terms of use
• Review guest access periodically

Do not exclude all guests from the main MFA policy merely because external collaboration exists.

A compromised supplier account can still expose Teams and SharePoint data.

Use Report-Only Mode First

Every new Conditional Access policy should begin in report-only mode unless it is responding to an active emergency.

Report-only mode evaluates sign-ins and records what the policy would have done without enforcing the decision.

Microsoft recommends phased deployment, starting with a few core policies, testing and monitoring their effect before turning each one on. Policy templates are also created in report-only mode by default. 

Run the policy long enough to capture:

• Normal daily work
• Remote access
• Mobile access
• Month-end tasks
• Guest collaboration
• Administrator activity
• Less frequently used applications

Then review:

• Sign-in logs
• Report-only results
• Users who would be blocked
• Devices failing compliance
• Applications affected
• Unexpected exclusions

Use the What If Tool

Conditional Access includes a What If tool that simulates policy evaluation for a chosen user, application, device platform, location and other conditions.

Use it before enabling a policy to test scenarios such as:

• Finance employee on a company laptop
• Director using a personal phone
• Administrator accessing the Entra portal
• Guest opening a SharePoint site
• Emergency account signing in
• User travelling abroad

Microsoft recommends combining the What If tool with report-only testing to understand the result of new policies. 

Avoid Too Many Exclusions

Exclusions are often the weakest part of a Conditional Access configuration.

Common bad exclusions include:

• All executives
• All administrators
• An entire office
• Large service-account groups
• Every user experiencing a support issue

Every exclusion should have:

• A documented reason
• A business owner
• A compensating control
• An expiry or review date
• Minimal scope

When a user experiences a problem, investigate why the policy is failing rather than immediately adding them to a bypass group.

A Recommended Small-Business Policy Set

For many 20-person businesses, this is a sensible starting point:

Optional additions might include:

• Country blocking
• Guest restrictions
• Session controls
• Terms of use
• App-protection requirements for mobile access

Do not add optional policies merely because they appear in a template library. Add them when they address a documented risk.

Conditional Access Rollout Checklist

Before rollout:

• Confirm Entra ID P1 or P2 licensing.
• Create and test emergency access accounts.
• Inventory administrators, users, guests and devices.
• Confirm Intune enrolment before requiring compliance.
• Review legacy authentication activity.
• Agree on a naming standard.

For each policy:

• Create it in report-only mode.
• Exclude only emergency access accounts initially.
• Test with the What If tool.
• Review real sign-in results.
• Pilot with a small group.
• Document the owner and purpose.
• Enable gradually.

Ongoing:

• Review exclusions monthly.
• Check report-only policies that were never completed.
• Investigate failed sign-ins.
• Test emergency access accounts.
• Review administrator assignments.
• Remove obsolete policies.
• Reassess the design after major business changes.

Final Thoughts

A 20-person business does not need an enterprise-sized Conditional Access estate.

It needs a small collection of policies that are easy to understand, test and maintain.

Begin with the controls that provide the greatest reduction in risk:

1. Require MFA for everyone.
2. Block legacy authentication.
3. Apply stronger authentication to administrators.
4. Require compliant devices where management is ready.
5. Respond to risky sign-ins if P2 licensing is available.
6. Protect authentication-method registration.

Create every policy in report-only mode first. Exclude emergency access accounts, test normal workflows and resist the temptation to solve every support problem with a permanent exclusion.

The strongest policy set is not the one with the most rules.

It is the one your business understands, monitors and can recover from safely.

Need Help Configuring Conditional Access?

Hamilton Group can help your business design a practical Microsoft Entra Conditional Access policy set without unnecessary complexity.

Our experts can help you:

• Review Microsoft Entra licensing
• Create emergency access accounts
• Require MFA securely
• Block legacy authentication
• Protect administrator accounts
• Configure compliant-device access
• Introduce risk-based policies
• Test policies in report-only mode
• Review exclusions and sign-in failures
• Build a documented Conditional Access baseline

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to secure Microsoft 365 access without making everyday work harder.