Securing the Browser Era: How to Protect the Modern Workspace with Microsoft Intune and Edge

The browser has quietly become the most critical attack surface in the modern enterprise. Whether your users are hitting Salesforce, SharePoint Online, or a line-of-business SaaS app, every keystroke, every file upload, and every authentication token flows through a browser tab. Microsoft's blog series Securing the Browser Era — From Cloud to AI puts a spotlight on exactly this reality, and in this post we're going to translate that vision into concrete Intune and Edge configuration you can deploy today.

This isn't a marketing recap. This is a practitioner walkthrough of the policies, profiles, and PowerShell you need to harden the browser layer in your tenant — from basic Edge security baselines to Defender for Cloud Apps session controls and AI-era data loss prevention.

Context and Background: Why the Browser Is Now the New OS

Think about what a typical information worker actually does in a day. They authenticate to Microsoft 365 via a browser, open Outlook Web Access, edit documents in Office Online, join Teams meetings, approve workflows in ServiceNow, and submit expenses in Concur. The local operating system is increasingly irrelevant — Windows, macOS, ChromeOS, it barely matters. The browser is the runtime.

This shift has massive security implications:

• Identity and session tokens live in browser storage — steal the cookie, bypass MFA entirely.
• Unmanaged devices can reach corporate SaaS apps through nothing more than a browser and a valid credential.
• AI-powered tools like Microsoft Copilot and third-party AI assistants introduce new data exfiltration vectors directly in the browser context.
• Browser extensions run with elevated privileges and can silently harvest credentials, clipboard data, and DOM content.
• Personal profiles in corporate browsers blur the boundary between managed and unmanaged data paths.

Microsoft's answer to this is a layered architecture: Microsoft Edge for Business as the managed browser, Intune for policy delivery, Entra ID Conditional Access for identity-based enforcement, and Defender for Cloud Apps for session-level inspection and control.

Problem Statement: The Gaps in a Default Browser Deployment

Out of the box, even on a fully Intune-managed Windows 11 device, Edge ships with a relatively permissive configuration. Users can:

• Install arbitrary browser extensions from the Chrome Web Store (via the compatibility layer)
• Sign into Edge with a personal Microsoft account, creating a separate unmanaged sync profile
• Paste corporate data into consumer AI tools like ChatGPT running in a browser tab
• Bypass Conditional Access by using an alternate browser (Firefox, Chrome) that isn't enrolled
• Save passwords locally without integration into enterprise credential management

None of these are catastrophic on their own, but combined they represent a significant control gap — especially as AI-assisted attacks become more sophisticated and as AI productivity tools proliferate inside enterprise browsers.

Step-by-Step Solution: Hardening the Browser with Intune and Edge Policies

Step 1: Deploy the Microsoft Edge Security Baseline via Intune

Microsoft maintains a Security Baseline for Microsoft Edge in Intune. This is the fastest path to a defensible starting configuration. Navigate to Intune > Endpoint Security > Security Baselines > Microsoft Edge Baseline and create a new profile.

Key settings enforced by the baseline include SmartScreen enforcement, password manager restrictions, and extension install blocklists. But don't stop there — layer on top with a custom Administrative Templates (ADMX) profile for Edge-specific settings the baseline doesn't cover.

Here's a PowerShell snippet to export your current Edge baseline assignments for documentation purposes:

# Requires Microsoft.Graph.Intune module or Graph SDK
# Export Edge Security Baseline assignments

Connect-MgGraph -Scopes "DeviceManagement.Read.All"

$baselines = Get-MgDeviceManagementIntent | Where-Object {
    $_.DisplayName -like "*Edge*"
}

foreach ($baseline in $baselines) {
    $assignments = Get-MgDeviceManagementIntentAssignment -DeviceManagementIntentId $baseline.Id
    Write-Output "Baseline: $($baseline.DisplayName)"
    foreach ($a in $assignments) {
        Write-Output "  -> Target: $($a.Target.AdditionalProperties['@odata.type'])"
    }
}

