Microsoft Defender Application Guard is a browser isolation feature that opens untrusted web content in a separate, hardened environment. It uses hardware-based virtualisation to keep the isolated browsing session apart from the host device, so malicious sites cannot easily reach local files, credentials, or the wider operating system.
How browser isolation changes the security model
Microsoft Defender Application Guard changes the browser from a direct bridge into the endpoint into a constrained, disposable workspace. That matters because web content is one of the most common paths for malicious scripts, drive-by payloads, and credential theft attempts, especially when users browse from a machine that also holds sensitive data.
The core security value is containment. If a site, ad, or embedded script misbehaves, the hostile code is meant to stay inside the isolated environment rather than inherit trust from the host OS. That reduces the chance that a browser compromise becomes local file access, token theft, or a broader endpoint compromise.
What isolation does and does not protect
Isolation is strongest when the threat is untrusted web content reaching into the host through the browser process. It is less useful if the user is tricked into handing over secrets directly, if malware already exists on the device, or if identity sessions are exposed outside the browser context. Browser isolation narrows the blast radius, but it does not replace endpoint hardening or access controls.
Microsoft Defender Application Guard is also best understood as a compensating control for risky browsing, not a cure for all web threats. It can reduce exposure from unknown sites, but it does not make malicious downloads safe, and it does not remove the need to patch the browser, operating system, and surrounding security stack.
Where it fits in an enterprise browser defence strategy
This control fits naturally alongside browser hardening, reputation filtering, and application control. Organisations usually deploy it where users regularly touch untrusted content, such as research, support, contractor, or privileged workflows that are exposed to phishing and hostile links.
It is most effective when paired with policy decisions about which sites should open in isolation, how files or clipboard data move between contexts, and how much trust the host machine should retain after a browsing session ends. Remote Browser Isolation Guide provides the broader isolation model that helps explain where this feature sits among other browser containment options.
Operational limits and related controls
Because the feature depends on a hardened virtualised boundary, its practical value is tied to platform support, policy enforcement, and user experience. If users can bypass it for convenience, or if risky content is routinely allowed to open in the normal browser, the protection becomes inconsistent.
It also works best when the organisation treats the browser as one layer in a wider defence-in-depth stack. That includes keeping the endpoint hardened, reducing local admin exposure, restricting untrusted extensions, and limiting the kinds of files and links users can open from high-risk sources. Windows Endpoint Hardening Guide and Application Allowlisting Guide are useful complements because they address the host and execution layers that browser isolation alone does not solve.
Risk and Threat Considerations
Browser isolation reduces the impact of hostile sites, but it does not eliminate phishing, credential capture, or malicious content delivery. The main risk is false confidence: organisations may assume isolated browsing makes a user safe to click anything, when the real exposure simply shifts to what happens after content leaves the isolated session or reaches a second control boundary.
Failure mechanism: An attacker uses a compromised or malicious site to trigger browser exploitation, lure a user into entering secrets, or deliver content that is later opened outside the isolated environment, turning a contained browsing event into endpoint or account compromise.
Impact: The likely outcomes are reduced containment, credential theft, malware introduction, session abuse, or a follow-on compromise of locally accessible data and corporate resources.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Browser isolation depends on knowing where risky browsers and endpoints exist. |
| CIS-3 — Data Protection | Isolation is used to reduce exposure of local files, secrets, and sensitive data during web use. | |
| CIS-6 — Access Control Management | The control reduces trust in untrusted web sessions and supports tighter access boundaries. | |
| Recommendation — Inventory browsers and endpoints so you can enforce isolation policy on the systems that need it. Limit sensitive data exposure paths so isolated browsing cannot reach critical information unnecessarily. Restrict risky browsing paths and user access so hostile web content has fewer opportunities to reach the host. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | Application Guard is fundamentally a browser isolation control that separates risky code from the host. |
| SI-3 — Malicious Code Protection | Browser isolation helps contain drive-by downloads and malicious web-delivered code. | |
| SC-7 — Boundary Protection | The feature creates a stronger boundary between untrusted web content and the local device. | |
| Recommendation — Use process isolation to separate untrusted web activity from the host environment. Apply malicious code protection to detect and contain web-delivered threats before they escape the browser boundary. Enforce boundary protections so untrusted web sessions stay separated from trusted system resources. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Isolation is a compensating control when web and browser vulnerabilities remain exploitable. |
| A.8.23 — Web filtering | Browser isolation is commonly paired with controls that govern which web destinations users can reach. | |
| Recommendation — Use technical vulnerability management to keep browsers and endpoints from depending on isolation alone. Apply web filtering to direct risky sites into the safer browsing path. | ||
Practitioner Guidance
Why practitioners should care: Treat the feature as a targeted control for untrusted browsing, not as a general endpoint security substitute. Its value depends on clearly defined use cases, especially for users who regularly encounter unknown sites or risky links.
What to watch for: Confirm that policy actually forces the risky browsing path you intended, and that users are not routinely opting out through alternate browsers, unmanaged devices, or manual workarounds. If the control is optional in practice, it will not meaningfully change risk.
Practitioner takeaway: The best deployment is narrow, deliberate, and paired with browser, endpoint, and identity protections, so isolation remains one layer in a controlled access path rather than a stand-alone promise of safety.
Related resources from NHI Mgmt Group
- When should organisations investigate Microsoft 365 application identities first?
- How should security teams govern application and device email sent from Microsoft 365?
- How should security teams detect abuse of Microsoft application credentials in Entra ID before persistence is established?
- What breaks when organisations assume OAuth 2.0 scopes fully describe what a Microsoft application can do?