Setting Up Windows Defender Application Guard for Isolated Browsing
Running an untrusted website in a hardware-isolated container that's automatically discarded afterward, instead of risking whatever a malicious page might do to your regular browsing session.
Windows Defender Application Guard runs an untrusted browsing session inside a hardware-isolated, disposable container — separate from your regular desktop and its files, credentials, and other running applications — specifically for situations where visiting a genuinely untrusted or suspicious website is unavoidable but you don’t want to risk whatever that page might attempt against your actual system.
What isolation actually means here, concretely
Application Guard uses the same virtualization-based security foundation as Hyper-V and Windows’s other VBS-based protections to run the browsing session in a genuinely separate, lightweight container — not simply a sandboxed browser process on your regular desktop, but a container with no direct access to your regular file system, installed applications, saved credentials, or other browser tabs. A website that successfully exploits a browser vulnerability inside an Application Guard session is contained within that isolated container, without a direct path to your actual desktop environment.
Checking prerequisites before enabling
Application Guard requires hardware virtualization support (the same underlying requirement as Hyper-V) and a supported edition of Windows — checking virtualization support directly:
systeminfo | findstr /i "Hyper-V"Confirming “Virtualization Enabled In Firmware: Yes” in the output rules out the most common reason enabling Application Guard fails outright — virtualization support disabled at the BIOS/UEFI level, which needs to be enabled there directly before Windows-side configuration can succeed.
Enabling the feature
Enable-WindowsOptionalFeature -Online -FeatureName Windows-Defender-ApplicationGuardA restart is required after enabling the feature for it to become fully active.
Launching an isolated browsing session
Once enabled, Microsoft Edge presents an explicit “New Application Guard window” option, which opens a browsing session running inside the isolated container rather than your regular browsing profile — visually similar to an ordinary browser window, but with a distinct visual indicator confirming it’s actually running in the isolated Application Guard context rather than your normal profile.
Configuring which sites are treated as trusted versus isolated
Application Guard’s real value depends on correctly distinguishing trusted sites (which should open normally, in your regular browsing session) from untrusted ones (which should be forced into the isolated container) — this is configured via Group Policy or Microsoft Intune, defining your organization’s actual trusted network boundary:
Computer Configuration > Administrative Templates > Windows Components >
Microsoft Defender Application Guard > "Network isolation settings"Defining your organization’s internal network ranges and trusted cloud services here means only genuinely external, untrusted sites get automatically routed into isolated Application Guard sessions, rather than requiring users to manually decide for every single site.
Forcing all untrusted sites through Application Guard automatically
Beyond the manual “New Application Guard Window” option, enabling automatic enforcement routes any site not matching your defined trusted list through isolation automatically, without relying on users remembering to manually choose isolation for suspicious sites themselves:
Computer Configuration > Administrative Templates > Windows Components >
Microsoft Defender Application Guard > "Configure Microsoft Defender Application Guard clipboard settings"alongside the network isolation policy above — together these determine both which sites get isolated automatically and what’s allowed to cross the isolation boundary (clipboard content, in this specific case), since even a legitimately isolated session could otherwise leak data back to the host through an unrestricted clipboard.
Why the container is disposable, and why that matters
Every Application Guard session starts completely fresh and is discarded entirely when closed — no persistent state, cookies, downloaded files, or any other artifact survives between sessions unless explicitly configured otherwise. This is a deliberate design choice: even if a session was compromised during use, nothing persists for that compromise to build on in a subsequent session, which is a meaningfully stronger guarantee than a regular browser’s ordinary security features (which generally aim to prevent compromise, but don’t provide the same clean-slate guarantee if prevention fails).
What this doesn’t protect against
Application Guard specifically isolates the browsing session itself — it doesn’t protect against a user being socially engineered into manually downloading and running a malicious file outside the isolated container, or against phishing that doesn’t rely on an actual browser exploit at all. It’s a targeted defense against a specific threat model (browser-exploit-based compromise from visiting an untrusted page), not a comprehensive answer to every category of web-based threat.
Why this is worth deploying for specific high-risk browsing scenarios
Application Guard’s overhead (a genuinely separate container has real resource cost compared to an ordinary browser tab) means it’s not necessarily worth enabling for all everyday browsing. It’s most directly valuable for specific, identifiable high-risk scenarios — security researchers investigating suspicious URLs, employees whose role requires visiting external, unvetted websites regularly, or as a standing protection for an organization’s most exposed user population — rather than as a blanket replacement for ordinary browsing across an entire organization regardless of actual risk exposure.