Parag Mali https://paragmali.com/blog/windows-sandbox-vs-windows-defender-application-guard-two-hy/
37 min read
By

Windows Sandbox vs Windows Defender Application Guard: Two Hyper-V Sandboxes, Different Threat Models

Two Hyper-V-backed isolation containers shipped in Windows -- one survived, one was retired. The story of why disposable beat persistent, and what each model was actually for.

Permalink

1. The Hyper-V Isolation Layer Both Features Share

Open two Microsoft Learn pages side by side -- the Windows Sandbox architecture page and the Microsoft Defender Application Guard overview -- and the descriptions almost rhyme. The MDAG overview opens by calling its container an "isolated Hyper-V-enabled container"; the Sandbox architecture page describes its guest as a dynamically generated, "kernel-isolated" Windows image that the host can destroy. Two pages, two teams, the same noun and the same verb. The two features are siblings: built by overlapping teams, on top of the exact same compute substrate, and shipped roughly two years apart.

That substrate is named, and worth naming carefully, because the rest of the article rests on it.

Host Compute Service (HCS)

The Windows API that creates, starts, configures, queries, and destroys Hyper-V "compute systems" -- the umbrella term Microsoft uses for either a virtual machine or a container with its own kernel. The HCS reference docs list functions like HcsCreateComputeSystem, HcsStartComputeSystem, and HcsGetComputeSystemProperties -- a kernel32-shaped surface for child partitions, parameterized by JSON.

When Microsoft first documented HCS publicly, it framed it as a kernel32-equivalent for child partitions. The HCS overview describes the API in terms of compute systems (the umbrella term for either a virtual machine or a container with its own kernel), with "configurations and properties... stored in a JSON file which will then be passed through the HCS APIs to create the compute system." The API reference notes that the DLL "exports a set of C-style Windows API functions, using JSON schema as configuration"; Microsoft's hcsshim repository provides the Go binding used by Moby and containerd. The framing matters. HCS is not a sandbox. It is the mechanism a sandbox feature uses to ask Hyper-V for "a kernel of my own, isolated from yours, please." What the consumer does with that kernel -- what it boots, what it shares, when it tears it down -- is the threat model. That is where Sandbox and WDAG diverge.

Underneath HCS sits Hyper-V itself, and underneath Hyper-V sits Virtualization-Based Security (VBS).

Virtualization-Based Security (VBS)

A Windows feature that runs the normal Windows kernel as a Hyper-V guest, then uses a second, smaller secure kernel running at a higher Virtual Trust Level (VTL1) to isolate keys, policies, and code-integrity decisions from the main kernel. The OEM VBS guidance documents the boot path: the hypervisor launches first, then hosts the NT kernel in a child partition.

VBS itself does not run untrusted user code. Its job is to give Windows a hypervisor that ships in the box on every supported SKU and that is anchored by Secure Boot. Once that hypervisor exists, the cost of "spawn a second Windows guest just for this task" stops being "boot a full VM (minutes, gigabytes)" and starts being "ask HCS for a child partition (seconds, hundreds of megabytes)." Hyper-V on Windows is the desktop face of that hypervisor; Hyper-V isolation containers on Windows Server are the server face. Sandbox and WDAG are two desktop-flavored consumers of the same pipe.

Ctrl + scroll to zoom
The shared substrate. Both Windows Sandbox and WDAG sit on the Host Compute Service, which drives Hyper-V partitions backed by VBS. The host NT kernel itself runs as the root partition.

Notice the diagram's most important detail: the host NT kernel is also a Hyper-V guest. It runs in the root partition, which has full physical-device access; the sandbox and WDAG partitions run as L1 guests with no physical-device access at all. The Hyper-V VM boundary -- the membrane between root and L1 -- is what Microsoft commits to defending. That commitment is published: the Microsoft Security Servicing Criteria for Windows names the Hyper-V VM as a serviced security boundary, and the Hyper-V Bounty Program pays up to $250,000 for a guest-to-host escape. The boundary has a dollar sign attached to it, which is how you know it counts.

The Hyper-V VM boundary is the serviced security boundary. Windows Sandbox and WDAG ride on top of that boundary; neither product is the boundary. Bugs in the host-side broker, the clipboard channel, or the policy engine are not Hyper-V escapes -- they are integration bugs in features that happen to run inside a VM.

This distinction matters operationally. When the Windows Sandbox configuration docs warn that enabling vGPU "can potentially increase the attack surface of the sandbox," they are talking about widening a brokered channel from the L1 guest into the root partition's display stack. That channel runs through the VM boundary; abusing it does not require breaking Hyper-V. The same logic applies to mapped folders, the clipboard, networking, and the Edge-window remoting path WDAG used. Each is a deliberate hole in the boundary, made for a reason, with its own threat model.

With the substrate established, the next question is what Sandbox does on top of it. The answer turns on a single observation: the host already has a Windows image. Why download another one?

2. Windows Sandbox: The Disposable Desktop

Windows Sandbox shipped in Windows 10 1903, the May 2019 update, as an optional Windows feature named Containers-DisposableClientVM -- the install page documents both the version requirement and the exact PowerShell feature name. The naming is loud about the design goal. A container (rather than a VM you manage with vmconnect), disposable (state is destroyed on close), for client workloads (interactive desktop apps, not server workloads). Microsoft's original Windows Sandbox announcement on the Kernel Internals blog (preserved on the Internet Archive after Microsoft retired the canonical URL) frames the use cases plainly: trying out an installer, opening a suspicious download, testing an executable from email -- the same use cases the current Sandbox overview still enumerates.

The trick that makes this feel cheap is the dynamic base image.

Dynamic base image

The disk template Windows Sandbox uses to boot its guest. According to the Windows Sandbox architecture page, the on-disk package is approximately 30 MB compressed and expands to about 500 MB when installed. The expansion is mostly pointers back to the host's own immutable OS files; pristine private copies exist only for files the guest may legitimately mutate.

A traditional VM ships a 4-8 GB VHDX with its own copy of Windows. The dynamic base image inverts that. Read-only files in the host -- ntdll.dll, the bulk of System32, the side-by-side cache -- are reflected into the guest by reference. The guest sees a complete Windows install at boot. The host barely paid for it.

Memory uses an even sharper trick: direct map.

Direct map

A Hyper-V memory-sharing optimization, described on the Windows Sandbox architecture page, in which immutable physical pages are shared read-only between the host and the sandbox guest. When the guest loads ntdll.dll, the same physical RAM that already holds ntdll.dll on the host is mapped into the guest's address space rather than duplicated.

The page is read-only from both sides, so a guest exploit cannot scribble into the host's copy. The win is memory pressure: dozens of megabytes for the guest's mutable state instead of hundreds of megabytes for a fresh Windows kernel image. The same architecture page describes the memory model directly: "containers collaborate with the host to dynamically determine how host resources are allocated. This method is similar to how processes normally compete for memory on the host... If the host is under memory pressure, it can reclaim memory from the container much like it would with a process." A sandbox that does little uses little, and a sandbox that does a lot pulls pages from the host the same way a heavy host process would.

Direct map is conceptually the same trick Linux uses to share glibc between processes -- the same physical pages of a read-only binary backing many virtual address spaces. The Windows Sandbox application is to use that primitive across a Hyper-V partition boundary, not just across processes inside one kernel.

Graphics use a third mechanism. A vGPU runs the guest's display through WDDM 2.5+, sharing the host GPU much like another process on the host would. When the host GPU lacks a compatible WDDM driver, the guest falls back to WARP, Microsoft's CPU-backed Direct3D rasterizer. The same Sandbox architecture page cited above documents both branches: "a system with a compatible GPU and graphics drivers (WDDM 2.5 or newer) is required. Incompatible systems render apps in Windows Sandbox with Microsoft's CPU-based rendering technology, Windows Advanced Rasterization Platform (WARP)." That fallback is slow but means Sandbox starts on essentially any Pro+ Windows 10/11 install, not only on machines with modern discrete GPUs.

Ctrl + scroll to zoom
The Windows Sandbox lifecycle. Direct map and the dynamic base image keep cold start in the seconds-range and steady-state memory comparable to a heavy host process. Closing the host UI destroys the partition.

What the user configures is the small set of seams between guest and host. Configuration lives in a .wsb file, an XML document the user double-clicks to launch a customized sandbox. The Windows Sandbox configuration page enumerates every supported element: <vGPU>, <Networking>, <MappedFolders>, <LogonCommand>, <MemoryInMB>, <AudioInput>, <VideoInput>, <ProtectedClient>, <PrinterRedirection>, <ClipboardRedirection>. Each line is a knob on the boundary.

A minimal hostile-binary harness disables almost every shared channel:

JavaScript Generate a paranoid .wsb config for malware triage 
// Produce a Windows Sandbox configuration that minimizes shared channels.
// Run this in Node, save the output as triage.wsb, then double-click it.
const sample = "C:\\Users\\analyst\\Samples\\suspicious.exe";
const wsb = [
"<Configuration>",
"  <VGpu>Disable</VGpu>",
"  <Networking>Disable</Networking>",
"  <AudioInput>Disable</AudioInput>",
"  <VideoInput>Disable</VideoInput>",
"  <PrinterRedirection>Disable</PrinterRedirection>",
"  <ClipboardRedirection>Disable</ClipboardRedirection>",
"  <ProtectedClient>Enable</ProtectedClient>",
"  <MappedFolders>",
"    <MappedFolder>",
"      <HostFolder>C:\\Users\\analyst\\Samples</HostFolder>",
"      <SandboxFolder>C:\\Samples</SandboxFolder>",
"      <ReadOnly>true</ReadOnly>",
"    </MappedFolder>",
"  </MappedFolders>",
"</Configuration>"
].join("\n");
console.log(wsb);
console.log("\nSample path inside guest: " + sample.replace("C:\\Users\\analyst", "C:"));

Press Run to execute.

A few cost-of-doing-business limits are worth flagging up front. Only one Sandbox can run at a time, per the Sandbox overview, which also restricts the feature to Pro/Enterprise/Education SKUs ("Windows Sandbox is currently not supported on Windows Home edition") and inherits the VBS-capable-hardware requirement from the OEM VBS guidance. And while in-sandbox state survives a shutdown /r inside the guest (a Windows 11 22H2 refinement called out in the same overview page), state still dies when the host UI window closes -- "disposable" is the contract, not a marketing word.

