How to Replace Microsoft Defender Application Guard After Its Removal

Microsoft Defender Application Guard (MDAG) used hardware-backed containers to isolate untrusted Edge sessions and Office documents from the user’s normal desktop. It is no longer a feature to deploy as new security architecture: Microsoft deprecated both variants, stopped updating them, and made the Edge/Isolated App Launcher feature unavailable starting with Windows 11 version 24H2. A current plan begins by identifying the threat MDAG addressed, then replaces that control with supported layers instead of trying to force an obsolete optional feature onto a newer image.

Step 1: inventory the operating system and existing MDAG footprint

Run the inventory from an elevated PowerShell session on a representative device and through the organization’s endpoint-management tooling at scale:

Get-ComputerInfo |
  Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Get-WindowsOptionalFeature -Online `
  -FeatureName Windows-Defender-ApplicationGuard

Record Windows edition and build, whether the optional feature exists, Edge and Office policies that reference Application Guard, browser extensions used to redirect Chrome or Firefox, trusted-network definitions, clipboard/download rules, and the user populations assigned to them. Do not interpret Disabled and FeatureNameUnknown as the same state: one can describe an available legacy component, while the other can reflect its absence from the installed Windows release.

Step 2: stop treating the old enable command as a current setup procedure

Older runbooks commonly contain this command:

Enable-WindowsOptionalFeature -Online `
  -FeatureName Windows-Defender-ApplicationGuard

It belongs only in a version-controlled legacy procedure for an explicitly supported older image. On Windows 11 24H2 and later, Microsoft’s current Edge documentation says MDAG and the Windows Isolated App Launcher APIs are no longer available. Existing installations on earlier Windows versions may continue to operate for their remaining supported lifecycle, but that is a migration window, not a reason to create a new dependency.

Also remove assumptions about the old Chrome and Firefox redirection extensions. Microsoft states that the corresponding extensions and Store application were not migrated to Manifest V3 and ceased being available after May 2024.

Step 3: write down the threat model before choosing a replacement

MDAG covered several distinct requirements that no single replacement automatically reproduces:

isolate a browser exploit from the host;
prevent an untrusted page from reaching corporate resources;
constrain clipboard, printing, downloads, cameras, microphones, and mapped storage;
protect documents arriving from untrusted zones;
route sites based on an enterprise trust boundary;
preserve audit and incident evidence.

Mark which of those controls are mandatory for each user group. A standard browser hardening policy can reduce exploit and phishing risk but is not a disposable virtual machine. Windows Sandbox is a disposable local environment but does not automatically classify enterprise URLs. Azure Virtual Desktop can isolate work onto remote infrastructure but adds identity, network, image, monitoring, cost, and data-governance responsibilities. Calling any one of them a drop-in replacement would hide important gaps.

Step 4: harden ordinary Edge browsing where container isolation is not required

Microsoft’s deprecation guidance points to current Edge security layers such as Defender SmartScreen, Enhanced Security Mode, typo protection, and data-loss-prevention integration. Combine the capabilities licensed and supported in the environment with prompt browser patching, least-privilege user accounts, Defender web/network protection, controlled extension policy, and appropriate download controls.

Test those controls independently. A blocked known-malicious URL demonstrates reputation filtering; it does not prove containment of an unknown browser exploit. Enhanced Security Mode changes exploit mitigations for selected sites; it does not create MDAG’s separate container or network boundary. Document that residual risk explicitly.

Step 5: use Windows Sandbox for deliberate, disposable local isolation

Microsoft recommends Windows Sandbox when container-based isolation is still required. Sandbox provides a clean, disposable Windows desktop, but the operator must launch it deliberately and its network access must match the investigation. A .wsb file can reduce accidental data paths:

<Configuration>
  <vGPU>Disable</vGPU>
  <Networking>Default</Networking>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ClipboardRedirection>Disable</ClipboardRedirection>
</Configuration>

Networking must remain available if the purpose is to visit a website, so this configuration is not sufficient by itself. Put the sandbox’s traffic through the intended DNS, proxy, firewall, and monitoring path; do not expose internal administration interfaces merely because the desktop is disposable. Avoid mapped host folders for hostile-content research, never enter production credentials, and destroy the session after collecting only sanitized evidence through an approved path.

Step 6: use Azure Virtual Desktop when isolation must be centrally operated

Microsoft also recommends Azure Virtual Desktop (AVD) for container-style isolation requirements. AVD can place browsing or document handling on managed remote session hosts rather than the endpoint, which is useful when security teams need centralized images, conditional access, network segmentation, logging, and rapid reset.

That architecture still needs a design review. Define identity controls, privileged access, egress filtering, access to corporate applications, clipboard and drive redirection, profile persistence, session-host patching, log retention, geographic/data requirements, and the response to a compromised session. A remote desktop that shares broad internal access can move the risk instead of containing it.

Step 7: replace Application Guard for Office with the documented control set

Microsoft separately deprecated Application Guard for Office and recommends transitioning to Defender for Endpoint attack-surface-reduction (ASR) rules together with Protected View and application control. Treat those as complementary controls:

Protected View opens internet-originated or otherwise risky documents with restricted editing;
ASR rules can block behaviors commonly abused by Office content, scripts, and child processes;
App Control for Business restricts which code is trusted to execute;
mail and collaboration protections reduce malicious attachments before they reach the endpoint.

Roll ASR and App Control policies through audit and staged enforcement, review line-of-business compatibility, and preserve the provenance markers that cause Office to use Protected View. Do not remove Mark-of-the-Web metadata or broadly add trusted locations merely to suppress user prompts; that defeats the boundary the replacement depends on.

Step 8: migrate policy and telemetry instead of only uninstalling a feature

Search Intune, Group Policy, configuration baselines, scripts, documentation, help-desk articles, SIEM queries, and compliance checks for Application Guard, WDAG, MDAG, the old optional-feature name, and the browser extensions. Map every old policy to a replacement, an explicitly accepted gap, or a removal because the original requirement no longer exists.

Update monitoring at the same time. Old Application Guard launch counts and container events cannot demonstrate use of Windows Sandbox, Edge hardening, AVD, Protected View, ASR, or App Control. Define new signals for policy application, audit-to-block transitions, browser and Defender alerts, session-host health, and user-visible failure modes.

Step 9: prove the replacement with adversarial acceptance tests

Use safe test artifacts and a non-production account to verify at least these cases:

an approved site and line-of-business document still work;
a reputation-blocked URL is stopped and logged;
a risky Office document enters Protected View and the expected ASR events appear;
clipboard, drive, printer, camera, microphone, and internal-network access match the selected isolation design;
a disposable Sandbox or AVD session cannot reach resources outside its intended boundary;
help-desk and incident-response staff can identify which control produced a block;
rollback restores the previous supported policy without reintroducing MDAG as a dependency.

The migration is complete only when the supported controls cover the documented requirements and the organization can detect both enforcement and failure. “The old feature disappeared after an upgrade” is an outage; a tested, evidence-backed replacement is a security transition.

Related:

Sources: