Windows Sandbox: the disposable VM in the box, and the .wsb settings that decide whether it is actually isolated

Somebody on your service desk gets a suspicious invoice attachment. They want to look at it without risking their laptop. On Windows 11 Pro, Enterprise and Education there is already a tool on the device for exactly that job: Windows Sandbox. It is a throwaway Windows desktop that boots in seconds, runs on the Microsoft hypervisor, and is destroyed the moment you close the window. No separate ISO, no VM to patch, no licence to buy.

The catch is that "isolated" is not a property of Windows Sandbox. It is a property of the configuration file you launched it with. And the default configuration, plus the sample configuration people copy off the internet, is not the one you want for opening an untrusted invoice. This post explains what the sandbox actually is, walks every documented element of the .wsb configuration schema and what each one costs you in security terms, and shows the Group Policy and Intune settings that let you take the decision away from the user entirely.

The problem: the defaults are the opposite of isolation

Start with what Microsoft says the product does. Windows Sandbox "offers a lightweight, isolated desktop environment for safely running applications." Applications installed inside it "remain isolated from the host machine using hypervisor-based virtualization." Closing it "deletes all software, files, and state." That is genuinely useful, and it is genuinely true.

Now look at what you get when a user clicks the Start menu tile with no configuration file at all. Microsoft documents the default launch posture explicitly, and it reads like a list of things a malware analyst would switch off first.

Three of the four things you would most want off are on. That is a defensible choice for a consumer feature where the goal is that a browser works and copy-paste works. It is the wrong starting point for opening an attachment.

The second half of the problem is the part that surprises experienced engineers. The disposal guarantee has a boundary, and mapped folders sit outside it.

The third half, if you will allow it, is the sample configuration problem. The most-copied .wsb snippets on the internet are development snippets. They map a projects folder read-write, because that is the point of a dev sandbox. Someone doing triage copies the shape of that file, changes the folder, and never notices that <ReadOnly>false</ReadOnly> is still in there. The XML looks careful. The posture is wide open.

Why it happens: what the sandbox actually is under the window

To reason about the settings you need to know what is being configured. Windows Sandbox is not a normal virtual machine, and the difference is the reason it can boot in seconds.

Dynamic Base Image: it borrows your host's Windows

A conventional Hyper-V VM needs its own complete copy of Windows on disk. Windows Sandbox does not. Microsoft calls the technique Dynamic Base Image. Most operating system files are immutable, so the sandbox shares the copies already installed on your host. The small subset that is mutable cannot be shared, so the base image ships pristine copies of just those. The two sets combine into a complete, bootable Windows image.

The numbers Microsoft publishes for this are worth remembering. Before installation the dynamic base image package is a compressed 30 MB package. Once installed it occupies about 500 MB of disk space. That is the entire on-disk cost of having a spare Windows install available.

Direct map: it borrows your host's memory too

Because the sandbox runs the same operating system image as the host, Microsoft extended it to use the same physical memory pages for OS binaries, via a technology it calls "direct map." Microsoft's example: when ntdll.dll is loaded in the sandbox, it uses the same physical pages as the copy loaded on the host. That is why the memory footprint is smaller than a VM's, and Microsoft is careful to say this happens "without compromising valuable host secrets."

Memory allocation is dynamic rather than fixed. A classic VM is handed a static slice of host memory. The sandbox collaborates with the host, and if the host comes under memory pressure it can reclaim memory from the container much as it would from an ordinary process.

The isolation boundary, stated properly

This matters because people argue about it. Microsoft's Windows 11 Security Book says Windows Sandbox "uses the same hardware-based virtualization technology as Hyper-V" and that any untrusted Win32 app installed in it "stays only in the sandbox and can't affect the host." The overview page describes it as "Secure: Uses hardware-based virtualization for kernel isolation. It relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host."

The moving parts on the host

Windows Sandbox is not installed by default. It arrives as a Windows optional feature named Containers-DisposableClientVM, whose display name is "Windows Sandbox" and whose description reads "Enables the dependencies required to run Windows Sandbox scenarios." Enabling it stages a small payload and lights up the Start menu entry.

Here is what the feature actually puts on the box and what each piece does in the flow, from the user double-clicking a .wsb file to a desktop appearing.

The chain, in order: the user opens a .wsb file, or the Start menu tile, or runs wsb start. WindowsSandbox.exe reads the configuration. It checks the configuration against policy in HKLM\SOFTWARE\Policies\Microsoft\Windows\Sandbox and refuses anything policy has blocked. It asks vmcompute to build a container from the dynamic base image. vmwp hosts the partition. Mapped folders are attached. Then, and only then, the logon command runs. Ordering matters here, and Microsoft states it: "When using <Mappedfolders> to map folders, the folders are mapped before the execution of the Logon command." A logon command can therefore touch a mapped host folder on its very first instruction.

Why the defaults never got tightened

Windows Sandbox is aimed at everyone. Microsoft's own FAQ says it "can be used in various scenarios by anyone without any technical skills," and lists secure web browsing and social media browsing alongside malware triage. Networking off breaks the browsing scenarios. Clipboard off breaks the "just paste this in" scenario. So the defaults optimise for the common case, and the security-critical case is left to the configuration file. That design decision is the whole reason this post exists.

How to verify: feature state, prerequisites, surfaces and .wsb parsing

Verification splits into two questions. Is the sandbox available on this device, and what posture will it launch with?

Step 1: is the optional feature enabled?

The single authoritative check is Get-WindowsOptionalFeature. It needs an elevated prompt. Run it and read the State field.

Two related checks are worth having in the same breath. On Windows 11 24H2 and later, Windows Sandbox is also delivered as a Microsoft Store app with a revamped UI and the wsb.exe command line. Microsoft's documented way to tell which version you are on is Get-AppxPackage -Name WindowsSandbox | Select-Object Version: an empty result means the older inbox version, a version number means the newer one. You can also run wsb --version, and if wsb is not available you are on the older version.

Step 2: are the prerequisites there?

Microsoft publishes a short prerequisite list, and every item on it is checkable without rebooting anything.

Nested virtualisation deserves its own sentence because the question comes up constantly. Yes, Windows Sandbox runs inside a virtual machine, and Microsoft documents exactly how to make that work. On the VM host you run Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true followed by Update-VMVersion -VMName <VMName>. Note the constraint that goes with it: Microsoft's troubleshooting table says Windows Sandbox "only supports Hyper-V Hypervisor. Third-party hypervisors are not supported."

Step 3: the registry surface

There is exactly one registry key that changes Windows Sandbox behaviour, and it is the policy key. There is no supported user-preference key, no per-machine defaults key, nothing under HKCU. Everything else about a sandbox launch comes from the .wsb file.

Those eight value names are not guesses. They are the value names in C:\Windows\PolicyDefinitions\WindowsSandbox.admx on a stock Windows 11 device, and they match the WindowsSandbox area of the Policy CSP exactly. Here is what that key looks like when the policy has actually applied.

Step 4: Event Viewer, honestly

This is where I have to be straight with you. Microsoft publishes no Event ID catalogue for Windows Sandbox. There is no Microsoft-Windows-WindowsSandbox channel. There is no documented sandbox log file either. When Microsoft's own troubleshooting guidance wants sandbox diagnostics, it sends you to Feedback Hub traces or the GitHub repository, not to an Event ID.

What you do get, documented, are the Host Compute Service channels, because the sandbox is built by the same Host Compute Service that builds Windows containers. Those are the channels to watch when a sandbox refuses to start.

To capture the verbose channel for one reproduction, Microsoft documents the exact wevtutil sequence. Enable the analytic channel, reproduce the failure, export it, then turn it off again.

Step 5: services and scheduled tasks

Two services matter and one common assumption is wrong. There is no service called "Windows Sandbox." The work is done by the Hyper-V host stack, which is present on a supported device whether or not the sandbox feature is enabled.

On scheduled tasks the honest answer is that there are none. I found no scheduled task under \Microsoft\Windows\ that drives Windows Sandbox, and Microsoft documents none. The sandbox is entirely user-initiated: a tile, a .wsb file, or wsb start. Nothing runs it on a timer, which is one fewer thing to worry about.

Step 6: Defender, and a name collision that catches people out

On the question that actually matters, whether Defender scans inside a Windows Sandbox session, I could not find a Microsoft statement either way, so I am not going to invent one. What I can say from the documented architecture is the thing you should plan around. Each sandbox launch is a fresh, pristine Windows instance that is destroyed on close, so any detection or telemetry generated inside it dies with it. Compare that with WSL, where Microsoft explicitly ships a Defender for Endpoint plug-in that monitors activity inside a distribution and reports it to the MDE dashboards. There is no equivalent documented plug-in for Windows Sandbox. Treat the sandbox interior as unmonitored.

The part your host Defender does see is the part that touches the host. A file written into a write-enabled mapped folder lands on the host filesystem, where host real-time protection applies normally. The .wsb file itself, and WindowsSandbox.exe launching, are host-side events. That is the seam your detections should live on.

Step 7: read the .wsb files that already exist

All of the above tells you whether a sandbox can launch. It does not tell you what posture the sandboxes in your environment actually use. For that you have to find and parse the configuration files, which is what the companion script does.

The fix: a hardened .wsb, then pin it with policy

Two layers. The configuration file is what a careful user writes. Policy is what stops a careless one.

Layer 1: the complete .wsb schema, element by element

A configuration file is XML with a single <Configuration> root, saved with a .wsb extension. Double-clicking it launches a sandbox with those settings. Every documented element, its documented values, and what it costs you:

Protected client is the element people skip, so be precise about it. Microsoft's wording: "When Protected Client mode is enabled, Sandbox adds a new layer of security boundary by running inside an AppContainer Isolation execution environment. AppContainer Isolation provides Credential, Device, File, Network, Process, and Window isolation." It hardens the Remote Desktop Protocol session to the sandbox. Microsoft's own caveat is that it "may restrict the user's ability to copy/paste files in and out of the sandbox" - which, for a triage sandbox, is a feature rather than a limitation.

Here is the hardened file. Every risky element is set explicitly, because relying on a default is how you end up with networking on.

Layer 2: Group Policy

This is the part the internet gets wrong. There absolutely is a Group Policy node for Windows Sandbox, backed by WindowsSandbox.admx, which ships in C:\Windows\PolicyDefinitions on a stock Windows 11 device. You do not need to download an ADMX pack.

1. On a management workstation, open Group Policy Management and edit the GPO you use for endpoint hardening.
2. Expand Computer Configuration, then Policies, then Administrative Templates.
3. Expand Windows Components and select Windows Sandbox. If the node is missing, your central store predates the ADMX; copy WindowsSandbox.admx and its .adml from a current Windows 11 device.
4. Open Allow networking in Windows Sandbox and set it to Disabled. That writes AllowNetworking = 0.
5. Open Allow clipboard sharing with Windows Sandbox and set it to Disabled.
6. Open Allow vGPU sharing for Windows Sandbox and set it to Disabled.
7. Open Allow audio input in Windows Sandbox and set it to Disabled.
8. Open Allow mapping folders into Windows Sandbox. To permit read-only triage mappings, set it to Enabled and clear the AllowWriteToMappedFolders checkbox in the options pane. To forbid mappings entirely, set it to Disabled.
9. Close the editor, link the GPO, and run gpupdate /target:computer /force on a test device.
10. Confirm the values landed under HKLM\SOFTWARE\Policies\Microsoft\Windows\Sandbox, then restart Windows Sandbox. Microsoft notes that these settings require a sandbox restart to take effect.

Step 8 is worth pausing on. AllowWriteToMappedFolders is not a separate policy in the editor. It is a checkbox element inside the Allow mapping folders into Windows Sandbox policy, which is why the Policy CSP documents it as depending on AllowMappedFolders being set to 1. That single checkbox is the cleanest control in the whole feature: it lets developers keep their mapped folders while making every mapping read-only at the platform level, regardless of what the .wsb file says.

Layer 3: Intune

