diff --git a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md
index 5c320db82c..5b2545753c 100644
--- a/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md
+++ b/windows/device-security/device-guard/requirements-and-deployment-planning-guidelines-for-device-guard.md
@@ -57,12 +57,7 @@ The following tables describe additional hardware and firmware qualifications, a
| Protections for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|------|
-| Text | Text | Text |
-
-
-| Protections for Improved Security | Description | Security benefits |
-|---------------------------------------------|----------------------------------------------------|------|
-| Firmware: **Securing Boot Configuration and Management** |
• BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. |
• BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
+| Firmware: **Securing Boot Configuration and Management** | • BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | • BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
@@ -71,9 +66,9 @@ The following tables describe additional hardware and firmware qualifications, a
| Protections for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|-----|
-| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). |
• Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. |
+| Firmware: **Hardware Rooted Trust Platform Secure Boot** | Boot Integrity (Platform Secure Boot) must be supported. See the Windows Hardware Compatibility Program requirements under [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](https://msdn.microsoft.com/library/windows/hardware/dn932807(v=vs.85).aspx#system_fundamentals_firmware_cs_uefisecureboot_connectedstandby)
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](https://msdn.microsoft.com/en-us/library/windows/hardware/mt712332.aspx). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. |
| Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. |
-| Firmware: **Securing Boot Configuration and Management** |
• Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.|
• Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
+| Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
@@ -82,8 +77,8 @@ The following tables describe additional hardware and firmware qualifications, a
| Protection for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|------|
-| Firmware: **VBS enablement of NX protection for UEFI runtime services** |
• VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
• PE sections need to be page-aligned in memory (not required for in non-volitile storage).
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
• No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.
Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.
Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code |
• Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. |
-| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.|
• Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. |
+| Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be exceutable.
• UEFI runtime service must meet these requirements:
• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
• PE sections need to be page-aligned in memory (not required for in non-volitile storage).
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
• No entries may be left with neither of the above attributes, indicating memory that is both exceutable and writable. Memory must be either readable and executable or writeable and non-executable.
Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.
Please also note the following:
• Do not use sections that are both writeable and exceutable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. |
+| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](http://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. |
## Device Guard deployment in different scenarios: types of devices