A practical guide to access policies, session policies, and real-time cloud app protection using Conditional Access App Control and Microsoft Defender for Cloud Apps

Security controls that rely solely on authentication and post-event analysis are no longer sufficient in modern cloud environments. While Conditional Access policies in Microsoft Entra ID effectively govern who can access applications, they provide limited visibility and control over user activity once access is granted. This creates a critical gap, where sensitive actions such as data exfiltration, unauthorized downloads, or malicious file interactions can occur within otherwise legitimate sessions.

Conditional Access App Control, delivered through Microsoft Defender for Cloud Apps, addresses this challenge by introducing real-time session governance. By acting as a reverse proxy, it enables continuous evaluation of user activity and enforces granular controls based on contextual signals such as user identity, device state, location, and session risk. This approach extends Zero Trust principles beyond authentication, enabling organizations to apply policy decisions dynamically throughout the session lifecycle.

This article provides an overview of the architecture and practical implementation of Conditional Access App Control, including the configuration of access policies, session policies, and its integration with Entra ID to achieve comprehensive session-level security.

What Is Conditional Access App Control?

Conditional Access app control is a reverse-proxy capability built into Defender for Cloud Apps. When a user navigates to a protected SaaS app, their session is routed through Defender for Cloud Apps infrastructure rather than going directly to the application. This intermediary position gives the platform visibility and control over everything that happens inside the session.

The integration point is Microsoft Entra Conditional Access. A Conditional Access policy routes qualifying sessions to Defender for Cloud Apps, where access policies and session policies take effect. For Microsoft Entra ID applications, onboarding is automatic. Third-party identity providers require manual configuration.

Defender for Cloud App Policy Types

Conditional Access app control operates through two complementary policy types:

• Access policies: Act at the point of authentication. They allow or block access entirely based on user, device, location, app, and client type. No session is established with a blocked app.

• Session policies: Act within an established session. They monitor and govern what the user actually does — downloads, uploads, clipboard actions, message sends, file labeling — without necessarily blocking app access.

Together, these policies address the full range of scenarios: blocking access from unmanaged devices entirely, or allowing access while restricting sensitive operations within the session.

Architecture: How the Proxy Works

Conditional Access App Control introduces a proxy-based architecture that enables real-time evaluation and enforcement of controls within active user sessions. The sequence below outlines how a proxied (non-Edge) browser session is processed:

1. User authenticates to a protected app via Microsoft Entra ID.
2. Entra ID evaluates the Conditional Access policy and, when conditions match, applies the ‘Use Conditional Access App Control’ session control.
3. The session is redirected through Defender for Cloud Apps proxy infrastructure. The app URL gains the .mcas.ms suffix.
4. Defender for Cloud Apps evaluates all configured access and session policies against the session context.
5. Policy actions execute in real time: block, audit, encrypt, label, require step-up MFA, or pass through.

Defender for Cloud Apps uses globally distributed Azure datacenters for geolocation-optimized routing. No session data is stored at rest in the proxy infrastructure, cached content follows RFC 7234 HTTP caching rules and covers only public content.

Implementation Details

Prerequisites and Licensing

Before configuring policies, verify the following are in place:

Step 1: Configure the Entra ID Conditional Access Policy

Access and session policies in Microsoft Defender for Cloud Apps require a corresponding Entra ID Conditional Access policy to route sessions through the proxy. Without this integration, Defender for Cloud Apps cannot evaluate or enforce controls on the session.

The initial step is to create the Conditional Access policy in Microsoft Entra ID in report-only mode. Follow the steps below to configure the policy before enabling any settings in Microsoft Defender for Cloud Apps.

Configuration Steps

1. Sign in to the Microsoft Entra admin center (entra.microsoft.com) as at minimum a Conditional Access Administrator.
2. Navigate to Entra ID > Conditional Access > Policies and select New policy.
3. Name the policy descriptively, for example: CAAC-SessionControl-SalesforceMarketing.
4. Under Assignments > Users or workload identities: Include the target users or groups. Exclude break-glass / emergency access accounts without exception.
5. Under Target resources > Resources: Include the specific cloud apps you want to govern (Salesforce, SharePoint Online, Box, etc.).
6. Under Conditions: Configure device filters, locations, client app types, or risk levels as needed for your scenario.
7. Under Access controls > Session: Select Use Conditional Access App Control, then select the appropriate control (Monitor only, Block downloads, or Use custom policy).
8. Set Enable policy to Report-only. Validate behavior in the CA sign-in logs before enabling.
9. After validation, toggle to On.