A Containers-DisposableClientVM partition, then, is essentially a Hyper-V container with a desktop bolted on, a shared OS image, a few configurable channels, and a strict "destroy on close" lifecycle. WDAG, the older sibling, took the same building blocks and arranged them around a completely different question: not "run this executable once" but "render this website transparently."

3. WDAG: The Persistent Browser Container

Windows Defender Application Guard shipped in Windows 10 1709 -- the Fall Creators Update (Microsoft's UWP what's-new page identifies "Windows 10 build 16299 (also known as the Fall Creators Update or version 1709)"), with a GA start date of October 17, 2017 per the Microsoft Lifecycle page. The WDAG install guide still lists standalone-mode support starting at "Windows 10 Enterprise edition, version 1709 and later." At launch it integrated with the legacy EdgeHTML-based Edge; later it integrated with Chromium-based Edge for Business and, beginning in 2020, with Microsoft 365 Apps for Enterprise to wrap untrusted Office documents -- the MDAG overview explicitly enumerates the file types: "Application Guard helps prevent untrusted Word, PowerPoint, and Excel files from accessing trusted resources." The product was rebranded from "Windows Defender Application Guard" to "Microsoft Defender Application Guard" along the way -- the isolatedapplauncher.h header notes state directly that "Windows Defender Application Guard (WDAG) is now Microsoft Defender Application Guard (MDAG). The WDAG name is deprecated, but it is still used in some APIs." This article uses WDAG for continuity.

The use case was specific and corporate: in a managed enterprise, an employee may need to follow a customer's link, open an inbound attachment, or read a marketing site -- content that originates outside the organization's network perimeter. WDAG's job was to render that content in a partition that cannot talk to the intranet, so that a renderer exploit chained to a kernel LPE inside the guest could not pivot to corporate file shares, Active Directory, or the user's own home directory.

The trust boundary was policy-defined.

Network Isolation policy

The Group Policy mechanism Windows uses to enumerate "what counts as inside the enterprise network," documented under Configure Microsoft Defender Application Guard. Administrators populate Enterprise Network Domains, Cloud Resources, Internal Proxies, and IPv4/IPv6 Subnets. Anything inside the list is rendered in the host browser; anything outside is reissued inside the WDAG container.

This is the property Windows Sandbox does not have. Sandbox is a manual tool; WDAG was transparent. Click an external link in Outlook, and a separate Edge window opens hosting the rendered page -- the user did not have to know about, configure, or invoke a sandbox. The host-side broker forwarded the navigation; the in-container Edge rendered the page; an RDP-family remoting path relayed pixels back to the host UI. Microsoft has not publicly named the inner protocol, but its visible behavior -- per-window remoting of a single app onto the host desktop -- is the signature of the Remote Applications Integrated Locally (RAIL) virtual channel specified in [MS-RDPERP], the RDP extension that "presents a remote application... as a local user application." The implementation may differ in detail; the architectural shape is the same.

Where Sandbox is "destroy on close," WDAG was "warm at logon."

Ctrl + scroll to zoom
WDAG navigation path. The container is pre-warmed at user login. The first untrusted URL is reissued from the host Edge into the container Edge; subsequent untrusted navigations reuse the warm partition.

The configuration surface was correspondingly broader than Sandbox's .wsb. Group Policy settings controlled clipboard direction (upload, download, both, neither), file print to host, microphone and camera access, hardware acceleration, and -- most operationally consequential -- whether downloads escape the container at all. The Microsoft Edge WDAG configuration guidance listed knobs like ApplicationGuardUploadBlockingEnabled and ApplicationGuardPassiveModeEnabled for security-versus-usability tuning.

WDAG also exposed a small detection API for applications running inside it, the IsolatedAppLauncher COM interface. The methods IsProcessInWDAGContainer and IsProcessInIsolatedContainer let an app know "am I in the guest?" -- useful for, say, disabling drivers that cannot work inside the partition. The header carries the deprecation notice today.

The detection-from-inside API is itself a useful tell about WDAG's threat model. If the guest needed to know it was the guest, that means software running inside it could legitimately do guest-specific things -- license activation, optional installers, telemetry. WDAG was meant to host fully functional applications, not a stripped renderer. That breadth is part of what made its operational cost real.

What it improved over the AppContainer-wrapped Edge of 2016 was substantial. A renderer-to-kernel exploit in the container's stripped Windows guest landed in a throwaway kernel that had no view of the host filesystem, no route to the corporate intranet, no host clipboard write path, and no persistence across reboot. The kernel attack surface of the partition is, in the limit, the Hyper-V VM boundary. That is a serviced Microsoft boundary; an AppContainer-wrapped Edge is not.

So why was WDAG retired and Sandbox kept? Because in the WDAG threat model, the "warm partition for every employee, all day long, on every device" became a tax that the in-browser sandbox could finally outrun.

4. The Lifecycle Divergence

The clearest way to see why two siblings on the same substrate diverged is to put their lifecycles side by side. Sandbox boots on user gesture, runs as long as one window stays open, dies on close. WDAG booted at user logon, stayed resident the entire session, and discarded state only when the user signed out (or, for the persistent variant, never). The same Hyper-V partition primitive, allocated at very different points in the day, for very different durations, was being asked to solve very different problems.

Lifecycle binding

