The Final Countdown: Wrapping Up Conditional Access with Application Specific protection

As the countdown for my series draws to a close, there are still a few final points I’d like to explore, and hopefully, you’ll join me for this last journey.

Wrapping up this series on Conditional Access, we’ve covered everything from how the Entra Authentication Flow operates to foundational baselines, Privileged and Workload Identities, and risk-based policies. In this final post, I’ll guide you on implementing Conditional Access policies specifically tailored to protect organizational data and applications through Microsoft’s solutions: Microsoft Defender for Cloud Apps, SharePoint, Global Secure Access, and Office 365.

Organizations can generally recover from the loss of specific identities, hardware, or software, though it does come with costs beyond money. But data is a different story altogether. Data is the backbone of every organization, and its loss can be fatal.

Table of content

1. Data Loss: The Why

2. Conditional Access: The signals

   1. Global Secure Access

      1. Global Secure Access (GSA) Profiles and Licensing

   2. Microsoft O365 & Sharepoint Signals

   3. Microsoft Defender for Cloud Apps

      1. Requirements for Microsoft Defender for Cloud Apps

3. Conditional Access: The policies

   1. CAP examples

4. Conditional Access - The final words

   
   

---

Data Loss: The Why

As we know, corporations rely heavily on data, which comes in various forms. The University of Illinois provides a comprehensive list of data types, including:

• Intellectual Property

• Network and System Diagrams

• Configuration Documents

• Personal Health Information

• Passwords, Encryption Keys, and Authorization Codes

• Production Documentation

Following the NIST 800-60 guidelines (specifically FIPS 199), these data types are classified into three impact levels:

1. Low

2. Moderate

3. High

Data governance is crucial, as data loss can disrupt an organization entirely. According to IBM, the average cost of a data breach in 2024 has risen to USD 4.88 million, including direct costs like system restoration, configuration, and personnel training, as well as intangible costs like lost goodwill and reputation.

It’s essential for IT pros to reduce these risks, with Conditional Access policies providing a key solution for securing data.

---

Conditional Access: The signals

The policies in this post use Conditional Access signals tailored to Microsoft Defender and other Microsoft programs.

Global Secure Access

Microsoft’s new identity-based Zero Trust Network Access (ZTNA) solution, Global Secure Access (GSA), is designed to manage multiple types of network access and reduce risks through micro-tunneling. Micro-tunneling provides an added layer of security by isolating and protecting data in transit, whether it’s for remote access or general internet usage.

GSA offers three distinct traffic forwarding profiles:

1. Microsoft Traffic Profile: Routes data between Microsoft services over the Microsoft Global WAN instead of the public internet.

2. Private Access Profile: Connects users to internal applications and services via Microsoft’s Secure Service Edge.

3. Internet Access Profile: Routes general internet traffic through Microsoft’s Secure Service Edge for controlled and monitored access.

With GSA, it’s essential to enforce GSA client usage and configure security settings appropriately. For Conditional Access integration, enable GSA Conditional Access signaling through Adaptive Access configurations, found in the Entra Management portal under Global Secure Access -> Settings -> Session Management -> Adaptive Access. This setup allows for Security Profiles that control access based on web filtering policies.

Global Secure Access (GSA) Profiles and Licensing

Security Profiles in GSA allow granular control over web content access. These profiles group Web content filtering settings to allow or block specific web categories or Fully Qualified Domain Names (FQDNs), which are then prioritized based on the applied policy. This layered approach ensures that even if users have multiple profiles, only the highest priority configuration apply.

A Baseline Profile is also available, automatically applied to all GSA clients regardless of Conditional Access. Keep this in mind as it sets a foundation for secure network access.

Licensing options for GSA vary depending on which access profiles are needed:

1. Microsoft Entra Suite: A comprehensive bundle including Internet Access, Private Access, and other licenses like Microsoft Entra Identity Governance.

2. Microsoft Entra Internet Access: Grants access to the Internet Access traffic forwarding profile.

3. Microsoft Entra Private Access: Allows the use of the Private Access forwarding profile.

4. Secure Access Essentials: The basic license which only allows the use of the Microsoft Traffic forwarding profile, included in Microsoft 365 E3 & E5 plans.

To utilize either the Internet Access or Private Access profiles, a minimum of a Microsoft Entra P1 license is required.

Microsoft O365 & Sharepoint Signals

Now, let’s dive into a few essential policies that need configuration in either the M365 admin portal or the SharePoint admin portal.

For SharePoint, two key configurations to set up are session lifetime and unmanaged device access policies.

In the SharePoint Admin Center under Access control, make sure to configure the following:

• Unmanaged devices: I’ve set this to limited web access, though the ideal setting will vary based on your organization’s needs and policies.

  

