Understanding Device Guard in Windows 10
Antivirus Usually Had to Decide Something Was Dangerous
Traditional malware protection often begins with detection.
A security product examines a file, its behavior, its reputation, or other characteristics and attempts to determine whether the software represents a threat. When the answer is yes, execution can be blocked or the file can be removed.
That model has protected computers for decades, but it also gives attackers an obvious objective: create malicious code the defensive system does not yet recognize.
Detection Begins With a Question About the File
The traditional security model asks whether software appears malicious. If a new threat can avoid producing the signals the protection expects, the computer may still allow the program to begin running.
Not Recognized as Malware Did Not Mean Known to Be Safe
A newly created executable may have no established reputation and no known malicious signature.
That does not make it dangerous automatically. Legitimate programs are created every day. But it also means the absence of a malware detection cannot by itself establish that the file should be trusted on a sensitive computer.
Enterprise systems sometimes needed a stricter question.
Unknown Is Different From Trusted
A security scanner may find no evidence that an application is malicious while an organization still has no reason to permit that application to execute on a controlled workstation.
Device Guard Could Begin With What Was Allowed to Run
Device Guard gave organizations a way to approach application security from the opposite direction.
Instead of permitting arbitrary software unless something identified it as malicious, an organization could define which applications, drivers, publishers, or other code should be trusted. Code outside the established policy could then be prevented from executing.
The default question could become whether the software belonged there at all.
Allow Known Code Instead of Chasing Every Unknown Threat
A restrictive application-control policy reduces dependence on identifying every possible malicious program because software that has not satisfied the organization’s trust rules does not automatically receive permission to run.
Trust Could Be Based on the Software the Organization Approved
Device Guard was not designed around maintaining a catalog of every malicious file in existence.
An organization could create Code Integrity policies defining software that should be accepted. Trust could be established through mechanisms such as approved publishers and signed code rather than waiting for unwanted software to appear and then adding it to a blacklist.
This reverses the traditional security relationship.
Block Known Bad
Traditional defensive tools can identify software associated with known threats and prevent or remove it when the malicious characteristics are recognized.
Allow Known Good
Application control can establish which code is trusted to execute and deny software that falls outside the organization’s approved policy.
A New Attack Did Not Need to Be Recognized If It Was Never Authorized
Zero-day attacks are difficult partly because defenders may have little or no prior knowledge of the malicious code or vulnerability being used.
A restrictive application-control policy can change that problem. Even if a malicious executable is completely new, the file still needs to satisfy the system’s trust policy before it can execute.
Novelty no longer guarantees an opportunity to run.
Unknown Malware Could Still Be Untrusted Code
Device Guard did not need a malware signature for every new executable when policy already established that only specifically trusted software was permitted to run.
Windows Could Consider Who Published the Code
A digital signature can provide cryptographic information about the publisher associated with a piece of software and whether the signed content has been altered after signing.
Device Guard policies could use signing relationships as part of the trust decision. An organization might choose to permit software from selected publishers rather than manually approving every individual executable those publishers release.
This could make restrictive application control practical at larger scale.
A Signature Establishes Identity Not Perfection
Digitally signed software is not automatically safe. Signing helps establish provenance and integrity, while the organization still decides whether that publisher or particular code should be trusted.
An Executable Could Be Blocked Without Being Proven Malicious
Many malicious programs historically arrived without a trustworthy digital signature.
Under a restrictive Code Integrity policy, an unsigned executable may simply fail to satisfy the rules required for execution. Windows does not necessarily need to demonstrate that the file contains malware before refusing to run it.
The absence of established trust can itself be enough.
Blocked Does Not Necessarily Mean Infected
When application control prevents software from running, the result may indicate that the program does not satisfy the organization’s trust policy rather than that Windows has positively identified the file as malware.
Internal Software Did Not Need a Public Publisher
Businesses frequently depend on custom applications developed specifically for their own operations.
Those programs may not come from a commercial software publisher recognized across the Internet. An organization can nevertheless establish trust for its internal software through appropriate signing and policy mechanisms.
The trust model belongs to the organization controlling the device.
Enterprise Trust Can Be Private
A program does not need to be globally recognized to be approved on a managed computer. The organization can establish its own trusted software relationships according to operational requirements.
Malicious Kernel Code Could Be More Dangerous Than an Ordinary Application
Device drivers operate much closer to the Windows kernel than normal desktop applications.
A malicious or compromised driver can therefore create serious security consequences. Kernel-level code may gain access to resources and capabilities that ordinary applications cannot reach.
Code Integrity needed to protect this layer as well.
Kernel Privilege Magnifies the Consequences of Untrusted Code
Preventing unauthorized drivers from loading is particularly important because code executing in the kernel can potentially interfere with the mechanisms Windows uses to protect the rest of the operating system.
Windows 10 Made the Trust Policy More Powerful
Code-signing and kernel integrity protections did not begin with Windows 10.
What changed was the ability to combine configurable Code Integrity policy with newer platform security features to create a much more restrictive execution environment. Organizations could define trusted code across drivers, system components, and applications.
The operating system could become deliberately selective about execution.
Device Guard Was a Combination of Protections
The name described a security approach built from application-control policy, Code Integrity, platform security, and optional virtualization-based protection rather than one isolated executable scanning feature.
Malware Could Try to Attack the Mechanism Enforcing the Rules
A strict policy matters only while the mechanism enforcing it remains trustworthy.
If highly privileged malware could simply modify Code Integrity or manipulate the information used to decide whether software was approved, the attacker might defeat the policy and then execute whatever code it wanted.
The enforcement mechanism therefore needed protection of its own.
Protecting the Rulebook Is as Important as Writing the Rules
An application-control policy cannot provide a strong security boundary if malware with sufficient privilege can silently modify or bypass the component responsible for enforcing that policy.
The Hypervisor Could Help Protect Code Integrity From Normal Windows
Windows 10 introduced virtualization-based security capabilities that could isolate sensitive security functions from the normal operating-system environment.
Device Guard could use this architecture to protect Code Integrity through a Hyper-V-enforced environment. The mechanism determining whether code was trusted could therefore receive stronger isolation than ordinary process or kernel permissions alone could provide.
Virtualization became a defensive technology.
The Security Decision Could Live Behind a Stronger Boundary
Using virtualization-based protection makes it more difficult for malware operating in the normal Windows environment to tamper directly with the code-integrity mechanisms controlling what software may execute.
The Hypervisor Could Protect the Main Operating System
Many users associated Hyper-V with running a second operating system inside a virtual machine.
Windows 10 demonstrated another use. The hypervisor could help establish isolated security environments used by the primary Windows installation itself. No traditional guest desktop needed to be visible to the user.
Virtualization could exist purely to strengthen security boundaries.
A Hypervisor Can Separate Security Domains
The processor’s virtualization capabilities allow a layer beneath the ordinary Windows kernel to control access to memory and execution resources, creating boundaries that the normal operating system does not enforce entirely by itself.
Being an Administrator Did Not Have to Mean Being Allowed to Run Anything
Traditional Windows administration gives privileged users enormous control over the computer.
That creates a problem when an attacker gains administrative privileges. Malware operating with those rights may attempt to disable security controls, install drivers, alter system configuration, or execute additional payloads.
Device Guard was designed to preserve application-control restrictions even in a highly privileged environment.
Privilege and Trust Became Different Concepts
A user or process having administrative authority did not necessarily mean that every executable it attempted to launch should automatically become trusted code.
The Application Rules Themselves Could Be Protected
Organizations could sign Code Integrity policies used for restrictive Device Guard configurations.
Signing helps establish the authenticity and integrity of the policy. This makes unauthorized alteration more difficult because changing the policy contents breaks the cryptographic relationship established by the signature.
The trust rules can therefore receive protection similar in principle to the code they govern.
Security Policy Is a High-Value Asset
An attacker who can freely rewrite the list of trusted software can simply approve malicious code, so protecting the policy from unauthorized modification is essential to maintaining application control.
Application Control Was Stronger When Startup Was Trusted Too
A secure operating-system policy has limited value if an attacker can compromise the computer before that policy begins operating.
Secure Boot uses UEFI firmware trust mechanisms to help prevent unauthorized components from entering the early boot chain. Device Guard could build on that trusted platform foundation as Windows continued enforcing code policy later in startup and during normal operation.
The defenses formed a sequence.
Trust Could Begin Before Windows Loaded
Secure Boot helps establish confidence in early startup components, while Code Integrity and application-control policy continue making trust decisions as Windows loads drivers and applications.
Firmware Could Influence What Happened Much Later at the Desktop
Firmware was once largely viewed as the mechanism that initialized hardware and started the operating system.
Modern Windows security gave UEFI a much larger role. Secure Boot and related platform capabilities help establish a trustworthy foundation on which later operating-system protections depend.
A security feature visible at application launch can therefore depend on firmware behavior established seconds earlier.
Modern Security Crosses Traditional Layers
Firmware, processor virtualization, the hypervisor, the Windows kernel, Code Integrity, and application policy can all participate in deciding whether software ultimately receives permission to execute.
Not Every Windows 10 Computer Could Provide the Strongest Configuration
Virtualization-based Device Guard protections depended on compatible processor, firmware, and platform capabilities.
A computer might run Windows 10 perfectly well while lacking or having disabled one of the hardware features required for the strongest security configuration. The operating-system version alone therefore did not determine the protection available.
Platform design became part of the security calculation.
Windows Compatibility and Security Capability Are Different
A machine capable of running Windows 10 does not automatically satisfy every hardware and firmware requirement for virtualization-based Code Integrity or other advanced Device Guard protections.
Old Hardware Software Might Not Behave Under Stronger Integrity Rules
Drivers developed for older Windows environments may make assumptions that conflict with virtualization-based Code Integrity.
A driver that does not satisfy the required integrity or compatibility rules may fail to load when stronger protections are active. Because drivers often control essential hardware, deploying the feature without compatibility testing could produce operational problems.
Security had to be introduced deliberately.
Test Drivers Before Enforcing the Strongest Policy
Business systems with specialized printers, scanners, industrial equipment, legacy expansion cards, or proprietary hardware should be evaluated for driver compatibility before restrictive Code Integrity enforcement is deployed broadly.
Administrators Needed to Learn What Legitimate Software Actually Ran
Immediately blocking every application outside a newly created policy could disrupt normal business operations.
An organization first needs to understand which executables, drivers, scripts, and applications employees legitimately depend on. Audit-oriented deployment can help identify software that would be affected before enforcement becomes strict.
The policy can then be refined from real usage.
Application Control Requires Inventory
A restrictive allow policy works best when administrators understand the legitimate software environment well enough to distinguish necessary applications from code that has no business reason to execute.
Legitimate Software Could Be Blocked Along With Malware
Device Guard does not know whether an unapproved application is important to an employee’s job.
If the program falls outside the configured trust policy, the system may block it exactly as instructed. That behavior is a security success from the enforcement engine’s perspective even when the policy itself was incomplete.
Planning determines whether strict control remains usable.
Correct Enforcement Can Still Produce the Wrong Business Result
When approved software is omitted from policy, the application-control system may function exactly as designed while preventing legitimate work. Policy quality is therefore as important as enforcement quality.
Trusting Everything Signed Would Not Necessarily Be Safe
Digital signatures are useful, but signed malware and compromised publishers can exist.
An application-control strategy that accepts every signed executable without considering the publisher or other policy conditions can create more trust than the organization intended. The goal is not simply to find a signature but to establish meaningful trust.
Policy design requires judgment.
Signed and Trusted Are Not Synonyms
A valid digital signature can identify the source associated with software and show whether signed content was altered, but the organization still decides whether that source belongs inside its trusted execution environment.
Software Changes Without Becoming a Different Product
Business applications receive updates, patches, and new versions throughout their useful lives.
If policy identifies software too narrowly, every legitimate update may appear different enough to require administrative intervention. If policy is too broad, unwanted software may qualify for trust.
Practical application control must balance precision and maintainability.
Publisher Rules Can Reduce Maintenance
Trust relationships based appropriately on a known publisher can allow legitimate future versions to remain usable without requiring administrators to approve every changed executable individually.
Malicious Code Did Not Always Arrive as a Traditional EXE File
Attackers can abuse scripting environments and other interpreters already present on a Windows computer.
This makes application control more complicated than simply deciding which standalone executable files are allowed. The surrounding script and application-control architecture also needs to account for code that can execute through trusted interpreters.
A trusted tool can potentially be used for an untrusted purpose.
Living Off the System Changes the Threat
Attackers may attempt to use legitimate Windows components to perform malicious actions, so application control should be considered part of a broader security strategy rather than a complete replacement for monitoring and malware protection.
Blocking Untrusted Applications Solved a Different Security Problem
Application control and malware detection provide overlapping but different protections.
Device Guard can prevent software outside policy from executing, while antimalware tools can inspect files and behavior for evidence of known or suspicious threats. A trusted application can still contain a vulnerability, and an approved component can potentially be abused.
The protections work best as layers.
Application Control
Determines whether code satisfies the organization’s trust policy and therefore receives permission to execute.
Antimalware
Looks for evidence that files, behavior, or activity represent malicious or suspicious threats that should be blocked or removed.
One Protected Execution While the Other Protected Credentials
The similar names could easily create confusion.
Device Guard focused on controlling which code was trusted to run and protecting Code Integrity. Credential Guard used virtualization-based security to isolate valuable authentication secrets from the normal Windows environment.
Both could use virtualization, but their primary security objectives were different.
Prevent the Code and Protect the Identity
Device Guard could make it harder for untrusted code to execute, while Credential Guard could make selected credentials harder to steal if malicious code nevertheless gained substantial control of the computer.
Attestation Reported Security State Rather Than Choosing Applications
Windows 10 introduced several hardware-backed enterprise security technologies at the same time.
Device Health Attestation could help a management system evaluate whether selected platform security conditions were present. Device Guard addressed execution trust. Credential Guard addressed credential isolation.
The technologies complemented one another without performing the same job.
Windows 10 Was Building a Security Stack
Startup trust, device health, application control, credential isolation, encryption, and malware protection could contribute separate layers rather than requiring one security product to solve every problem.
Application Freedom and Application Control Pull in Opposite Directions
Some computers exist specifically to run a predictable collection of approved software.
Point-of-sale systems, kiosks, specialized workstations, high-value administrative computers, and tightly managed enterprise endpoints can benefit greatly from strict execution control. A development machine where users constantly build and test new programs presents a very different requirement.
The appropriate policy depends on the computer’s purpose.
Start With Systems That Have Predictable Software Needs
Restrictive application control is easiest to manage on computers whose legitimate workload is stable and well understood, making unexpected software execution easier to classify as unnecessary.
Replacing Hardware Might Introduce a Driver the Policy Did Not Expect
A hardware repair can require a different driver version or a newly installed device package.
On a tightly controlled business computer, that driver may need to satisfy existing Code Integrity policy before Windows allows it to load. A replacement component can therefore be physically functional while its supporting software remains blocked by enterprise security policy.
The symptom can look like failed hardware.
Consider Application Control When New Hardware Will Not Start
If a repaired managed computer detects replacement hardware but its driver will not load, investigate Code Integrity and organizational application-control policy before concluding that the replacement part is defective.
Windows Might Be Refusing the Software Intentionally
Technicians commonly troubleshoot driver failures by reinstalling packages, updating Windows, or replacing hardware.
Those steps may not solve a Device Guard policy conflict. If the driver is outside the organization’s trusted policy, repeatedly reinstalling the same package does not change the reason Windows refuses to load it.
Security logs and policy information become part of diagnosis.
Blocked and Broken Can Look Similar
A component may fail to operate because its driver is damaged, incompatible, or missing, but it can also fail because Windows deliberately prevented an otherwise functional driver from loading.
A Working Device Should Not Require Destroying the Trust Model
When application control interferes with legitimate hardware or software, disabling the protection entirely may appear to solve the immediate problem.
But that approach removes the security boundary the organization intentionally deployed. The correct solution is to identify an approved compatible driver or update the trust policy through the proper administrative process.
Security configuration is part of the system’s intended design.
Do Not Treat Enterprise Security as an Obstacle to Remove
A managed computer should be returned with its expected security controls intact unless the organization responsible for the device deliberately changes those requirements.
The Organization Could Decide What Even an Administrator Was Allowed to Execute
For many years, obtaining administrator privileges represented one of the attacker’s most important objectives on Windows.
Device Guard demonstrated a stronger enterprise model in which administrative privilege and code trust could be separated. An administrator might have authority to configure many aspects of the system without automatically granting every arbitrary executable permission to run.
The machine’s trust policy could remain a separate boundary.
Administrator Was a Role Not a Universal Trust Certificate
Giving a person or process elevated Windows privileges did not have to mean accepting every piece of code that elevated context attempted to introduce.
Microsoft Was Moving From Detecting Threats Toward Controlling Execution
Application allowlisting was not a new security concept in 2015.
What Windows 10 changed was the depth at which Microsoft could combine configurable Code Integrity with Secure Boot, hardware security, and virtualization-based protection. Application trust could become part of the operating system’s security architecture rather than simply another utility running above it.
The policy could reach from startup into everyday application execution.
The Operating System Could Enforce an Organization’s Definition of Trusted Code
Instead of depending entirely on identifying bad software after it appeared, Windows could be configured so that code first had to satisfy established trust rules before receiving permission to run.
Malware Could Be Stopped Before Its Behavior Needed to Be Analyzed
Once malicious software begins executing, the security system may need to detect what the program is doing and respond quickly enough to prevent damage.
Application control moves an important decision earlier. If the executable does not satisfy the trust policy, Windows can prevent execution before the program has an opportunity to demonstrate malicious behavior.
Prevention occurs at the trust boundary.
The safest unknown program on a tightly controlled computer may be the one that never receives permission to execute in the first place.
Windows 10 Made Trust a Requirement Before Code Could Run
Device Guard represented a significant change in the security philosophy available to Windows enterprises.
Instead of assuming software could execute unless a defensive product identified a reason to stop it, organizations could define the applications, publishers, drivers, and code they trusted. Configurable Code Integrity could enforce those decisions, while virtualization-based security could provide stronger protection for the integrity mechanism itself.
The result was not a replacement for antivirus, patching, monitoring, or careful administration. It was another security boundary with a fundamentally different purpose: unknown code no longer had to be proven malicious before Windows had a reason to keep it from running.