The point at which a security primitive's instance lifetime is anchored. Sandbox is gesture-bound: an instance exists because a user explicitly launched it. WDAG was session-bound: an instance existed because a user signed in. AppContainer is process-bound: an instance exists because a sandboxed binary is running. Each binding implies a different cost model and a different set of failure modes.

Gesture binding is cheap in expectation. Most users open Sandbox seldom -- when a particular file looks suspicious, when an installer wants admin rights for unclear reasons, when an analyst is reproducing a sample. The cost of the partition is paid on demand and only by the user who needed it. The Containers-DisposableClientVM feature in the Sandbox install docs ships an option: enabled but unused, it costs nothing beyond the dynamic base image on disk.

Session binding has the opposite cost profile. Every employee, on every device, pays for a Hyper-V child partition at every logon, whether or not they ever browse an untrusted URL. The partition holds memory. The host-side broker holds memory. The pre-warmed Edge holds memory. The Network Isolation policy must be evaluated on every navigation. The clipboard, downloads, and print paths require ongoing brokering. Even on a workstation that idles all day in front of an intranet portal, WDAG was a tax line item.

A serviced security boundary is cheap when it is allocated by gesture and expensive when it is allocated by session. WDAG bet that the per-session cost would amortize against frequent untrusted browsing; that bet failed for most enterprise users because the marginal extra protection over an in-browser sandbox (Edge ESM + ACG + CET) was small for the typical navigation, even though it remained large for the worst-case navigation.

The threat models also point in opposite directions. Sandbox optimizes for a single, contained interaction with an untrusted artifact: drop the .exe, run it, watch what happens, close the window. Anything the artifact does inside the partition -- registry writes, scheduled-task creation, persistence attempts -- is annihilated when the window closes. WDAG was optimizing for the opposite: many small, transparent interactions with untrusted content (clicks, navigations, document opens), all of which had to feel seamless or the user would route around them.

Ctrl + scroll to zoom
The two lifecycle shapes laid against each other on a typical workday. Sandbox makes one or two transient appearances on user gesture; WDAG holds a partition from logon to logoff regardless of usage.

The lifecycle asymmetry also asymmetrically rewards engineering effort. Hardening an in-browser renderer pays off thousands of times per session -- every page load benefits. Hardening a per-employee Hyper-V partition pays off only on the navigations that actually leave the trusted zone, which for most users is a small fraction of clicks. As the in-browser side became dramatically stronger between 2018 and 2023 -- Site Isolation, V8 sandboxing, Arbitrary Code Guard (ACG), Control-flow Enforcement Technology (CET), the new Edge Enhanced Security Mode -- the marginal value of WDAG dropped while its operational cost did not.

That set up the deprecation decision.

5. The Deprecation Decision

The retirement happened in two visible steps and a long invisible runway.

The first visible step was the Edge-side deprecation, announced in 2023. The Microsoft Edge and Microsoft Defender Application Guard page now opens with the banner: "Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is deprecated for Microsoft Edge for Business and will no longer be updated." The same page makes the operational substitute explicit: "The additional security features in Edge make it very secure without needing Application Guard," then enumerates Defender SmartScreen, Enhanced Security Mode, website typo protection, and Data Loss Prevention as the replacement set for the WDAG-for-Edge scenario.

The second visible step was the OS-level removal in Windows 11 version 24H2. The MDAG overview banner is unambiguous: "Starting with Windows 11, version 24H2, Microsoft Defender Application Guard, including the Windows Isolated App Launcher APIs, is no longer available." The isolatedapplauncher.h API reference carries the matching deprecation notice for the COM surface. Code paths that called IIsolatedAppLauncher on a 24H2 box now hit a removed feature; the API names remain in the documentation as historical record.

The invisible runway behind those two banners is the more interesting story. Microsoft's Security Servicing Criteria for Windows page names "Hyper-V VM" as a serviced security boundary but does not name WDAG or Application Guard. WDAG was always a feature that used the Hyper-V VM boundary; it was never the boundary itself. A bug in the WDAG broker, the Network Isolation policy evaluator, the clipboard channel, or the host-side window remoting was an integration bug, not a Hyper-V escape, and so was never going to attract the kind of bounty payout -- "up to $250,000 USD" per the Hyper-V Bounty Program -- that the underlying boundary attracts. The economic shape of WDAG's bug surface always favored deprecation: it was a complex, brokered feature whose worst plausible CVE was a privilege-escalation inside Edge, not a guest-to-host RCE.

WDAG's deprecation was overdetermined. (1) The session-bound cost model could not be amortized for most users. (2) The in-browser mitigations (ACG, CET, Edge ESM, Site Isolation) closed the marginal-security gap on the typical navigation. (3) The integration-bug class -- broker, clipboard, policy -- was never going to be on Microsoft's serviced security boundary list. Each reason alone could have justified retirement; all three together made it inevitable.

What was kept is just as telling. The Hyper-V VM boundary stayed; the bounty program stayed; the HCS API stayed; Windows Sandbox stayed; Hyper-V isolation containers on Windows Server stayed. Microsoft did not retire any of the things that made WDAG technically possible -- only the specific arrangement of those things into a session-bound, transparent, browser-targeted feature. The mechanism was kept; the productization was retired.

6. The WDAG Replacement Stack