Step 2: Create Access Policies in Defender for Cloud Apps

Access policies govern the initial connection to an application and operate at the authentication boundary, evaluating contextual signals before a session is granted or denied. They serve as the first layer of control, determining whether access should be allowed, blocked, or subjected to additional conditions.

To configure an access policy, navigate to Microsoft Defender XDR > Cloud Apps > Policies > Policy management > Conditional Access, and select Create policy > Access policy.

Key Access Policy Filters

Access Policy Actions

• Audit: Allow access but log the event. Use during initial rollout to understand traffic patterns before blocking.

• Block: Deny access entirely. Supports email notification to the user and customizable block messages. Use for definitive enforcement (e.g., block all unmanaged devices from Salesforce).

Common Access Policy Scenarios:

1. Block access for unmanaged devices:

2. Block native client access (force browser-only for session control):

Step 3: Create Session Policies in Defender for Cloud Apps

Session policies provide granular control within an active session. Unlike access policies, which govern access at the authentication boundary, session policies regulate user activity after access has been granted. They enable continuous evaluation and enforcement of controls based on real-time context.

To configure a session policy, navigate to the Conditional Access tab within Microsoft Defender for Cloud Apps and select Create policy > Session policy.

Session Control Types

Session Policy Actions

• Audit: Allow the activity but log it. Use to monitor without enforcement.
• Block: Prevent the activity. Can include custom user-facing messaging to explain why and what to do instead.
• Protect: Apply a Microsoft Purview sensitivity label to the file on download. The downloaded copy is encrypted and access-controlled; the cloud copy is unchanged.

Step-Up Authentication

The Require step-up authentication action is available for block activity, download control, and upload control policy types. When a user performs the governed action, Defender for Cloud Apps redirects the session to Entra ID for Conditional Access re-evaluation. This allows policies such as requiring MFA when a user attempts to download a file classified as Confidential, even if they already completed MFA at login.

Session Policy Scenarios:

1. Block Downloads from Unmanaged Devices

2. Block Upload of Unlabeled Sensitive Files

3. Block Malware

4. Block Sensitive Content in Teams Messages

Sensitivity Labels and Microsoft Purview Integration

When session policies are integrated with Microsoft Purview Information Protection, download control policies can apply sensitivity labels to files as they exit the cloud environment, extending protection beyond the session to the endpoint.

Supported file types for automatic labeling on download include: .docx, .docm, .dotx, .dotm, .xlsx, .xlsm, .xltx, .xlam, .pptx, .pptm, .potx, .ppsx, .ppsm, and .pdf (unified labeling is required for PDF files).

Important consideration: The Protect action does not overwrite existing sensitivity labels. If a file is already labeled, the session policy will not reapply or modify the label. Label taxonomy and policy design should account for this behavior to ensure consistent data protection outcomes.

Policy Conflicts and Precedence

When multiple session policies apply to the same session, the most restrictive action takes precedence. This behavior is intentional and ensures a security-first outcome.

• If a session matches both a block download policy and an audit download policy, the download is blocked.
• If a session matches both a protect on download policy and an audit download policy, the Protect action is enforced.

Policies should be designed with this precedence model in mind. Broad audit policies can coexist with more targeted enforcement policies without conflict, as restrictive actions such as block or protect will always override audit-only configurations.

Validating Your Configuration

Policies should not be enforced without prior validation. The following sequence outlines the recommended approach for testing and validating your configuration:

1. Create a dedicated test user account whose attributes match the policy scope (unmanaged device persona, specific group membership, etc.).
2. Sign out of all existing sessions for the test apps.
3. Navigate to the protected app in a supported browser. Confirm the .mcas.ms suffix appears (or the Edge lock icon for Edge sessions).
4. Walk through all pages the user would normally visit. Verify rendering is correct — proxy-related rendering issues indicate missing custom domains for non-Microsoft IdP apps.
5. Perform the governed action (attempt a download, upload, clipboard copy, print). Verify the expected policy action occurs.
6. In Microsoft Defender XDR, navigate to Cloud Apps > Policies, and open the session policy report to confirm match events are recorded.
7. Check Cloud Apps > Activity log, filtering on Source = Access control to review sign-in events captured by the proxy.

