- Combines VBS, HVCI, WDAC, and Credential Guard to isolate code and credentials.
- Use health attestation and conditional access with MDM and Enter ID.
- Deploy WDAC with ConfigMgr, monitor events, and sign policies.
- Complete with BitLocker, Exploit Guard, Application Guard and Firewall.
Hardening a Windows computer isn't just about enabling four options and that's it; it involves aligning hardware security, system protections and application control policies that work together. In this guide, we put all the pieces together: Credential Guard, BitLocker, AppLocker, Device Guard/WDAC, Application Guard, VBS, HVCI, and Conditional Access Health Attestation.
If you manage fleets or have high-value cargo, you'll want to deploy these layers in a planned manner. Combining them well reduces pass-the-hash attacks, bootkits, malware en Boot and execution of unauthorized software, and also enables access decisions based on the actual state of the device.
Layers of Protection in Windows: Hardware and Secure Boot
To start at the base, Windows relies on low-level protections: TPM 2.0, UEFI with Secure Boot, Boot Measurement (PCR/TCG) and ELAMThe goal is to load only legitimate code from the first millisecond and record everything that happens at startup.
El TPM (1.2 and preferably 2.0) Provides cryptographic keys, metrics, and functions to seal secrets (such as BitLocker or authentication keys) and support remote attestation. TPM 2.0 standardizes behaviors, supports SHA-256 in PCR, and offers greater algorithm flexibility.
With UEFI Secure Boot The firmware validates that the bootloader and critical Windows binaries are signed before booting, blocking malicious alternative loaders. Secure Boot Configuration Policy extends this check to sensitive parameters (for example, preventing signature test mode).
ELAM (Early Launch Anti-Malware) allows the antimalware driver to load before the rest of the drivers boot and classify drivers to prevent untrusted drivers from loading, continuing the chain of trust.
On top of all this, the Virtualization-Based Security (VBS) with Hyper-V creates an additional boundary, isolating critical services (code integrity and credentials) from the Windows kernel itself to survive even a compromised kernel.
Credential Guard in detail
Credential Guard isolates sensitive credentials (NTLM hashes and Kerberos TGTs, among others) in a protected process (LsaIso.exe) running in isolated user mode thanks to VBS. Even if an attacker gained administrator privileges, they would not be able to read LSASS memory to dump secrets.
The system uses boot and persistent keys to protect resident and stored credentials; the status is enabled by registry key and UEFI variable to prevent unauthorized remote changes. You can check its status with msinfo32 (“Device Guard Security Services Running: Hypervisor Enforced Code Integrity”).
At the level of requirements, it is requested x64 CPU with VT-x/AMD-V, IOMMU (VT-d/AMD-Vi), UEFI 2.3.1 with Secure Boot and TPM. Manufacturers like Dell emphasize that Windows 10 Enterprise/Education and HVCI-compatible drivers are key, as well as BIOS updated and virtualization options enabled.
If you manage with EMM solutions, it is possible Enable Credential Guard with or without UEFI lock through MDM policies (for example, in Citrix Endpoint Management the “Configure LSA protection” setting).
Device Guard and Hypervisor-Protected Code Integrity (HVCI)
Device Guard is not a single switch; it is the set of VBS + HVCI + code integrity policies that lock down the machine so that only trusted code (kernel and user) can run. HVCI makes kernel pages never W+X and requires integrity validation before running code.
The trust decision is defined in a code integrity policy (CIP), preferably signed, which you can generate with Microsoft tools and deploy with GPO, Intune, or Configuration Manager. Signing it adds additional protection against malicious local administrators by storing the GUID in a UEFI variable and only allowing updates signed by the same signer.
Device Guard supports rules of allow/deny, works very well in fixed workloads (kiosks, POS, SAW stations) and can be started in audit mode to capture which binaries would violate the policy before entering enforcement mode.
To validate readiness and enable it quickly, Microsoft and OEMs recommend the script DG_Readiness.ps1 with options like “–Capable –HVCI” or “–Enable –DG –AutoReboot”. The systems do not come preconfigured; features need to be enabled and policies deployed.
Windows Defender Application Control (WDAC) and its deployment
The former “Device Guard (WDAC)” is now known as Windows Defender Application Control. It is the advanced whitelist that prevents unauthorized code from running. You can manage it with Configuration Manager (current branch) to deploy directives by collections.
In ConfigMgr you can choose enforcement modes: Application enabled (trusted executables only) or Audit only (everything is executed and untrusted is logged). After processing the policy, ConfigMgr is marked as managed installer, so that the software you distribute later automatically becomes trusted.
What is usually allowed by default? System components, WHQL drivers, apps from Microsoft Store, the ConfigMgr client and what is implemented from ConfigMgr after the policy. You can also choose to trust the reputation of Microsoft Intelligent Security Graph/SmartScreen (Windows 10 1709+). Regardless of the mode chosen, .hta files are blocked.
Steps with ConfigMgr: create the policy (name, description, reboot if applicable, enforcement mode), decide whether you authorize ISG software, add specific trusted paths if you need to (for LOBs or to overcome installer quirks) and deploys to the collection and with a programming evaluation (daily by default, you can shorten it if there are problems).
Monitoring and security considerations when implementing WDAC
To monitor the processing of directives on the client, check %WINDIR%\CCM\Logs\DeviceGuardHandler.log. Blocking/auditing of executables is logged in Application and Services Logs > Microsoft > Windows > Code Integrity > Operational, and scripts/MSI in Microsoft > Windows > AppLocker.
Please note that, in audit mode or enabled without reboot, the computer is vulnerable to the installation of untrusted software that may continue to run afterward. Lab test with application mode enabled and restart before handing the equipment over to the user.
Important: If you enable compliance and then audit again on the same device, can afford untrustworthy software by state combinations. In addition, with ConfigMgr, a local administrator could bypass the directives; the robust way to prevent this is to apply a binary policy signed via GPO (not supported by ConfigMgr as of today).
AppLocker is used here only for check the managed installer; actual enforcement is enforced by WDAC. For a layered approach, WDAC defines the global foundation, and AppLocker adds user/group restrictions where appropriate.
AppLocker: Useful add-on wherever it's needed
AppLocker is still very handy for fine-tuned scenarios per user where WDAC doesn't filter by identity. You can deny, for example, a specific UWP app to a group, or limit PowerShell o cmd to support staff while the rest don't use it. Define rules for editor, path or hash with digital signature for greater robustness.
Remember that, in this context, AppLocker also participates as a mechanism to identify managed installers in the ConfigMgr flow with WDAC, but not to enforce the system base whitelist.
Application Guard and Exploit Guard: Containment and Surface Reduction
Windows Defender Application Guard isolates navigation to untrusted sites in a Hyper-V container Microsoft EdgeIf the browser crashes, the attacker would have to escape from the VM to access the host. This requires virtualization, and Microsoft recommends 8 GB of RAM at the very least practical; Enterprise mode allows you to define which domains go inside/outside the container and restrict capabilities (printing, downloads, camera, microphone).
With Windows Defender Exploit Guard you have four pillars: Attack Surface Reduction Rules (ASR) to stop typical vectors (Office macros, scripts, PSExec/WMI, PDFs with child processes, executables from USB, etc.), network protection (blocking HTTP/HTTPS to bad reputation domains via cloud), Controlled folder access (mitigates ransomware) and Protection against exploits (replaces EMET with DEP, ASLR, and additional mitigations).
If you came from EMET, you can convert policies to Exploit GuardAnd if you use the Microsoft cloud, Exploit Guard and reputation protection fuel richer prevention and response decisions.
Health Attestation and Conditional Access with MDM and Microsoft Sign In ID
Protecting is not enough: we must measure and demonstrate the status of the device to grant access to high-value resources. Windows offers hardware-based health attestation where the client sends the Microsoft service the TCG records and PCR values signed with AIK to verify boot (Secure Boot, Debug, Safe Mode), BitLocker, VBS, HVCI, ELAM and the code integrity policy fingerprint.
The typical route: the device (with TPM) gets a AIK certificate issued by the Microsoft Cloud CA (derived from the EK to preserve privacy), measures the boot (PCR0…n) and sends TCG log + PCR quote to the service. This validates signature, coherence and issues a encrypted state blob which the MDM can send back for decoding and evaluation.
Through the Health Attestation CSP, the MDM agent collects and forwards those metrics. Intune or other MDMs request the blob, the service checks nonce and boot counter, and returns state attributes (Secure Boot, db/dbx, BitLocker, VBS, ELAM, Code Integrity Policy hash, etc.) that the MDM uses to mark the device as compliant or non-compliant.
With the state in Microsoft Access ID, the Conditional Access engine decides in real time whether to allow Office 365, SaaS, or on-premises apps published by proxy. If the device is not enrolled or non-compliant, the user receives remediation instructionsIf the request is successful and authorized, Entra issues the access token. There's also AD synchronization and support for ADFS 2016 for on-prem scenarios.
Why antimalware and management are still necessary
Although a strong allowlist greatly reduces risk, vulnerabilities in user apps remain a common route of infection. The fundamental layer is apply patches and manage the park; antimalware provides complementary defense, feeds ELAM and benefits from the runtime report (System Guard) to verify that the environment has not been altered.
Windows Defender System Guard consolidates integrity controls, enables VBS by default on clean installations with supported hardware, and offers runtime certification which validates the boot state, hypervisor and signed binaries, as well as the integrity of the VBS enclave.
Requirements, licensing and platform compatibility
For health attestation, Windows Pro, Enterprise, and Education support it and usage rights come via licenses Pro/Pro Education/SE, Enterprise E3/E5, and Education A3/A5. For Credential Guard and Device Guard, Windows 10/11 Enterprise/Education and aligned hardware: x64 CPU, VT-x/AMD-V, SLAT, IOMMU (VT-d/AMD-Vi), UEFI 2.3.1 with Secure Boot, and TPM (preferably 2.0).
OEMs detail BIOS/HVCI driver compatibility by model. Examples of verified families These include the Dell Latitude, OptiPlex, Precision, and XPS Skylake/Kaby Lake generations with specific BIOS and driver versions. The bottom line is clear: Keep BIOS up to date and HVCI-compatible drivers to avoid failures when activating VBS/HVCI.
In BIOS/UEFI, enable virtualization, IOMMU, Secure Boot and secure MOR. If your CPU is Intel vPro usually implies VT-x/VT-d support; some non-vPro models also include it. Remember: Enterprise does not come from the factory on OEM; upgrades from Pro via volume licensing.
If you use third-party MDM (Citrix, for example), you can enable security for virtualization, set the platform level (Secure Boot with VBS or with DMA protection) and configure LSA protection (enable Credential Guard with or without UEFI lock); the server will only deploy if it detects configuration misalignment regarding the device.
BitLocker, performance, update, and firewall
About updates, Windows Update can postpone downloads on data networks (3G/4G considered metered usage) to save costs, resuming when returning to Wi‑Fi. If a critical update, is prioritized even in scenarios of limited connectivity.
For the firewall, manage the Windows Defender Firewall from the Control Panel or “Firewall with Advanced Security”. It is recommended to enable it with incoming and outgoing filtering tailored to needs (e.g., only corporate browsers to the Internet).
As a complement, AppLocker offers rules for manufacturer/firm for your own apps; “Device Guard approval” for apps appears when they are signed by Microsoft Store, your PKI, or a trusted CA, fitting into the trust strategy.
A practical note on closing the loop: protecting the firmware environment. Blocks access to boot options to prevent someone with physical access from disabling Secure Boot or booting from USB. And if you want to prevent the system security configuration tool from running, add a rule that deny C:\Windows\System32\SecConfig.efi in your integrity policy.
With all these layers, you move from a purely preventative approach to one balanced between prevention, detection and response, where the device proves its status, and identities and policies decide on each access point. By implementing it in an orderly manner in the lab, enabling VBS/HVCI, signing WDAC policies, using AppLocker where appropriate, measuring with state attestation, and coordinating with BitLocker, Exploit Guard, and Application Guard, you truly raise the bar for any attacker.
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.