There is no single replacement for WDAG. There is a stack of complementary features, each of which absorbs a slice of WDAG's old job. The Edge-deprecation page enumerates the substitute set; what follows pulls each item back to its primary source.

6.1 Edge Enhanced Security Mode (in-browser sandbox)

WDAG-for-Edge is now Microsoft Edge Enhanced Security Mode (ESM). The browse-safer page is explicit about what changed: "Enhanced security mode in Microsoft Edge mitigates memory-related vulnerabilities by disabling just-in-time (JIT) JavaScript compilation and enabling additional operating system protections for the browser. These protections include Hardware-enforced Stack Protection and Arbitrary Code Guard (ACG)."

Functionally, ESM gives up the Hyper-V partition boundary and replaces it with a set of process-mitigation policies that make the in-browser sandbox materially harder to escape. The renderer still runs on the host kernel, but with JIT disabled (closing a large class of write-then-execute primitives), CET enforcing shadow stacks, and ACG blocking dynamic code generation. For unfamiliar sites only, the browser flips into this mode automatically; familiar sites keep JIT on for performance.

The trade is explicit on the page: "Developers should be aware that the WebAssembly (WASM) interpreter running in enhanced security mode might not yield the expected level of performance." ESM is consciously slower in exchange for a smaller attack surface, and it concedes that this trade is only worth making on a subset of navigations. WDAG made the same concession at the partition level; ESM makes it at the mitigation level.

6.2 Smart App Control (OS-level binary trust)

For downloads -- the other half of "untrusted content reaches the user" -- the replacement is Smart App Control. The Microsoft Learn page describes it as "an app execution control feature that combines Microsoft's app intelligence services and Windows' code integrity features to protect users from untrusted or potentially dangerous code." The Windows 11 Security Book clarifies the mechanism: Smart App Control "blocks untrusted or unsigned applications" by predicting safety from a cloud intelligence service, and "blocks unknown script files and macros from the web."

The replacement logic is direct. WDAG protected the host kernel from a malicious download by running the download inside a Hyper-V partition. Smart App Control protects the host kernel from a malicious download by not running it at all unless app intelligence predicts it is safe or it is signed by a trusted CA. The first approach contains the blast radius after execution; the second prevents execution altogether. For the common case -- a user clicking through a suspicious-looking installer -- prevention strictly dominates containment.

6.3 Defender for Endpoint network protection (policy-defined trust boundary)

For the policy-defined "enterprise vs not-enterprise" boundary that the Network Isolation policy used to draw for WDAG, the replacement is Defender for Endpoint's network protection feature. The page describes it as "expand[ing] the scope of Microsoft Defender SmartScreen to block all outbound HTTP(S) traffic that attempts to connect to poor-reputation sources (based on the domain or hostname)," operating at the OS level. The same page is precise about which processes it covers on Windows: it enforces against non-Microsoft browsers and non-browser processes (for example, PowerShell), and its own Note states that "on Windows, network protection doesn't monitor Microsoft Edge. For processes other than Microsoft Edge and Internet Explorer, web protection scenarios use network protection for inspection and enforcement." For Microsoft Edge on Windows, the same reputational source feed (SmartScreen) operates inside the browser; Network Protection is the cross-process extension of that feed to the other process classes.

The shift is from isolate, then permit anything inside the isolated zone (WDAG) to enforce a reputational/IOC-based block list at the host network stack (Defender). The replacement gives up the partition boundary in exchange for matching coverage across every process on the device, not just Edge.

6.4 Office Protected View and Office SmartScreen (per-document admission)

The Office slice of WDAG -- the variant that wrapped untrusted Word, PowerPoint, and Excel files in a Hyper-V partition -- was always a layered feature on top of an older, cheaper primitive: Office Protected View. The Microsoft Support page describes the primitive directly: "files from these potentially unsafe locations are opened as read only or in Protected View. By using Protected View, you can read a file, see its contents and enable editing while reducing the risks." The page also calls out the WDAG layering explicitly: "If your machine has Application Guard for Microsoft 365 enabled, documents that previously opened in Protected View will now open in Application Guard for Microsoft 365" -- which is exactly the slice that 24H2 removed. Without WDAG, Protected View is the residual primitive: documents from the internet, untrusted senders, or unsafe locations open read-only in a stripped-down Office process until the user opts in to editing.

Around Protected View sits a second admission layer: SmartScreen-derived reputation checks on the artifact itself. The Microsoft 365 Apps internet-macros guidance sets the policy directly: "VBA macros are a common way for malicious actors to gain access to deploy malware and ransomware. Therefore, to help improve security in Office, we're changing the default behavior of Office applications to block macros in files from the internet." The page describes how Office uses the Mark of the Web -- the same signal SmartScreen uses for binaries -- to decide whether macros in a given document are admitted. Where the WDAG-for-Office configuration would have re-rendered the document inside a Hyper-V partition regardless of macro content, the 2026 replacement turns the question off: macros in internet-origin documents simply do not run.

Together, the two features are the document analog of Smart App Control + Defender network protection: a read-only fallback for the artifact itself (Protected View) and a reputation-driven admission policy for its riskiest payload (macros). Neither replaces a partition; the union covers WDAG's Office slice at the cost of giving up the kernel boundary around the document.