Because these are ADMX-backed policies in the WindowsSandbox area of the Policy CSP, you have both routes. The Settings Catalog is the maintainable one.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Platform: Windows 10 and later. Profile type: Settings catalog. Select Create.
4. Name it something a future admin will understand, for example Win11 - Windows Sandbox hardening. Select Next.
5. On the Configuration settings tab select Add settings and search the picker for Windows Sandbox.
6. Add Allow Networking, Allow Clipboard Redirection, Allow VGPU, Allow Audio Input and Allow Write To Mapped Folders.
7. Set every one of them to Not allowed - that is the 0 value. Leave Allow Mapped Folders as Allowed if you still want read-only mappings to work.
8. Select Next through Scope tags, then assign the profile to your device group. These are device-scope settings, so assign to devices, not users.
9. Review and create. Then check Devices, then Configuration, then your profile, then Device status for a Succeeded result.

If you prefer a custom profile, or the picker in your tenant has not caught up, the OMA-URIs are documented and stable. Create a Templates, then Custom profile and add each setting as an Integer with a value of 0.

The gap: there is no policy to remove the sandbox itself

For completeness, the documented ways the feature does get enabled, so you know what you are watching for: the Turn Windows features on or off dialog, and the elevated PowerShell one-liner Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online. If you are deliberately deploying the sandbox to a triage team, that command in an Intune platform script or a Win32 app is the supported route, and Peter van der Woude wrote that pattern up years ago.

One more thing to know before you consider this closed. On Windows 11 24H2 and later, the Store-delivered Windows Sandbox app added runtime toggles: a user can turn clipboard redirection, audio and video input, and folder sharing on or off from the "..." menu after the sandbox is already running, with no .wsb file involved. A hardened configuration file is therefore a default, not a boundary. Policy is what makes it a boundary - and when a user hits a policy-blocked setting, Windows Sandbox tells them so, with the message "The following settings are enforced by your IT administrator."

Proof it worked: real audit output

The companion script is Get-SandboxConfigAudit.ps1. It reads the feature state, the prerequisites, the binaries, the services, the policy key and every .wsb file it can find, then resolves each element to its effective value and names the consequence of the risky combinations. It never enables the feature and never launches a sandbox.

Below is a genuine run on a Windows 11 Enterprise device, trimmed for length, against two test configuration files: one written the way people copy them off the internet, one hardened. The device identifiers are unchanged because there are none to redact.

Read that output as three separate confirmations. The feature state proves the device cannot currently run a sandbox at all. The absent policy key proves that if someone enables the feature, nothing constrains the configuration. And the per-file breakdown proves the point of the whole post: the dangerous file is dangerous because of what it omits, not because of what it declares.

When policy is in place and a user launches a .wsb file that asks for something blocked, the behaviour is documented and visible. Microsoft's troubleshooting table lists the message "The following settings are enforced by your IT administrator." against the cause ".wsb file has a setting enabled that is controlled via group policy." That message is your proof that layer two is doing its job. And the FAQ says the same thing from the user's side: "You can't make changes to properties if they're controlled by Group Policy."

References

Microsoft official

• Windows Sandbox overview - the disposal statement, the feature list, edition and licensing requirements, and the networking-enabled-by-default warning.
• Use and configure Windows Sandbox - the complete .wsb configuration schema, default launch properties, and every element's supported values.
• Install Windows Sandbox - prerequisites, the Containers-DisposableClientVM feature name, and the nested virtualisation commands.
• Windows Sandbox architecture - Dynamic Base Image, direct map memory sharing, WDDM GPU virtualisation, battery pass-through.
• WindowsSandbox Policy CSP - all eight policies, their OMA-URIs, registry key and value names, and the ADMX mapping.
• Troubleshoot Windows Sandbox - the error table, including the enforced-by-your-IT-administrator message and the third-party hypervisor limitation.
• Windows Sandbox command line - wsb start, list, exec, stop, share, connect and ip.
• Windows Sandbox sample configuration files - the read-only downloads example and the read-write developer examples.
• Troubleshoot Windows containers - the Hyper-V-Compute event channels and the wevtutil analytic-log commands.
• Windows 11 Security Book: Application isolation - Microsoft's summary statement on Windows Sandbox isolation.
• Secure Windows containers - the statement that only hypervisor-isolated containers provide a security boundary.
• Run Microsoft Defender Antivirus in a sandbox - the unrelated Defender feature people confuse with Windows Sandbox.

Community deep-dives

Both of the following were fetched and confirmed to load and to be genuinely on this topic.