User Notification and Transparency

By default, users are presented with a banner notification when their session is being monitored. This approach is recommended, as transparency helps set expectations and reduces friction when users encounter restricted actions, providing context rather than an unexplained failure.

To configure notification settings, navigate to Microsoft Defender XDR > Settings > Cloud Apps > Conditional Access App Control > User monitoring. Options include disabling notifications entirely or customizing the message text and branding to align with organizational standards.

For block actions, it is recommended to configure a custom message that clearly communicates the policy rationale and provides guidance for remediation. For example: “This file cannot be downloaded to an unmanaged device. Please enroll your device in Intune or access the file from a corporate-managed device.” Well-defined, actionable messages help reduce user confusion and minimize help desk volume.

Cloud Discovery and Traffic Logs

Microsoft Defender for Cloud Apps automatically records detailed traffic logs for each proxied session, including timestamp, IP address, user agent, accessed URLs, and data transfer metrics such as bytes uploaded and downloaded. These logs are aggregated into the Conditional Access App Control continuous report within the Cloud Discovery dashboard, providing visibility into session-level activity.

To export logs for SIEM integration or compliance purposes, navigate to Settings > Cloud Apps > Connected apps > Conditional Access App Control, and select Export. Exported logs are available under Reports > Cloud Apps > Exported reports.

Recommended Deployment Sequence

For a production rollout, follow this sequence to minimize risk:

1. Enable report-only mode in Entra ID Conditional Access. Analyze sign-in logs for two to four weeks to understand which sessions would be affected.
2. Deploy monitor-only session policies in Defender for Cloud Apps for all target apps. Establish a baseline understanding of user behavior before enforcement.
3. Enable enforcement for access policies targeting unmanaged devices and native clients. These have the lowest false-positive risk.
4. Enable session policies with audit actions for download and upload. Review alerts for false positives.
5. Enable block and protect actions for validated scenarios. Start with pilot groups before broad rollout.
6. Configure custom block messages and user notification settings before broad enforcement.
7. Integrate alert forwarding to Power Automate or your SIEM for operational monitoring.

Known Limitations

• Non-interactive sign-in flows (Authenticator app, service principals) are not supported for access controls. Use native Entra ID Conditional Access policies for these scenarios.
  • Session policies on host apps do not extend to resource apps — configure separate policies for resource apps.
  • TLS 1.0 and TLS 1.1 clients are not supported. Defender for Cloud Apps requires TLS 1.2 or higher.
  • The Protect action does not overwrite existing sensitivity labels on files.
  • Custom apps using non-standard domains must have those domains manually registered in the cloud app catalog.
  • Session controls are browser-based. Native mobile and desktop apps require dedicated access policies with the Mobile and desktop client filter.

Final Thoughts

Conditional Access App Control addresses a critical gap left by traditional perimeter-based controls. As users increasingly access SaaS applications from diverse environments, the focus shifts from restricting access to ensuring that security controls extend into the session itself.

The architecture where Microsoft Entra ID Conditional Access routes sessions through Microsoft Defender for Cloud Apps, governed by access and session policies and reinforced by Microsoft Purview sensitivity labels enables real-time enforcement while maintaining user productivity. Effective implementation, however, depends on deliberate policy design, including precise scoping, clear and actionable user messaging, and a phased rollout approach that begins with audit mode and progresses to enforcement.

When integrated with the broader Microsoft 365 Defender ecosystem, Conditional Access App Control serves as a foundational component of a Zero Trust architecture, where trust is continuously evaluated throughout the session rather than established solely at the point of authentication.

References

• Microsoft Defender for Cloud Apps — Conditional Access App Control overview
  https://learn.microsoft.com/en-us/defender-cloud-apps/proxy-intro-aad
• Microsoft Defender for Cloud Apps — Session policies in Conditional Access App Control
  https://learn.microsoft.com/en-us/defender-cloud-apps/session-policy-aad
• Microsoft Defender for Cloud Apps — Access policies in Conditional Access App Control
  https://learn.microsoft.com/en-us/defender-cloud-apps/access-policy-aad
• Microsoft Entra ID — Conditional Access documentation
  https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• Microsoft Purview Information Protection — Sensitivity labels and protection
  https://learn.microsoft.com/en-us/purview/information-protection