Ctrl + scroll to zoom
The WDAG replacement set, mapped to the WDAG slice each feature absorbs. No single feature replaces WDAG; the union of the three covers its old job at a fraction of the operational cost.

The stack is not a one-for-one swap. Each feature trades the Hyper-V VM boundary for something cheaper to operate. The aggregate covers the WDAG threat model at typical navigation cost; for the unusual case where an enterprise still wants a hard kernel boundary around an untrusted workload, Microsoft's recommended fallback is explicit: "If your organization requires container-based isolation, we recommend Windows Sandbox or Azure Virtual Desktop (AVD)." The Hyper-V partition is still there. It just is no longer running every employee's browser, all day, by default.

7. Why Sandbox Survives

If the deprecation reasoning above is right, the natural question is why the same substrate, allocated by the same HCS API, in the same kind of Hyper-V partition, survived as Windows Sandbox. The answer is that everything that made WDAG expensive maps to an operational advantage in Sandbox.

The lifecycle is gesture-bound, not session-bound. The cost is paid by the user who explicitly asked for it, when they asked for it, and not before. The Sandbox install page ships the feature disabled by default; turning it on costs the dynamic base image on disk and nothing on memory until launch.

The substitute set is empty. For the "run an untrusted executable once" threat model, no in-process mitigation suite plays the role ESM plays for browsing. There is no in-AppContainer answer to "I want to detonate suspicious.exe and observe it"; Smart App Control prevents execution rather than containing it; AppLocker policies refuse the run rather than sandboxing it. The use case Sandbox fills is what is left over when prevention fails or is operationally unacceptable, and there is no cheaper way to fill it.

The "run an untrusted executable" threat model lacks a cheaper substitute, so Sandbox's Hyper-V partition cost is the floor. WDAG's "render an untrusted website" threat model gained a cheaper substitute (Edge ESM), so WDAG's same Hyper-V partition cost stopped being the floor and became the ceiling -- and was retired.

The integration surface is also far smaller. Sandbox exposes one launcher binary, one configuration file format, no policy engine, no clipboard direction policies (just on/off), no network zoning, no pre-warmed worker process, no host-side broker for an embedded browser. The host-side attack surface is correspondingly thin: a .wsb parser, an HCS caller, a window-host process. Each WDAG-style integration bug class -- network-isolation evaluator, browser broker, document-routing logic -- has no analog.

A useful contrast: the isolatedapplauncher.h page exposes IIsolatedAppLauncher, IIsolatedProcessLauncher, IsProcessInIsolatedContainer, and IsProcessInWDAGContainer. That is the application surface of a feature that hosts third-party processes and lets them know they are inside it. Sandbox has nothing comparable, because no third-party application is supposed to ship with "behave differently inside Sandbox" logic. The guest is a fresh Windows install, the artifact is whatever the user dropped in, and the host does not need to expose an "am I inside?" predicate.

Sandbox also benefits from the negative space of the deprecation. The replacement stack (Edge ESM, Smart App Control, Defender network protection) collectively pushes the unbearable workloads off the Hyper-V partition: the always-on browser, the heavyweight Office document host, the network-zone enforcer. What is left for Sandbox is the relatively small set of workloads where partition isolation is the right answer: malware triage, installer testing, one-off compatibility checks, isolated developer environments. The feature is now used closer to its design intent than it was in the WDAG era.

This is the rare case where deprecating a sibling makes a feature more aligned with its purpose. Before WDAG retirement, the question "should this be in Sandbox or WDAG?" had a complicated answer involving who you were and what you were doing. After 24H2, the question collapses: if you want a partition, you mean Sandbox.

8. The 2026 Isolation Stack

With WDAG gone, the post-24H2 Windows isolation taxonomy is best read as four orthogonal primitives, each answering a different question about an untrusted workload. None alone substitutes for WDAG's combined function; together they cover the ground WDAG used to. The tiers below are numbered for reference; the numbering does not imply a single linear cost/strength axis. Process mitigations live inside AppContainer-wrapped processes (they are not "below" AppContainer on a cost axis, they are within it), and admission primitives (Smart App Control, Defender network protection) are an orthogonal family that decides whether a binary or destination is allowed at all -- a question that runs before capability containment, not above or below it.

Isolation primitive

A mechanism that answers a specific question about how an untrusted workload is constrained. The four families that the 2026 Windows stack composes are: (1) process-internal mitigations that limit what a corrupted-memory exploit can do (ACG, CET, Edge ESM); (2) capability sandboxes that limit what a process can name and reach (AppContainer); (3) admission policies that decide whether a binary may run or a destination may be contacted at all (Smart App Control, Defender network protection); and (4) kernel-partition boundaries that put an entire second NT kernel between the workload and the user's data (Hyper-V VM). Each family has its own cost shape; only the kernel-partition boundary appears on the Microsoft Servicing Criteria for Windows as a serviced security boundary.

Tier 1: Process mitigations (Edge ESM, ACG, CET)

The cheapest family runs the workload on the host kernel under a stricter set of process-level controls. Edge Enhanced Security Mode is the visible UI; the underlying primitives are the Hardware-enforced Stack Protection (CET) and Arbitrary Code Guard (ACG) referenced from the browse-safer page. These mitigations apply inside whatever container the binary already runs in -- an AppContainer-wrapped Edge renderer, or a non-AppContainer process -- and limit the privileges a corrupted-memory exploit can give itself. They are sufficient for the vast majority of untrusted navigations after the JIT-disabling trade is made.

