Understanding Conditional Access Policies in Microsoft Entra

For many nonprofits, data security can feel like walking a tightrope. Imagine an organization that provides housing assistance and collects personal information from clients—Social Security numbers, income details, and health records. A volunteer accidentally logs into the organization’s portal from an unsecured public Wi-Fi network. Without proper safeguards, this scenario could easily lead to a data breach.

This is where Conditional Access in Microsoft Entra comes into play. It empowers organizations to enforce dynamic, context-aware access policies that help protect both users and the sensitive data they handle. Conditional Access (CA) policies are a core part of a Zero Trust security strategy, helping nonprofits and enterprises alike balance accessibility and security by evaluating real-time risk factors.

What Is Conditional Access?

Conditional Access is a policy-driven control mechanism in Microsoft Entra that determines how users access your cloud applications. These decisions are based on identity signals, environmental context, and real-time risk insights. Instead of offering unrestricted access after sign-in, CA evaluates conditions like device health, geographic location, and user behavior to decide whether access should be granted, limited, or blocked.

For nonprofits, this means staff and volunteers can work flexibly while the organization maintains strong protections around sensitive systems such as donor databases, case management software, or finance portals.

The Conditional Access Model: Signal, Decision, Enforcement

Microsoft's Conditional Access operates through a clear three-stage model:

1. Signal Collection: Each time a user attempts to access a resource, Conditional Access collects data points such as:

• • The identity and role of the user (e.g., volunteer, admin)
  • The location of the sign-in (trusted IP, known country)
  • The type and health of the device used (managed, compliant, jailbroken)
  • The application or service being accessed
  • Risk assessment (from Microsoft Entra Identity Protection)

2. Policy Decision: Using the collected signals, Microsoft Entra evaluates policies configured by your IT admin. Policies define the conditions under which access is allowed or restricted. If the user's sign-in context meets the policy criteria, the system determines whether additional requirements (like MFA) must be satisfied.
3. Enforcement: Once a decision is made, enforcement is immediate. The system grants access challenges the user for more verification or blocks the attempt entirely. Enforcement can also limit session behavior using session controls (e.g., read-only access in SharePoint Online).

Key Components of a Conditional Access Policy

A Conditional Access policy includes two main segments: Assignments (who and what the policy applies to) and Access Controls (what should happen if the policy is triggered).

Assignments

1. Users and Groups: Policies can target:

• Specific users (e.g., executive director)
• Security groups (e.g., all finance team members)
• Directory roles (e.g., Global Administrators)
• All users, with necessary exclusions for emergency access accounts

2. Cloud Apps or Actions:

• Define whether the policy applies to Exchange Online, SharePoint, Teams, or other applications
• Protect sensitive user actions such as registering security details or using privileged accounts

3. Conditions: Each policy can be fine-tuned using a wide array of conditions:

• Sign-in Risk: Flags sign-ins that appear risky based on impossible travel, leaked credentials, or unusual behavior. Policies can respond differently based on low, medium, or high-risk scores.
• Device Platforms: Enables targeting of specific OS platforms (iOS, Android, Windows, macOS) to enforce device-based controls like requiring compliant or hybrid-joined devices.
• Locations: Policies can include or exclude IP ranges and countries. Named locations (like your office IP range) can be marked as trusted to reduce friction.
• Client Apps: Differentiates between browser-based apps, desktop clients, and legacy protocols (e.g., POP, IMAP). Legacy protocols often bypass MFA and are common attack vectors, making them ideal for restricted access policies.
• Device State: Detects whether the device is marked as compliant by Intune or is domain-joined. Enforces that sensitive data only flows to trusted, healthy devices.

These conditions are additive and must all be met for a policy to apply. Administrators can also use conditional filters and multiple policy layers to build complex enforcement scenarios.

Access Controls

Once conditions are met, Conditional Access determines the appropriate control. These fall into two categories: Grant Access or Block Access.

Grant Access Controls:

Access is granted only if certain criteria are met. Controls include:

• Require multi-factor authentication (MFA) for stronger verification
• Require device to be marked compliant by Microsoft Intune
• Require hybrid Azure AD join (for domain-joined, managed devices)
• Require approved client apps or app protection policies for mobile access
• Require terms of use acceptance to ensure informed compliance
• Require password change if user risk is high

You can require all selected controls or at least one control to be satisfied before access is granted.

Block Access:

This control denies access entirely when risk signals cross a threshold or critical policy conditions are not met. Example use cases:

• Block access from countries your nonprofit doesn’t operate in
• Block sign-ins using legacy authentication
• Block users accessing high-risk apps from unmanaged devices

Blocking overrides any grant conditions and is enforced in real-time.

Best Practices for Conditional Access Implementation

1. Use Report-only Mode First: Before enabling enforcement, simulate policy impact in audit mode to verify behavior.
2. Always Exclude Break-glass Accounts: Keep at least two cloud-only Global Administrator accounts exempt from all Conditional Access policies, with complex, monitored credentials. However, you can create a policy specific to for your emergency accounts that have stronger conditional policies like user risk, sign-in risk, MFA FIDO2, etc. Some features may only be accessible through Microsoft Entra ID Plan 2. See here for more information: Risk policies - Microsoft Entra ID Protection | Microsoft Learn.
3. Use Named Locations Strategically: Define known safe IP ranges (e.g., office, partner orgs) to simplify policy logic.
4. Design for Least Privilege: Apply the minimal access necessary for users and apps to operate securely.
5. Deploy MFA Broadly but Thoughtfully: Balance security with usability by requiring MFA on sensitive resources and risky sign-ins.
6. Reassess Policies Quarterly: Align policies with changes in staff roles, service usage, and threat landscape.
7. Use Templates and Baselines: Microsoft provides templates for common scenarios such as protecting privileged roles or blocking legacy authentication.
8. Enable Real-time Monitoring: Utilize sign-in logs, diagnostic settings, and Entra Workbooks to track trends and investigate blocked access attempts.

Conclusion

Microsoft Entra Conditional Access gives nonprofits a powerful and flexible way to secure access to their cloud environments. By evaluating each login attempt against a set of contextual signals and adaptive policies, Conditional Access enforces security in real-time without unnecessary disruption. It supports the organization's mission by protecting sensitive data, ensuring compliance, and enabling secure remote work.

Whether you’re managing grants, safeguarding health records, or coordinating volunteers, Conditional Access ensures that only the right individuals, under the right circumstances, can access the right information.

Hyperlinks

• Building a Conditional Access policy - Microsoft Entra ID | Microsoft Learn
• Risk policies - Microsoft Entra ID Protection | Microsoft Learn