• Idle session sign-out: Enable this policy, although the specific configuration here is less critical, as we’ll overwrite it with the M365 idle session policy.

  

Each of these policies will auto-generate a Conditional Access policy. We’ll keep the one created by the Unmanaged Devices policy, but the idle session policy can be removed (or disabled and ignored) because we’ll implement a more comprehensive Microsoft 365 Idle Session Control.

This policy is available in the Microsoft 365 Admin portal under Org settings. For direct access, use this link: Microsoft 365 Session Control.

For session timeout, a maximum of 3 hours is recommended. If this is only enforced for unmanaged devices, you might even reduce it to 1 hour, depending on your requirements. This policy will override the SharePoint session timeout, although we still need to enable the SharePoint policy to trigger the Conditional Access signal.

Microsoft Defender for Cloud Apps

To help protect corporate data in real-time, we can enforce policies that manage session and access control for cloud applications. These policies, enforced via App Control, are part of the Session Control settings within Conditional Access.

Requirements for Microsoft Defender for Cloud Apps

• Microsoft Entra P1

• Microsoft Defender for Cloud App license

These licenses can be standalone or bundled, although the Defender for Cloud Apps license is only included in Microsoft E5, E5 Security add-on, or E5 Compliance add-on.

By default, you have three policy types to choose from:

• Monitor

• Block download

• Custom policy...

The default policies, Monitor and Block download, don’t need to be configured in Defender for Cloud Apps as they’re built-in. However, to use a custom policy, you’ll need to configure it in Defender for Cloud Apps, which can be managed in the Microsoft XDR portal.

Without diving too deeply into Defender for Cloud Apps, you’ll need to onboard the SaaS applications you want to manage with Session and Access policies.

Applications that use Microsoft Entra as an identity provider (IdP) fall into two categories:

• Catalog Apps: These include apps like GitHub, Salesforce, OneDrive for Business, Microsoft Defender, and others in the Microsoft Entra app gallery using Microsoft IdP for SSO.

• Custom Apps: Any third-party applications using Microsoft Entra IdP for SSO that aren’t pre-onboarded, such as internal apps, fall into this category.

Applications that don’t use Microsoft Entra IdP are also divided into Catalog and Custom Apps. However, none of these are automatically onboarded; they need to be manually onboarded and configured with Session or Access policies.

To access the policies, follow these steps:

For both policy types, you can create various filters. Here, for example, I’m filtering for any unmanaged device accessing the automatically onboarded Azure Key Vault app.

In Access policies, you can configure actions like monitoring or blocking access:

Session policies allow for more flexibility, enabling you to set multiple data loss prevention (DLP) actions. Here, I’m using a Microsoft-provided DLP policy for PII with a few available actions:

As seen in the screenshot, a new public preview feature for step-up authentication allows you to enforce additional authentication for high-sensitivity scenarios. This is useful for cases where you’d want to reevaluate access using an authentication context—similar to what we used previously for a High Privileged PIM CAP.

I’ll dive deeper into Microsoft Defender for Cloud Apps in a future blog post, but for now, we’ve covered the essentials!

---

Conditional Access: The policies

Now that we’ve covered the why and how and understand the signals we’ll be using, let’s dive into some example policies.

These policies should serve as examples, as they’re much more environment-specific than those I’ve provided previously. They can be imported directly but may not cover all scenarios. Some may need to be customized for your setup, while others, like CAP51 for setting the Internet Access Security profile for a specific department, might require duplicates.

Short reminder of the naming scheme:

<CANumber>-<GrantControl>-<PolicyType>-<Persona>-<App>-<Platform>-<OptionalDescription>

CAP examples

CAP 43:

CA509-CompliantNetwork-IdentityProtection-Global-AllApps-AnyPlatform-Require Global Secure Access client active v1.0

JSON | MITRE ATT&CK Technique ID: T1078

This policy requires the Global Secure Access client to be active, meeting the requirement for a “trusted network.” It ensures that no corporate data is accessible without the built-in protections configured in Internet Access, which leverages Microsoft’s Secure Service Edge (SSE).

NOTE: License requirement as mentioned in the signals segment.

CAP 44:

CA510-TokenProtection-AttackSurfaceReduction-Global-Exchange&Sharepoint-Windows-Enforce Token Protection for Exchange & Sharepoint on Mobile & Desktop applications v1.0

JSON | MITRE ATT&CK Technique ID: T1557 & T1134

Token Protection binds a token to a user’s device, ensuring it cannot be stolen by malicious actors for token relay attacks. Currently in public preview, this feature has known limitations, so thorough testing is advised.

At present, it’s supported only for Exchange and SharePoint.

CAP 45:

CA511-APPorCompliant-Data&AppProtection-Global-O365-Windows-Require App Protection Policy or Compliant device for Office 365 v1.0

JSON | MITRE ATT&CK Technique ID: T1526

Requiring a Windows App Protection policy or a compliant device ensures no company data is accessed without management. Windows App Protection is in preview and currently supports only two scenarios, as described in the Microsoft Learn article: Microsoft Learn: App protection policies overview

CAP 46:

CA512-AppRestriction-Data&AppProtection-Global-O365-AnyPlatform-Enforce App Enforced Restrictions for Office 365 v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

Enforcing App Enforced Restrictions for Office 365 ensures the Session Timeout configured in the Microsoft 365 Admin portal is applied. This policy supersedes the session timeout settings in SharePoint.

CAP 47:

CA513-AppControl-Data&AppProtection-Global-Exchange&Sharepoint-AnyPlatform-Enforce Defender for Cloud Apps Session policy - Block Downloads for unmanaged devices v1.0

JSON | MITRE ATT&CK Technique ID: T1027 & T1567

This policy uses the built-in “Block Downloads” App Control policy, preventing unmanaged devices from downloading company data to protect against data exfiltration. To restrict this policy to unmanaged devices, use the following exclude device filter:

device.isCompliant -eq True

NOTE: License requirement as mentioned in the signals segment.

CAP 48:

CA514-AppControl-Data&AppProtection-Global-VariousApps-AnyPlatform-Enforce Defender for Cloud Apps Session policy - Custom policy v1.0

JSON | MITRE ATT&CK Technique ID: T1027 & T1567

This policy enforces a custom policy configured in Defender for Cloud Apps, requiring setup of the app connector, app onboarding, Conditional Access App control, and the session policy to meet your enforcement requirements. - Ensure to update the name of the policy depending on app and policy and conditions. NOTE: License requirement as mentioned in the signals segment.

CAP 49:

CA515-ComplianceOREntraJoined-DataProtection-Global-Sharepoint-AnyPlatform-Require managed device for Sharepoint access v1.0

JSON | MITRE ATT&CK Technique ID: T1567

Requiring a compliant device for SharePoint access protects company data against both intentional and accidental exfiltration, ensuring only managed devices can access SharePoint on mobile and desktop.

This policy re-uses the autogenerated policy:

[SharePoint admin center]Block access from apps on unmanaged devices

CAP 50:

CA516-AppControl-DataProtection-Global-Sharepoint-AnyPlatform-Enforce limited web access for Sharepoint for unmanaged device v1.0

JSON | MITRE ATT&CK Technique ID: T1567

This policy complements CAP 49 by enforcing the Limited Access policy, configured in the SharePoint admin center, for browser access on unmanaged devices.

This policy re-uses the autogenerated policy: [SharePoint admin center]Use app-enforced Restrictions for browser access

CAP 51:

CA517-SessionControl-IdentityProtection-Global-AllApps-AnyPlatform-Enforce never persistent browser session v1.0

JSON | MITRE ATT&CK Technique ID: T1078.004

This policy prevents users from saving their PTR tokens, requiring them to authenticate for each session. Depending on PTR lifetime, this enforces MFA or a phishing-resistant authentication method, such as a security key or Windows Hello for Business, aligning with the Zero Trust principle of “Verify Explicitly.”

CAP 52:

CA901-SecurityProfile-IdentityProtection-Marketing-GSA-AnyPlatform-Enforce Entra Internet Access Security profile for Marketing v1.0

JSON | MITRE ATT&CK Technique ID: T1204 & T1566

Organizations deploying Global Secure Access with Microsoft Entra Internet Access may need different Security Profiles for various departments. For instance, while you may block all social media sites, Marketing might need access. This policy enforces such exceptions as needed.

NOTE: License requirement as mentioned in the signals segment.

---

Conditional Access - The final words

And… that’s a wrap!

With this final post in the Conditional Access series, we’ve journeyed through Microsoft Entra’s labyrinth, navigated policy nuances, and stacked up protections on every access point. While there’s no 100% guarantee in cybersecurity, the right Conditional Access configurations go a long way to making your defenses a solid barrier, even if we can’t fully fortress your org from every possible risk.

Remember, Conditional Access isn’t a “set it and forget it” tool. New risks call for constant vigilance, policy tweaking, and perhaps even the occasional re-read of this series (I won’t mind!). Keep those policies current, keep learning, and your security strategy will always be a step ahead.

As usual, to lighten your mood, here's another bad joke:

Why was the access request feeling down?

Because it kept getting denied! 😎

Stick around, though, because there’s plenty more coming! I’ve got exciting posts lined up and will be sticking with Entra for the foreseeable future. So, stay tuned—may your access be conditional and your data ever secure!