Tier 2: AppContainer (capability-bound sandbox)

The capability sandbox is the AppContainer primitive. The MSDN page enumerates the isolation slices under six section headings -- Credential isolation, Device isolation, File isolation, Network isolation, Process isolation, and Window isolation -- all enforced at the OS, none requiring a partition. AppContainer is the wrapper around Edge's renderer, around UWP apps, around modern app-isolation packages. It is the cheap container that scales to every process on the device. Inside an AppContainer, Tier 1 mitigations still apply; AppContainer constrains what the process can name, Tier 1 constrains what a corrupted process can do. They are complementary, not stacked.

Tier 3: Smart App Control + Defender network protection (policy at the OS edge)

Adjacent to the process tiers, the policy tier decides what binaries and what destinations are allowed at all. Smart App Control governs what runs; Defender network protection governs what the device talks to. These are not isolation primitives in the strict sense -- they are admission primitives. They turn off the question before the partition has to answer it.

Tier 4: Hyper-V VM (Windows Sandbox, Windows Server Hyper-V isolation containers)

At the top of the cost curve sits the Hyper-V VM boundary -- the only tier whose worst-case escape pays the $250,000 bounty. Windows Sandbox is the desktop face; Hyper-V isolation containers on Windows Server ("each container runs inside of a highly optimized virtual machine and effectively gets its own kernel") are the server face. The 2026 stack uses this tier sparingly, on user gesture, for workloads where the cheaper tiers are not enough.

Ctrl + scroll to zoom
The 2026 Windows isolation tiers, presented as a stack of orthogonal primitives. The tiers are not strictly ordered on a single cost/strength axis: process mitigations live inside any AppContainer-wrapped process, and admission primitives (SAC, DNP) decide whether a binary or destination is allowed at all -- a separate question from how it is contained once allowed. The tier numbering is for reference, not for cost ranking.

The taxonomy is layered without being strictly linear. Read it as a four-question pipeline rather than a four-rung ladder. Tier 3 (Smart App Control + Defender network protection) decides what runs and what the device talks to -- admission, not containment. Whatever Tier 3 admits then lands inside Tier 2 (AppContainer), which constrains the binary's capabilities -- file, network, device, window, credential, and process scope. Inside that AppContainer-wrapped process, Tier 1 (ACG, CET, Edge ESM) applies process-internal mitigations that limit what a corrupted-memory exploit can do. Tier 4 (Hyper-V VM) is the last-resort kernel boundary: when the workload is hostile enough that the host kernel itself must be assumed reachable from the renderer, Windows Sandbox or a Hyper-V isolation container puts an entire NT kernel between the artifact and the user's data. WDAG used to plug a session-bound, transparent variant of Tier 4 underneath every Edge navigation; once Tier 1 hardening (ACG, CET, ESM) closed the marginal-security gap on the typical navigation, that session-bound Tier 4 paid more than it saved, and was deleted.

9. Engineering Takeaways

A few rules of thumb fall out of the architectural comparison.

Use the lowest tier whose boundary you actually need. If your threat is "this binary may try to escape the renderer," AppContainer + process mitigations suffice. If your threat is "this binary may try to escape the kernel," you need a Hyper-V partition; that means Sandbox or, for production, an isolation container. The Microsoft Servicing Criteria for Windows lists which boundaries Microsoft commits to defending; anything not on that list is best treated as a depth-in-defense layer, not a primary boundary.

Disable shared channels first; renegotiate them only when forced. The default .wsb-less Sandbox enables networking and clipboard redirection -- per the configuration docs, enabled networking "can expose untrusted applications to the internal network." For malware triage, build the paranoid .wsb from the snippet in section 2 and only loosen it when a specific analysis step requires it.

JavaScript Tier picker: map a workload description to the right 2026 isolation tier 
// A naive but useful decision tree. Print the recommended tier for a workload.
function pickTier(workload) {
const w = workload.toLowerCase();
if (w.includes("untrusted exe") || w.includes("malware")) {
  return "Tier 4: Windows Sandbox (on-demand, gesture-bound)";
}
if (w.includes("untrusted website") || w.includes("unfamiliar site")) {
  return "Tier 1: Edge Enhanced Security Mode + Tier 3: Defender network protection";
}
if (w.includes("untrusted document") || w.includes("office")) {
  return "Tier 3: Smart App Control + Office Protected View";
}
if (w.includes("third-party app") || w.includes("uwp")) {
  return "Tier 2: AppContainer";
}
return "Default: ship the workload under Tier 2 AppContainer; escalate if the threat model justifies it.";
}

[
"Detonate untrusted exe from email",
"Open an unfamiliar site for research",
"Open an untrusted Office document",
"Run a third-party packaged app"
].forEach(w => console.log(w + "  ->  " + pickTier(w)));

Press Run to execute.

Avoid features whose own boundary is not a serviced boundary. A useful litmus test is to read the Microsoft Security Servicing Criteria for Windows and ask whether the feature's own claimed isolation appears there. WDAG didn't; Hyper-V VM did. Designs that rely on a non-serviced isolation are more brittle, both technically (no bounty pressure on the boundary) and operationally (no commitment to fix integration bugs out-of-band).