Step 2: Configure Edge for Business Policies via Intune ADMX Templates

Create a new Configuration Profile > Templates > Administrative Templates and filter by Microsoft Edge. Below are the high-priority settings to configure, along with their policy names:

• BrowserSignin = 1 — Force users to sign in with their work account; disables personal profile creation.
• NonRemovableProfileEnabled = Enabled — Ensures the work profile persists and cannot be removed.
• ExtensionInstallBlocklist = * — Block all extensions by default.
• ExtensionInstallAllowlist — Explicitly whitelist approved extension IDs.
• PasswordManagerEnabled = Disabled — Redirect credential management to enterprise solutions.
• SmartScreenEnabled = Enabled — Enforce Microsoft Defender SmartScreen.
• PreventSmartScreenPromptOverride = Enabled — Users cannot bypass SmartScreen warnings.

You can also push these as OMA-URI settings in a Custom profile. Here's an example for blocking all extension installs by default:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Edge~Policy~microsoft_edge~Extensions/ExtensionInstallBlocklist
Data Type: String
Value: <enabled/>
<data id="ExtensionInstallBlocklistDesc" value="1
*"/>

And to allow specific extensions (e.g., the Microsoft Single Sign On extension):

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Edge~Policy~microsoft_edge~Extensions/ExtensionInstallAllowlist
Data Type: String
Value: <enabled/>
<data id="ExtensionInstallAllowlistDesc" value="1
ppnbnpeolgkicgegkbkbjmhlideopiji"/>

Step 3: Enforce Edge as the Required Browser via Conditional Access

Conditional Access can require a compliant device for access to corporate apps, but you can go further by combining it with Defender for Cloud Apps to enforce browser-level controls even on compliant devices.

In Entra ID > Conditional Access, create a policy that routes browser sessions for your critical SaaS apps through the Defender for Cloud Apps proxy:

// Conditional Access Policy JSON (for reference/import via Graph API)
{
  "displayName": "CA - Route Browser Sessions to MDCA",
  "state": "enabled",
  "conditions": {
    "clientAppTypes": ["browser"],
    "applications": {
      "includeApplications": ["All"]
    },
    "users": {
      "includeGroups": ["YOUR-GROUP-OBJECT-ID"]
    }
  },
  "sessionControls": {
    "cloudAppSecurity": {
      "isEnabled": true,
      "cloudAppSecurityType": "mcasConfigured"
    }
  }
}

Once sessions are proxied through Defender for Cloud Apps, you gain session-level visibility and control: block downloads of sensitive files to unmanaged devices, block uploads to personal cloud storage, and monitor for anomalous data exfiltration behavior.

Step 4: Configure App Protection Policies for Browser-Based Access (MAM)

For BYOD scenarios where the device isn't enrolled in Intune, Microsoft Intune App Protection Policies (MAM) can wrap the Edge browser itself. This is the MAM-WE (without enrollment) scenario — corporate data accessed through Edge on a personal iPhone or Android is still protected.

Deploy an App Protection Policy for Edge on iOS and Android:

• Navigate to Intune > Apps > App Protection Policies > Create Policy
• Select platform (iOS or Android), target Microsoft Edge
• Configure: Data Transfer restrictions (block transfer to unmanaged apps), PIN requirement, block screenshots, require Intune enrollment or MAM registration
• Under Conditional Launch, set minimum OS version requirements and actions (block access / wipe data)

Here's a PowerShell snippet to check current MAM policy assignments for Edge:

Connect-MgGraph -Scopes "DeviceManagement.Read.All"

$mamPolicies = Get-MgDeviceAppManagementiOSManagedAppProtection | Where-Object {
    $_.DisplayName -like "*Edge*"
}

