This chapter covers session and access policies in Microsoft Defender for Cloud Apps, which are critical for controlling user behavior in real time within cloud applications. These policies enforce granular restrictions on data exfiltration, download, copy/paste, and printing, and they work hand-in-hand with Azure AD Conditional Access. On the SC-900 exam, approximately 10-15% of questions touch on Defender for Cloud Apps, with session and access policies being a key subtopic. Understanding the difference between access policies (applied at sign-in) and session policies (applied during use) is essential for answering scenario-based questions correctly.
Jump to a section
Imagine a large international airport with multiple terminals. Passengers (users) arrive and check in at the main counter (identity provider). After check-in, they proceed through security (conditional access). But beyond security, there are additional gates leading to specific concourses (cloud apps). Each gate has a security officer who can inspect passengers in real time, allow them through, block them, or even escort them to a special screening room. This is exactly how session policies in Defender for Cloud Apps work. When a user authenticates and is granted access to a cloud app via Azure AD Conditional Access, the session is redirected through Defender for Cloud Apps as a reverse proxy. At that point, session policies inspect every request and response in real time. The security officer (policy) can allow the request, block it, or apply actions like restricting download, blocking copy/paste, or requiring step-up authentication. Just as an airport gate officer can enforce rules like 'no liquids over 100ml' or 'no laptops in checked baggage', session policies enforce granular controls on data exfiltration and user actions. The key difference from conditional access is timing: conditional access is the checkpoint before boarding, while session policies are the ongoing monitoring and control while the passenger is moving through the concourse. The proxy sits between the user and the app, so it can see everything the user does and intervene if necessary.
What Are Session and Access Policies in Defender for Cloud Apps?
Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) is a Cloud Access Security Broker (CASB) that provides visibility, control, and protection for cloud applications. Among its most powerful features are session policies and access policies, which enable real-time monitoring and control of user activities in cloud apps like Microsoft 365, Salesforce, Box, and more.
Access policies: Enforce controls at the moment of sign-in, such as requiring multi-factor authentication (MFA), blocking access from untrusted locations, or allowing only compliant devices. They are evaluated before the user reaches the app.
Session policies: Enforce controls continuously while the user is actively using the app. They can block, allow, or restrict specific actions like downloading files, copying data, or printing.
Both types of policies are built on the Conditional Access App Control architecture, which integrates with Azure AD Conditional Access to route traffic through Defender for Cloud Apps as a reverse proxy.
How Conditional Access App Control Works
Conditional Access App Control leverages a reverse proxy architecture. When a user attempts to access a cloud app that is protected by a session or access policy, the following sequence occurs:
User authenticates with Azure AD. The authentication process evaluates Azure AD Conditional Access policies. If the user is allowed, Azure AD issues a token.
Conditional Access policy can be configured to redirect the user to Defender for Cloud Apps. This is done by selecting "Use Conditional Access App Control" in the Conditional Access policy under session controls.
Defender for Cloud Apps receives the user's request and acts as a reverse proxy. The user's browser or client is redirected to the Defender for Cloud Apps proxy, which then forwards the request to the cloud app.
All subsequent traffic between the user and the cloud app flows through Defender for Cloud Apps. This allows Defender for Cloud Apps to inspect every request and response in real time.
Session policies are evaluated on each request. If a policy condition is met, an action is taken (allow, block, restrict download, etc.).
Key Components and Defaults
Session policy conditions: Can be based on:
- User, group, or role - Device tag (compliant, domain-joined, etc.) - IP address or location - App (e.g., Exchange Online, SharePoint Online) - Activity type (download, upload, copy/paste, print) - File sensitivity label (from Microsoft Information Protection) - Risk level (from Azure AD Identity Protection)
- Session policy actions: - Allow: Let the activity proceed. - Block: Prevent the activity entirely. - Restrict: Apply restrictions such as:
- Block download - Block copy/paste - Block print - Apply label to file - Require step-up authentication (MFA) - Encrypt file - Custom notification to user
Access policy conditions: Similar to session policies but evaluated at sign-in. Common conditions include:
- User, group, or role - Device compliance - Location (IP range or country) - App - Client app type (browser, mobile, desktop) - Risk level
- Access policy actions: - Allow: Grant access. - Block: Deny access. - Require MFA: Force additional authentication. - Require device compliance: Only allow if device is compliant. - Require password change: Force user to reset password.
Default values: There are no default session or access policies in Defender for Cloud Apps; administrators must create them. However, the Conditional Access App Control feature is not enabled by default; it must be configured in Azure AD Conditional Access policies.
Timers: Session policies are evaluated on every HTTP request. There is no caching of policy decisions for a session; each request is checked independently. However, authentication tokens have a lifetime (default 1 hour for Azure AD, configurable) that affects how often re-authentication occurs.
Configuration and Verification
To configure a session policy in Defender for Cloud Apps:
1. Navigate to Microsoft 365 Defender portal > Cloud Apps > Policies > Policy management. 2. Click Create policy > Session policy. 3. Provide a name and description. 4. Under Session control type, choose one of: - Control file download (with inspection) - Control file upload (with inspection) - Block activities - Protect files on download (applies sensitivity labels) - Custom 5. Define the Activity source (user, group, etc.) and Activity target (app, folder, etc.) as conditions. 6. Under Actions, select what to do when conditions match. 7. Save the policy.
To verify a session policy is working:
Use the Policy match logs in Defender for Cloud Apps under Investigate > Activity log. Filter by policy name to see matched events.
Use a test user to attempt a blocked activity and confirm the block notification.
Interaction with Related Technologies
Azure AD Conditional Access: The gateway. Without a Conditional Access policy that redirects traffic to Defender for Cloud Apps, session policies cannot be enforced. The Conditional Access policy must include the session control "Use Conditional Access App Control" with the appropriate mode (monitor only, block downloads, or custom policy).
Microsoft Information Protection (MIP): Session policies can inspect files for sensitivity labels and take actions based on those labels (e.g., block download of files labeled "Highly Confidential").
Azure AD Identity Protection: Risk level (user risk or sign-in risk) can be used as a condition in session policies.
Microsoft 365 services: Session policies work with Exchange Online, SharePoint Online, OneDrive for Business, Teams, and other Microsoft 365 apps, as well as third-party apps like Salesforce, Box, and Google Workspace.
Step-by-Step Mechanism Example
Consider a scenario where an organization wants to prevent users from downloading files marked as "Confidential" from SharePoint Online when accessing from an unmanaged device.
Conditional Access policy: Created in Azure AD to target all users, target SharePoint Online, and require a compliant device. Under session controls, select "Use Conditional Access App Control" with mode "Custom policy".
Session policy: In Defender for Cloud Apps, create a session policy:
- Name: "Block Confidential Downloads from Unmanaged Devices" - Session control type: Control file download (with inspection) - Conditions:
- Device tag: Not compliant - App: SharePoint Online - File sensitivity label: Confidential - Actions: Block 3. User experience: A user on an unmanaged device signs into SharePoint Online. Azure AD evaluates the Conditional Access policy; since the device is not compliant, the policy redirects to Defender for Cloud Apps. The user can view files but when they attempt to download a file labeled "Confidential", the session policy blocks the download and displays a notification: "This file cannot be downloaded due to organizational policy."
Advanced: Monitoring vs. Blocking
Session policies can operate in monitor only mode, where actions are logged but not blocked. This is useful for testing and auditing before enforcing restrictions. The monitor only mode is set in the session policy's action as "Allow" but with logging enabled.
Limitations
Performance: The reverse proxy adds latency. Microsoft recommends using session policies only for high-risk scenarios.
App compatibility: Not all cloud apps are supported. The list of supported apps is maintained by Microsoft and includes major SaaS apps.
Non-browser clients: Session policies work only for browser-based access. Native mobile apps and desktop clients are not proxied. For those, you need to use app-level controls or conditional access.
File inspection: Only file types that Defender for Cloud Apps can inspect (e.g., Office documents, PDFs) are subject to content inspection. Archives may be inspected but with limitations.
Configure Azure AD Conditional Access
First, an administrator creates a Conditional Access policy in Azure AD that targets the cloud app(s) to be protected. The policy must include a session control: 'Use Conditional Access App Control'. This control can be set to 'Monitor only' (for testing), 'Block downloads' (to block all downloads), or 'Custom policy' (to use session policies from Defender for Cloud Apps). The Conditional Access policy acts as the gate that redirects traffic to the Defender for Cloud Apps proxy. Without this step, no session policies will be enforced.
Create Session Policy in Defender for Cloud Apps
In the Microsoft 365 Defender portal, navigate to Cloud Apps > Policies > Policy management. Click 'Create policy' > 'Session policy'. Provide a name and description. Choose the session control type: 'Control file download (with inspection)', 'Control file upload (with inspection)', 'Block activities', 'Protect files on download', or 'Custom'. Define the conditions: user/group, device tag, IP location, app, activity type, file sensitivity label, and risk level. Set the action: Allow, Block, or Restrict (with specific restrictions like block download, copy/paste, print). Save the policy.
User Authenticates and Accesses App
When a user attempts to access a protected cloud app, Azure AD evaluates the Conditional Access policy. If the policy conditions are met (e.g., user is in scope, app is targeted), the session control redirects the user to Defender for Cloud Apps. The user's browser is redirected to a Defender for Cloud Apps URL, which then proxies the request to the actual cloud app. The user is unaware of this redirection; they see the normal app interface. All subsequent HTTP requests and responses are routed through the proxy.
Session Policy Evaluation on Each Request
For every HTTP request (e.g., clicking a download button, copying text, printing), Defender for Cloud Apps evaluates the active session policies. The proxy inspects the request metadata, including user identity, device, location, app, and the activity being performed. If the activity involves a file, the proxy may inspect the file content for sensitivity labels. If a policy condition matches, the configured action is executed. For example, if a policy blocks downloads for files with label 'Confidential', the proxy intercepts the download request and returns a block notification to the user instead of the file.
Logging and Monitoring
All policy matches are logged in the Defender for Cloud Apps activity log. Administrators can view these logs under Investigate > Activity log. Each log entry includes the user, app, activity, policy name, and action taken (allow, block, restrict). This provides audit trail and helps fine-tune policies. Additionally, alerts can be configured for specific policy violations. The logs integrate with Microsoft 365 compliance center for advanced investigations.
Enterprise Scenario 1: Protecting Intellectual Property in a Law Firm
A global law firm uses SharePoint Online to store client documents, many of which are labeled 'Highly Confidential' under Microsoft Information Protection. The firm wants to prevent employees from downloading these documents onto unmanaged personal devices. They implement a session policy that blocks downloads of files labeled 'Highly Confidential' when the device is not marked as compliant in Intune. The Conditional Access policy targets SharePoint Online and uses 'Custom policy' session control. In production, the firm tests with a pilot group using monitor-only mode for two weeks, reviewing logs to ensure no false positives. After validation, they switch to block mode. A common issue is that some users attempt to download via the sync client (OneDrive sync) which is not proxied; the firm uses additional controls like blocking sync on unmanaged devices via conditional access. Performance impact is minimal because only high-risk activities are inspected; normal browsing is unaffected. Misconfiguration often occurs when the Conditional Access policy does not include the correct app (e.g., forgetting to include SharePoint Online in the target apps), causing session policies to never be triggered.
Enterprise Scenario 2: Preventing Data Exfiltration in a Financial Services Company
A bank uses Salesforce as its CRM. Employees frequently copy customer data from Salesforce into email or other applications. The bank wants to prevent copy/paste of sensitive fields like Social Security numbers. They create a session policy with session control type 'Block activities' and condition on the activity type 'Copy/paste'. The policy applies to all users accessing Salesforce from non-corporate IP ranges. In production, they configure the policy to block copy/paste and display a custom notification: 'Copying data from Salesforce is not permitted for security reasons.' A challenge is that the policy must be scoped to the specific web page or field; otherwise, it might block all copy/paste even from benign fields. They use the 'Custom' session control type with advanced filters to target specific URLs. Performance is a concern because every copy/paste action is inspected, but since it's a simple regex check, overhead is low. When misconfigured, the policy might block legitimate activities, causing user frustration. They use monitor-only mode initially to identify the correct scope.
Enterprise Scenario 3: Enforcing Device Compliance for a Healthcare Organization
A hospital uses Microsoft Teams for internal communication and file sharing. They require that only compliant devices (enrolled in Intune and meeting health policies) can download patient records from Teams. They set up a Conditional Access policy that requires device compliance and uses 'Custom policy' session control. In Defender for Cloud Apps, they create a session policy that blocks downloads from devices that are not compliant. They also add a condition for file sensitivity label 'Protected Health Information (PHI)'. In production, they find that the session policy works well for web browser access, but the Teams desktop client is not proxied. They mitigate this by using conditional access to block the Teams desktop client on non-compliant devices and force users to use the web app. A common mistake is not excluding service accounts from the policy, causing automated processes to fail. They create an exclusion group for service accounts.
SC-900 Exam Focus
This topic falls under Domain 3: Security Solutions and specifically Objective 3.2: Describe the capabilities of Microsoft Defender for Cloud Apps. The exam expects you to understand the difference between access policies and session policies, how they integrate with Azure AD Conditional Access, and what actions they can enforce.
Common Wrong Answers and Why Candidates Choose Them:
'Session policies replace Conditional Access policies.' This is wrong because session policies are dependent on Conditional Access to route traffic. Conditional Access is the gate; session policies are the ongoing controls. Candidates confuse the two because both involve 'policies' and 'conditions'.
'Session policies can be applied to native mobile apps.' Wrong. Session policies only work for browser-based access through the reverse proxy. Native apps and desktop clients are not proxied. Candidates assume all app traffic can be inspected.
'Access policies control actions during a session.' Wrong. Access policies are evaluated at sign-in only, not during the session. Session policies control in-session actions. Candidates mix up the timing.
'You can block copy/paste using an access policy.' Wrong. Blocking copy/paste is a session-level action. Access policies cannot inspect user actions; they only decide whether to allow sign-in. Candidates don't understand the proxy architecture.
Specific Numbers and Terms:
The feature is called Conditional Access App Control.
The three modes in Conditional Access session control: Monitor only, Block downloads, Custom policy.
Supported session control types: Control file download (with inspection), Control file upload (with inspection), Block activities, Protect files on download, Custom.
Conditions include device tag (compliant, domain-joined), file sensitivity label, risk level (from Azure AD Identity Protection).
Actions include Block, Allow, Restrict (with sub-actions like block download, block copy/paste, block print, require MFA, apply label).
Edge Cases the Exam Tests:
If a session policy is set to 'monitor only', it logs but does not block. The exam may ask what happens when a user attempts a blocked activity in monitor mode.
Session policies do not apply to B2B guest users unless explicitly included in the Conditional Access policy.
File inspection only works for files that Defender for Cloud Apps can parse; unsupported file types are passed through without inspection.
The reverse proxy adds latency; the exam may ask about performance impact.
How to Eliminate Wrong Answers:
If the scenario mentions 'real-time control during a session', look for session policy answers, not access policy or conditional access.
If the scenario mentions 'at sign-in', look for access policy or conditional access.
If the scenario involves blocking downloads or copy/paste, it must be a session policy.
Remember that Conditional Access must be configured first; without it, session policies are not enforced.
Session policies require a Conditional Access policy with 'Use Conditional Access App Control' set to 'Custom policy' to route traffic through Defender for Cloud Apps.
Session policies can block downloads, copy/paste, and print actions based on conditions like device compliance, user, location, and file sensitivity label.
Access policies are evaluated at sign-in and can block access, require MFA, or require a compliant device, but they do not control in-session actions.
Session policies only work for browser-based access to supported cloud apps; native apps and desktop clients are not proxied.
The reverse proxy architecture adds latency; use session policies only for high-risk scenarios.
Session policies can operate in monitor-only mode to log actions without blocking, useful for testing.
File inspection depends on Defender for Cloud Apps' ability to parse the file type; unsupported files are passed through.
Conditions in session policies can include device tag, IP location, app, activity type, file sensitivity label, and risk level from Azure AD Identity Protection.
These come up on the exam all the time. Here's how to tell them apart.
Access Policies
Evaluated at sign-in time only.
Control whether a user can access the app.
Actions include Allow, Block, Require MFA, Require device compliance.
Do not inspect user activities within the app.
Configured directly in Defender for Cloud Apps policy management.
Session Policies
Evaluated on every HTTP request during the session.
Control what actions a user can perform within the app.
Actions include Allow, Block, Restrict (block download, copy/paste, print, etc.).
Inspect file content and user activities in real time.
Also configured in Defender for Cloud Apps but require Conditional Access to route traffic.
Mistake
Session policies can replace Azure AD Conditional Access.
Correct
Session policies are dependent on Conditional Access. Without a Conditional Access policy that redirects traffic to Defender for Cloud Apps, session policies have no effect. Conditional Access acts as the gateway; session policies are the fine-grained controls inside the gate.
Mistake
Access policies control user actions within an app.
Correct
Access policies only control access at sign-in (allow, block, require MFA, etc.). They do not monitor or control actions like downloading or copying. Session policies are responsible for real-time control of user actions during a session.
Mistake
Session policies work for all cloud apps and all client types.
Correct
Session policies only work for browser-based access to a limited set of supported cloud apps (e.g., Microsoft 365, Salesforce, Box, Google Workspace). Native mobile apps and desktop clients are not proxied and are not subject to session policies.
Mistake
You can block all downloads with a single session policy without Conditional Access.
Correct
Even if you create a session policy that blocks all downloads, it only takes effect if the traffic is routed through Defender for Cloud Apps via a Conditional Access policy. Without the Conditional Access redirection, the session policy is never evaluated.
Mistake
Session policies are evaluated only at the start of a session.
Correct
Session policies are evaluated on every HTTP request throughout the session, not just at the beginning. This allows real-time control of each action (download, copy, print) as it occurs.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An access policy is evaluated when a user signs in to a cloud app and can allow, block, or require additional authentication (like MFA). It does not control actions within the app. A session policy, on the other hand, is evaluated continuously during the user's session and can control activities like downloading files, copying data, or printing. Session policies require a Conditional Access policy to redirect traffic through Defender for Cloud Apps as a reverse proxy. Think of access policies as the bouncer at the door, and session policies as the security guards inside the venue.
No, session policies only work for browser-based access. Native mobile apps and desktop clients do not go through the reverse proxy. To control access from these apps, you must use Azure AD Conditional Access policies (e.g., require compliant device) or app-level controls. For example, you can block the Outlook mobile app entirely via Conditional Access, but you cannot use a session policy to block download within that app.
Yes, session policies can block copy/paste actions. When creating a session policy, select the session control type 'Block activities' and then choose the activity type 'Copy/paste'. You can also specify conditions such as the user, device, or app. This is useful for preventing data exfiltration of sensitive information. Note that this only works in the browser and only for supported apps.
Conditional Access App Control is the feature that integrates Azure AD Conditional Access with Defender for Cloud Apps. It allows you to create a Conditional Access policy that redirects user traffic through Defender for Cloud Apps as a reverse proxy. Without this redirection, session policies cannot be enforced. The Conditional Access policy must include the session control 'Use Conditional Access App Control' and set it to 'Custom policy' to enable session policies.
You can create the session policy with the action set to 'Allow' but ensure that logging is enabled (monitor-only mode). This will log all policy matches without blocking any activities. You can then review the activity logs in Defender for Cloud Apps under Investigate > Activity log to see how many users would have been affected. After verifying the policy conditions are correct, you can change the action to 'Block' or 'Restrict' to enforce the policy.
Yes, session policies can inspect files for sensitivity labels from Microsoft Information Protection. You can create a condition based on the file's sensitivity label (e.g., Confidential, Highly Confidential). For example, you can block download of files labeled 'Highly Confidential' from unmanaged devices. The inspection happens in real time as the file is being downloaded or uploaded.
The user will see a notification in their browser indicating that the download is blocked due to organizational policy. The exact message can be customized in the session policy configuration. The download is prevented at the proxy level; the file never reaches the user's device. The event is logged in the Defender for Cloud Apps activity log for auditing.
You've just covered Session and Access Policies in Defender for Cloud Apps — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?