Plan for deprecation of integration features, not of primitives. Microsoft retired WDAG; it did not retire HCS, Hyper-V isolation containers, or AppContainer. The primitives outlast the productizations. A codebase that depends on the primitives (calling HCS directly, wrapping a workload in AppContainer) is more durable than one that depends on a packaged feature (calling IIsolatedAppLauncher, relying on Network Isolation policy semantics) whose lifecycle is set by product economics.

10. Open Problems and Future Direction

The 2026 stack is good. It is not finished. Several open problems remain visible at the seams.

Transparent, gesture-priced isolation. WDAG's session-bound model failed; Sandbox's gesture-bound model is too explicit for everyday use. There is no current Windows feature that combines (a) automatic, policy-driven launch ("this URL is outside the trust zone, isolate it"), (b) Sandbox-style on-demand allocation, and (c) sub-second cold start. Each pair of those three is achievable -- WDAG had (a) and (b) but not (c); Sandbox has (b) and (c) but not (a); ESM has (a) and (c) but gives up the partition boundary. Closing all three simultaneously is the standing open problem.

Hardware-rooted attestation of the partition. Today's Hyper-V partition is anchored by VBS, which is anchored by Secure Boot, which is anchored by the platform firmware. Microsoft Pluton -- "a secure crypto-processor built into the CPU... designed to provide the functionality of the Trusted Platform Module (TPM) and deliver other security functionality beyond what is possible with the TPM 2.0 specification" -- raises the floor on what a guest can attest about, opening a path to confidential-VM-style guarantees on the client. The shape of that integration with Sandbox is not yet public.

Confidential client VMs. On the server, Azure confidential VMs provide a "hardware-enforced boundary between your application and the virtualization stack" via AMD SEV-SNP and Intel TDX, with "secure key release with cryptographic binding between the platform's successful attestation and the VM's encryption keys." Whether that boundary -- guest memory unreadable by the host kernel -- ever shows up under client Windows Sandbox or Hyper-V is an open architectural question. If it does, it changes the Hyper-V VM threat model: a malicious host (or compromised host kernel) could no longer read guest memory, which would close a category of risk that currently sits outside the bounty scope.

AI-agent action containment. WDAG's specific shape -- a session-bound partition that transparently absorbed risky actions on behalf of a user -- is suggestive of an emerging problem: containing the actions of AI agents that take tool-using steps inside a user's session. Today's stack does not have a feature shaped quite like this. Sandbox is too explicit; AppContainer is too process-bound; ESM is browser-only; Smart App Control is admit/deny, not contain/observe. An "AI-agent action sandbox" would need WDAG's transparency without WDAG's resident-per-employee cost. The architectural question is whether the lessons of WDAG's retirement should make the next attempt look like Sandbox-with-a-policy-trigger or like AppContainer-with-a-stronger-boundary.

Shared-microarchitectural-state side channels. The Hyper-V VM boundary is a logical boundary. The CPU caches, branch predictors, and prefetch units are still shared with the host. Spectre-class side channels survive partition boundaries and survive confidential-VM boundaries; the canonical Meltdown/Spectre disclosure frames the primitive as a class of transient-execution attacks against the shared microarchitectural state itself, and Microsoft's KB4072698 guidance for speculative-execution side-channel vulnerabilities catalogs a long succession of advisories (ADV180002, ADV180012, ADV180018 L1TF, ADV190013 MDS, ADV220002 MMIO Stale Data, CVE-2022-23825 Branch Type Confusion, CVE-2022-0001 Branch History Injection, CVE-2023-20569 AMD Return Address Predictor) that each required Hyper-V-host mitigation to keep the partition boundary effective. Mitigations close known variants at the cost of performance, but the underlying primitive -- one core, two security domains -- does not change. The ideal sandbox -- sub-second cold start, single-digit-MB resident overhead, transparent policy launch, and a partition boundary that closes all microarchitectural channels -- remains unachievable on shared silicon. This is not a Windows-specific problem; it is the lower bound on what any client-side sandbox can deliver.

The 2026 isolation stack is the right shape for the threats it was designed against: a malicious binary, an unfamiliar website, an untrusted document, a third-party app. It is not yet shaped for the threats that will dominate 2027 and beyond: confidential client compute, agent action containment, hardware-rooted attestation. Watching where the next partition-shaped primitive appears -- or fails to -- is how the architecture will continue to evolve.

Windows Sandbox and WDAG are the cleanest natural experiment Windows has run on Hyper-V isolation as a product. Same substrate, same partition primitive, same bounty-protected boundary; opposite lifecycle bindings, opposite threat models, opposite outcomes. The substrate survives because the substrate is the boundary; the productizations come and go because they are bets on how to spend that boundary's budget. WDAG bet on session-bound transparency and lost to a cheaper process-mitigation stack; Sandbox bet on gesture-bound disposability and remains the right answer for the workload it was designed for. The story is less about Hyper-V and more about lifecycle: when you allocate isolation matters as much as how much isolation you allocate.

Spot a bug?

- printed from https://paragmali.com/blog/windows-sandbox-vs-windows-defender-application-guard-two-hy/ · ©2026 Parag Mali · CC BY 4.0