{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihhshy2ekxwksibazadk77fv5r35rco2inii75jt3qku3i2s6zpba",
    "uri": "at://did:plc:zwrtxk7dxjuph4rvm63q4diu/app.bsky.feed.post/3mngnwlto37b2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiaafkbpzy7rtbqwsachlzlh5pm546blt5bhwbcr7ix3ffjgu3clpu"
    },
    "mimeType": "image/png",
    "size": 536718
  },
  "description": "SMBs must adopt Zero Trust with Azure Conditional Access — MFA, device compliance and legacy-auth blocking to reduce breaches.",
  "path": "/zero-trust-azure-conditional-access-smb-guide/",
  "publishedAt": "2026-06-04T02:47:41.000Z",
  "site": "https://azure.criticalcloud.ai",
  "tags": [
    "Azure Conditional Access",
    "Microsoft Entra ID P1",
    "Microsoft Entra ID",
    "Microsoft 365 Business Premium",
    "Microsoft Intune",
    "Azure Optimization Tips, Costs & Best Practices",
    "Azure Identity Protection",
    "FIDO2",
    "Windows Hello for Business",
    "Log Analytics workspace",
    "Graph PowerShell",
    "Continuous Access Evaluation",
    "How to Set Up Azure Multi-Factor Authentication",
    "5 Azure Security Best Practices for SMBs",
    "Checklist for Securing Azure Data in Transit",
    "5 Steps to Implement Zero Trust in Azure"
  ],
  "textContent": "**Zero Trust security is essential for SMBs** as cyberattacks increasingly target smaller organisations. Azure Conditional Access transforms Zero Trust principles into practical policies, safeguarding users and resources without requiring large IT teams.\n\nKey takeaways:\n\n  * **Zero Trust** means always verifying access requests, limiting privileges, and assuming breaches.\n  * **SMBs benefit** by reducing data breach risks by up to 80% and improving compliance.\n  * **Azure Conditional Access** enforces security measures like multi-factor authentication (MFA), device compliance, and location-based restrictions.\n  * **Microsoft licensing options** include cost-effective solutions for SMBs, such as Microsoft Entra ID P1 (£6/user/month) or Business Premium (£20/user/month).\n\n\n\nThis guide covers setup, key policies (e.g., MFA, blocking legacy authentication), and risk management to help SMBs secure their operations efficiently.\n\n## Getting Started with Azure Conditional Access\n\n### How Azure Conditional Access Works\n\nAzure Conditional Access acts like a smart gatekeeper, standing between your users and your resources. It evaluates several factors - known as signals - before deciding whether to grant or block access.\n\nThe system operates on an if-then basis: _if_ certain conditions are met, _then_ specific actions are enforced. For instance, if someone logs in from an unknown device, they might need to complete multi-factor authentication (MFA) before gaining access. Signals that are analysed include the user’s identity, the device’s compliance status, IP location, the application being accessed, and any risk indicators.\n\n> \"Conditional Access policies help you balance security and productivity by enforcing security controls when needed and staying out of the user's way when they aren't.\" - Microsoft Entra\n\nThese policies kick in after the initial authentication step. This means users first attempt to log in before any additional checks are applied.\n\nOnce you understand how Conditional Access works, the next step is to prepare your Azure tenant by ensuring all the necessary prerequisites are ready.\n\n### Preparing Your Azure Tenant for Conditional Access\n\nTo implement a Zero Trust strategy effectively, your Azure tenant needs to be set up with a few critical components.\n\nFirst, ensure you have an active Microsoft Entra tenant with Microsoft Entra ID P1 licences. You’ll also need the Conditional Access or Security Administrator role assigned to manage policies.\n\nIt’s also wise to create at least two emergency access accounts - often called break-glass accounts. These accounts are excluded from all Conditional Access policies and serve as a backup in case you get locked out during the setup process.\n\nIf your tenant is currently using Security Defaults, you’ll need to disable them before activating Conditional Access policies, as the two features can’t run simultaneously.\n\nFinally, before enforcing any policies, test them in report-only mode for at least seven days. This lets you observe how the policies would affect users and devices without causing any disruptions.\n\n> \"Conditional Access policies provide significant configuration flexibility, but this flexibility means you need to plan carefully to avoid undesirable results.\" - Microsoft Entra ID\n\n### Licensing Options for SMBs\n\nFor small and medium-sized businesses, Microsoft offers several licensing options to fit different needs and budgets.\n\nThe **Microsoft 365 Business Premium** plan, priced at about £20 per user/month, includes Microsoft Entra ID P1, device management through Microsoft Intune, and the full suite of Microsoft 365 apps. It’s an all-in-one solution that eliminates the need to combine separate licences.\n\nIf your business only requires Conditional Access, you can opt for the standalone **Microsoft Entra ID P1** licence, which costs around £6 per user/month. For businesses wanting more advanced features, such as risk-based policies that automatically respond to suspicious sign-ins, the **Microsoft Entra ID P2** licence is available for roughly £9 per user/month. These advanced policies rely on Microsoft Entra ID Protection, which is exclusive to the P2 licence.\n\nLicence | Conditional Access | Risk-Based Policies | Approx. Cost (per user/month)\n---|---|---|---\nMicrosoft Entra ID P1 | ✅ | ❌ | ~£6\nMicrosoft Entra ID P2 | ✅ | ✅ | ~£9\nMicrosoft 365 Business Premium | ✅ | ❌ | ~£20\n\nFor SMBs already using Microsoft 365, upgrading to Business Premium often makes financial sense. It offers Conditional Access and device management together without needing extra add-ons. If you’re looking for more tips on saving money while enhancing security and performance, check out Azure Optimization Tips, Costs & Best Practices.\n\n## How To Configure Conditional Access Policies in Entra ID: Zero Trust with MFA + Compliant Devices\n\n## Implementing Identity Protection with Azure\n\nBuilding on your Conditional Access setup, integrating Identity Protection adds another layer to your Zero Trust approach.\n\n### What is Azure Identity Protection?\n\nAzure Identity Protection, part of **Microsoft Entra ID P2** , continuously monitors user accounts for potential security breaches. By analysing hundreds of signals during each sign-in, it determines the risk level of the activity.\n\nIt identifies two main types of risks. **Sign-in risk** evaluates the likelihood that a specific login attempt is unauthorised. For instance, when a user seems to log in from London and Tokyo within an hour (a scenario often called \"impossible travel\"). **User risk** , on the other hand, assesses the chance of long-term account compromise, such as when credentials are leaked.\n\nRisk Type | Example Detection | What It Signals\n---|---|---\n**Sign-in Risk** | Impossible travel, unfamiliar sign-in properties, anomalous token | A specific login attempt appears suspicious\n**User Risk** | Leaked credentials, password spray attack | The account itself might be compromised\n\n### Connecting Identity Protection to Conditional Access\n\nIdentity Protection integrates seamlessly with the Conditional Access engine, allowing for dynamic responses to detected risks. For example, if a sign-in is flagged as \"Medium\" or \"High\" risk, Conditional Access can automatically prompt the user for additional verification before granting access.\n\nTo ensure clarity in troubleshooting and remediation, keep your sign-in risk and user risk policies separate. Combining them into a single policy can lead to confusion and make diagnosing issues more challenging.\n\n### Risk Mitigation Policies for SMBs\n\nSmall and medium-sized businesses (SMBs) can benefit significantly from these risk assessments by implementing core mitigation policies. For instance, enforce **multi-factor authentication (MFA)** for sign-ins flagged as \"Medium\" or \"High\" risk. Similarly, require a password reset for users identified as \"High\" risk. These measures empower users to resolve issues themselves, reducing the workload on IT teams.\n\nBefore applying these policies, ensure two key prerequisites are met:\n\n  * **Enable Password Hash Synchronisation (PHS):** Without this, Azure cannot detect leaked credentials.\n  * **Register all users for MFA:** This prevents users from being locked out and needing manual assistance during enforcement.\n\n\n\nFinally, always exclude your break-glass emergency accounts from these policies to maintain access during critical situations.\n\n###### sbb-itb-6ec400b\n\n## Key Conditional Access Policies for SMBs\n\nBuilding on earlier Identity Protection measures, these policies help solidify your Zero Trust framework. For SMBs, a recommended 2026 baseline includes eight key policies - three of which are critical: requiring MFA for all users, blocking legacy authentication, and enforcing device compliance.\n\nBefore implementing these policies, ensure break-glass emergency accounts are set up and excluded from these rules. If you haven't done so already, create two cloud-only accounts and securely store their FIDO2 keys.\n\n### Enforcing Multi-Factor Authentication (MFA)\n\nMFA is one of the most effective tools for securing accounts. As Alex Weinert put it:\n\n> \"Your password doesn't matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.\"\n\nConfigure an MFA policy that automatically applies to all resources, including new applications, ensuring they are protected from the start. Use Authentication Strengths to define acceptable methods. For regular users, the built-in multifactor authentication strength works well. However, for administrators, implement phishing-resistant MFA using tools like FIDO2 keys or Windows Hello for Business.\n\nApply the policy to a group (e.g., CA-InScope-AllUsers) rather than individual accounts for easier management. Start with report-only mode for seven days to review sign-in logs and identify any service accounts or shared mailboxes that may need adjustments.\n\n### Blocking Legacy Authentication\n\nLegacy protocols such as POP3, IMAP, SMTP AUTH, and Exchange ActiveSync lack the ability to prompt for MFA, creating a significant security gap. Over 99% of password spray attacks exploit these legacy protocols, so blocking them can eliminate most of these threats.\n\nTo implement this, go to Conditional Access settings, navigate to Conditions → Client apps, select \"Exchange ActiveSync clients\" and \"Other clients\", and configure the access control to block. As with MFA, start in report-only mode to identify any legitimate traffic from legacy devices or scripts. Once identified, migrate these to modern authentication methods like OAuth or Managed Identities before fully enforcing the block.\n\n### Device Compliance and Risk-Based Access Controls\n\nAfter setting up MFA and blocking legacy authentication, device compliance policies provide an additional safeguard. Requiring compliant devices for accessing critical admin portals ensures that even valid credentials cannot be used on unmanaged devices to make tenant-wide changes.\n\nFor mobile devices, Intune App Protection Policies (MAM) offer a practical solution without requiring full device enrolment. These policies ensure corporate data remains within managed apps like Outlook and Teams. For unmanaged browsers, session controls can enforce shorter sign-in frequencies and disable persistent browser sessions, requiring users on shared or unmanaged devices to re-authenticate regularly.\n\nBefore fully enforcing these policies, use the \"What If\" tool to simulate their impact and verify configurations.\n\n### Summary of the Eight Core Policies\n\nThe table below outlines the eight key Conditional Access policies:\n\nPriority | Policy | Target | Control\n---|---|---|---\n1 | Block Legacy Authentication | All Users | Block\n2 | Require MFA for All Users | All Users | Authentication Strength (MFA)\n3 | Phishing-Resistant MFA for Admins | All Admin Roles | Phishing-Resistant MFA\n4 | Compliant Device for Admin Portals | All Admin Roles | Require Compliant Device\n5 | Require MFA for Guests | All Guest Users | Require MFA\n6 | Block Unexpected Countries | All Users | Block (exclude allowed countries)\n7 | App Protection on Mobile | All Users | Require App Protection Policy\n8 | Session Controls for Unmanaged Devices | All Users | Sign-in frequency / Persistent browser off\n\nUse the \"What If\" tool in the Entra portal to test sign-ins and ensure policies are applied correctly. This reduces the risk of unexpected disruptions when moving from report-only to enforced mode.\n\n## Rolling Out and Monitoring Zero Trust Policies\n\nZero Trust with Azure Conditional Access: 3-Phase SMB Rollout\n\nThe rollout and monitoring phase is essential for maintaining the Zero Trust environment. Implementing the eight core policies requires careful planning to avoid disrupting users or locking anyone out.\n\n### Starting with a Pilot Deployment\n\nEstablishing a stable baseline of eight policies typically takes **6–8 weeks**. This timeline is deliberate - rushing the process can lead to gaps or unintended user blocks, especially for small and medium-sized businesses.\n\nThe most effective approach involves three phases: starting with administrators and core identity protections, moving to a small pilot group, and then expanding to all users. For the pilot phase, create a dedicated group (e.g., `CA-InScope-Pilot`) with **five to ten** users representing a cross-section of your organisation. This helps identify potential issues before rolling out changes organisation-wide.\n\nThe sequence of the rollout is also critical. Here's a suggested phased approach:\n\nPhase | Target Group | Focus\n---|---|---\n**Phase 1: Foundation** | Admins & test group | Block legacy authentication, implement phishing-resistant MFA for administrators\n**Phase 2: Core** | All users (phased) | MFA for all users, MFA for guests, mobile app protection\n**Phase 3: Advanced** | All users | Risk-based policies (P2), session controls for unmanaged devices\n\nEach policy should remain in report-only mode for at least seven days, allowing you to review sign-in logs before enforcing it. Importantly, do not disable Security Defaults until your \"Require MFA for all users\" policy is stable. This avoids leaving a gap without MFA protection.\n\nOnce the pilot demonstrates stability, the focus shifts to ongoing monitoring and adjustments.\n\n### Monitoring and Adjusting Policies\n\nPilot feedback is invaluable for fine-tuning policies. Use sign-in logs to identify recurring issues, such as shared mailboxes, service accounts, or legacy printers, which often cause failures. Tools like the **What If tool** in the Entra portal and the **Conditional Access Insights and Reporting workbook** can simulate sign-in scenarios, helping you visualise the combined impact of all policies. This ensures comprehensive coverage and prevents unexpected disruptions when policies move to enforced mode.\n\nFor extended log retention, connect your sign-in logs to a **Log Analytics workspace**. This not only increases retention beyond the default 30 days but also enables custom alerts, including notifications for break-glass account usage.\n\n### Keeping Policies Up to Date\n\nOver time, Conditional Access policies can drift due to staff changes, evolving roles, or temporary exceptions becoming permanent. To prevent this, conduct a **quarterly review** of exclusion groups and sign-in logs. These reviews help align configurations with current business needs and address emerging threats.\n\nAfter every policy change, use **Graph PowerShell to export policies to JSON**. This creates a dated snapshot for auditing, version control, or rolling back misconfigurations. Keep in mind that Entra ID has a limit of **240 Conditional Access policies per tenant** across all states. Consolidating policies and using a clear naming convention, like `CA01-AllUsers-RequireMFA`, will keep your policy list manageable as it grows.\n\n## Conclusion: Strengthening SMB Security with Azure\n\nZero Trust isn’t something you purchase - it’s a strategy you develop over time. For small and medium-sized businesses (SMBs), **Azure Conditional Access** provides a strong foundation for building this approach, even without a dedicated security team. For example, requiring **multi-factor authentication (MFA)** can lower the risk of account compromise by more than 99%, while blocking legacy authentication effectively counters most password spray attacks.\n\nA big step forward for many SMBs is transitioning from **Security Defaults** to a more layered Conditional Access baseline. As Tiago Carvalho, a Microsoft 365 Consultant, aptly says:\n\n> \"Security Defaults are a floor, not a destination.\" – Tiago Carvalho, Microsoft 365 Consultant\n\nRefining these policies as your organisation grows is key. Tools like **Continuous Access Evaluation (CAE)** and the **Conditional Access Optimisation Agent** allow policies to adjust dynamically based on real-time security signals, reducing the need for manual adjustments.\n\nAdditionally, always keep two **cloud-only break-glass accounts** on hand. These accounts, secured with **FIDO2 keys** and excluded from Conditional Access policies, are critical for recovering administrative access in case of misconfigurations.\n\n## FAQs\n\n### Which Conditional Access policies should we implement first to avoid lockouts?\n\nTo avoid lockouts, start by setting up and testing emergency access (break-glass) accounts. These accounts should be excluded from all policies to ensure they can be used for recovery access if needed. When deploying new policies, begin with **report-only mode** for at least seven days. This allows you to monitor their impact before full implementation.\n\nFor production environments, roll out changes in stages. First, enforce **multi-factor authentication (MFA)** for administrative roles. Next, block legacy authentication methods. Finally, extend MFA requirements to all users. To streamline access management, use named exclusion groups.\n\n### Do we need Microsoft Entra ID P2, or is P1 enough for our SMB?\n\nFor many small and medium-sized businesses (SMBs), **Microsoft Entra ID P1** offers the key Conditional Access tools they need. These include features like **multifactor authentication (MFA)** and **context-based access policies**. Moving up to **P2** is only necessary if you require more advanced capabilities, such as **risk-based Conditional Access** or **automated identity protection**.\n\nIn fact, a lot of SMBs find that **Microsoft 365 Business Premium** , which already includes P1, meets their security requirements effectively.\n\n### How can we secure service accounts and legacy devices when blocking legacy authentication?\n\nWhen stopping legacy authentication, it's better to migrate outdated clients and service accounts to modern authentication rather than creating exceptions in your policies. For service accounts that can't use updated protocols, consider applying tailored security measures through Conditional Access for workload identities.\n\nTo prepare for enforcement, enable _Report-only mode_ in the Entra admin centre to spot and resolve any problematic sign-ins. If migration takes longer than expected, you can temporarily exclude essential accounts, but always ensure that emergency access accounts are safeguarded.\n\n## Related Blog Posts\n\n  * How to Set Up Azure Multi-Factor Authentication\n  * 5 Azure Security Best Practices for SMBs\n  * Checklist for Securing Azure Data in Transit\n  * 5 Steps to Implement Zero Trust in Azure\n\n",
  "title": "Zero Trust with Azure Conditional Access: SMB Guide",
  "updatedAt": "2026-06-04T03:16:32.789Z"
}