foreach ($policy in $mamPolicies) {
    Write-Output "Policy: $($policy.DisplayName)"
    Write-Output "  Data Backup Blocked: $($policy.DataBackupBlocked)"
    Write-Output "  Screen Capture Blocked: $($policy.ScreenCaptureBlocked)"
    Write-Output "  Minimum OS: $($policy.MinimumRequiredOsVersion)"
}

Step 5: Address the AI Data Leakage Vector

This is the newest and fastest-growing risk vector. Users are copy-pasting sensitive data into ChatGPT, Gemini, and other AI tools running as browser tabs. Microsoft Edge for Business now supports Edge Copilot controls and you can also use Purview DLP policies to detect and block sensitive data being submitted to external AI services.

In addition, configure the Edge policy to restrict access to known AI consumer sites via the Managed Sites list or push a Sites block via Defender for Cloud Apps app governance. For Purview DLP, create an Endpoint DLP policy that monitors browser uploads and clipboard paste operations into unsanctioned web destinations.

// Purview Endpoint DLP - Block paste of Credit Card data to external AI sites
// Configured via Microsoft Purview Compliance Portal
// Policy rule example (simplified JSON representation):
{
  "ruleName": "Block-SensitiveData-To-AI-Sites",
  "conditions": {
    "contentContainsSensitiveInformation": [
      { "name": "Credit Card Number" },
      { "name": "U.S. Social Security Number" }
    ],
    "endpointActivities": ["PasteToWebBrowser", "UploadToWebSite"],
    "browserDomains": ["chat.openai.com", "gemini.google.com", "claude.ai"]
  },
  "action": "BlockWithOverride",
  "notifyUser": true
}

Result and Verification

After deploying these controls, verify the configuration state using the following approaches:

1. Intune Device Configuration Report — Navigate to Devices > Configuration Profiles > [Your Edge Profile] > Device and User Check-in Status. Confirm all targeted devices show "Succeeded."
2. Edge Policy Status in Browser — On a managed device, open Edge and navigate to edge://policy. All configured policies should appear with source "Platform" confirming Intune delivery.
3. Defender for Cloud Apps Activity Log — Confirm browser sessions from Conditional Access are appearing in the MDCA activity log with session policy enforcement events.
4. MAM Status Report — In Intune, check Apps > Monitor > App Protection Status to confirm Edge on BYOD devices is reporting as protected.

# Quick check: List devices where Edge config profile is not in 'Succeeded' state
Connect-MgGraph -Scopes "DeviceManagement.Read.All"

$profileId = "YOUR-PROFILE-ID-HERE"
$states = Get-MgDeviceManagementDeviceConfigurationDeviceStatus -DeviceConfigurationId $profileId

$states | Where-Object { $_.Status -ne "succeeded" } | Select-Object DeviceDisplayName, Status, LastReportedDateTime | Format-Table

Key Takeaways

• The browser is the primary enterprise attack surface today — treat it with the same rigor as endpoint OS hardening.
• Microsoft Edge for Business + Intune ADMX policies give you granular, policy-driven control over browser behavior across your managed fleet.
• Defender for Cloud Apps session controls extend protection to unmanaged devices accessing corporate SaaS via browser — you don't need full MDM enrollment to enforce session-level DLP.
• MAM without enrollment (MAM-WE) lets you protect Edge on BYOD mobile devices, covering the personal device gap without requiring full device management.
• AI-era data leakage through browser paste and upload operations is a real and growing threat — Purview Endpoint DLP can detect and block these activities on Windows endpoints.
• Always verify policy delivery via edge://policy on the endpoint — it's the fastest way to confirm Intune-delivered browser policies are actually applying.
• Combine Conditional Access, MDCA, Intune, and Purview into a layered defense — no single control is sufficient on its own.

Keywords

Microsoft Edge security, Intune browser policies, Microsoft Defender for Cloud Apps, secure browser enterprise, Edge for Business, Intune MAM browser, Zero Trust browser