Microsoft Security Servicing Criteria for Windows
Our commitment to protecting customers from vulnerabilities in our software, services, and devices includes providing security updates and guidance that address vulnerabilities when they are reported to Microsoft. We also want to be transparent with security researchers and our customers in our approach. This document helps to describe the criteria the Microsoft Security Response Center (MSRC) uses to determine whether a reported vulnerability affecting up-to-date and currently supported versions of Windows may be addressed through servicing or in the next version of Windows. For vulnerabilities in Windows, servicing takes the form of a security update or applicable guidance, most commonly released on Update Tuesday (the second Tuesday of each month).
Security Servicing Criteria
The criteria used by Microsoft when evaluating whether to provide a security update or guidance for a reported vulnerability involves answering two key questions:
- Does the vulnerability violate the goal or intent of a security boundary or a security feature?
- Does the severity of the vulnerability meet the bar for servicing?
If the answer to both questions is yes, then Microsoft’s intent is to address the vulnerability through a security update and/or guidance that applies to affected and supported offerings where commercially reasonable. If the answer to either question is no, then by default the vulnerability will be considered for the next version or release of Windows but will not be addressed through a security update or guidance, though exceptions may be made.
This document addresses the most commonly reported vulnerabilities, but as security is an ever-evolving landscape there may be vulnerabilities that are not covered by this criteria or the criteria may be adapted due to changes in the threat landscape. Microsoft addresses vulnerabilities based on the risk they pose to customers and may at any time choose to address, or not address, reports based on the assessed risk.
Security boundaries and features Microsoft intends to service
Microsoft’s software, services, and devices rely on a number of security boundaries and security features, as well as the security of the underlying hardware on which our software depends, in order to achieve our security goals.
Security boundaries
A security boundary provides a logical separation between the code and data of security domains with different levels of trust. For example, the separation between kernel mode and user mode is a classic and straightforward security boundary. Microsoft software depends on multiple security boundaries to isolate devices on the network, virtual machines, and applications on a device. The following table summarizes the security boundaries that Microsoft has defined for Windows.
| Security Boundary | Security Goal | Intent is to service? | Bounty? |
|---|---|---|---|
| Network boundary |
An unauthorized network endpoint cannot access or tamper with the code and data on a customer’s device.
|
Yes
|
|
| Kernel boundary |
A non-administrative user mode process cannot access or tamper with kernel code and data. This is applicable for the NT kernel and the Secure Kernel. For the NT kernel only, Administrator-to-kernel is not a security boundary.
|
Yes
|
|
| Process boundary |
An unauthorized user mode process cannot access or tamper with the code and data of another process.
|
Yes
|
|
| AppContainer sandbox boundary |
An AppContainer-based sandbox process cannot access or tamper with code and data outside of the sandbox based on the container capabilities
|
Yes
|
|
| User boundary |
A user cannot access or tamper with the code and data of another user without being authorized.
|
Yes
|
|
| Session boundary |
A user logon session cannot access or tamper with another user logon session without being authorized.
|
Yes
|
|
| Web browser boundary |
An unauthorized website cannot violate the same-origin policy, nor can it access or tamper with the native code and data of the Microsoft Edge web browser sandbox.
|
Yes
|
|
| Virtual machine boundary |
An unauthorized Hyper-V guest virtual machine cannot access or tamper with the code and data of another guest virtual machine; this includes Hyper-V Isolated Containers.
|
Yes
|
|
| Virtual Secure Mode (VSM) Boundary |
Data and code marked as private within a Virtual Trust Level (VTL) cannot be accessed or tampered with by code executing inside a lower VTL.
|
Yes
|
|
| Virtualization-Based Security (VBS) Boundary |
Data and code within a VBS Trustlet or Enclave cannot be accessed or tampered with by code executing outside of the VBS Trustlet or Enclave if not explicitly shared. Data and code of a VBS Trustlet or Enclave are always accessible by the Secure Kernel.
|
Yes
|
Non-boundaries*
Some Windows components and configurations are explicitly not intended to provide a robust security boundary. These components are summarized in the following table.
*Note: The following list is non-exhaustive and is intended to address components commonly mistaken as boundaries. By default, components are not considered boundaries unless explicitly named as such.
| Component | Explanation |
|---|---|
| Windows Server Containers |
Windows Server Containers provide resource isolation using a shared kernel but are not intended to be used in hostile multitenancy scenarios. Scenarios that involve hostile multitenancy should use Hyper-V Isolated Containers to strongly isolate tenants. If an application runs as an unprivileged user account within a container, the normal Windows security boundaries apply to this application. The application should not be able to elevate to administrator, gain access to other user’s resources, etc |
| Administrator to Kernel |
Administrative processes and users are considered part of the Trusted Computing Base (TCB) for Windows and are therefore not strong isolated from the kernel boundary. Administrators are in control of the security of a device and can disable security features, uninstall security updates, and perform other actions that make kernel isolation ineffective. This includes actions which require Administrator permissions like registry tampering with HKEY_LOCAL_MACHINE and any attack where the attacker has Local or Domain Administrator access.
|
| Hyper-V Administrators Group |
The Hyper-V Administrators group is intended to allow Windows server administrators to manage their Hyper-V environments without having to log into the server as a Local Administrator. It is not intended to be a security boundary from full Administrators; group membership should be restricted and controlled as with other administrative groups.
|
Security features
Security features build upon security boundaries to provide robust protection against specific threats. In some cases, the goal of a security feature is to provide robust protection against a threat and there are expected to be no by-design limitations that would prevent the security feature from achieving this goal. For security features in this category, Microsoft intends to address reported vulnerabilities through servicing as summarized by the following table.
| Category | Security Features | Security Goal | Intent is to service? | Bounty? |
|---|---|---|---|---|
| Device Security |
BitLocker
|
Data that is encrypted on disk cannot be obtained when the device is turned off.
|
Yes
|
|
| Device Security |
Secure Boot
|
Only authorized code can run in the pre-OS, including OS loaders, as defined by the UEFI firmware policy.
|
Yes
|
|
| Platform Security |
Windows Defender System Guard (WDSG)
|
Improperly signed binaries cannot execute or load in accordance with the Application Control policy for the system. Bypasses leveraging applications which are permitted by the policy are not in scope.
|
Yes
|
|
| Application security |
Windows Defender Application Control (WDAC)
|
Only executable code, including scripts run by enlightened Windows script hosts, that conforms to the device’s policy can run. Bypasses leveraging applications which are permitted by the policy are not in scope. Bypasses requiring administrative rights are not in scope.
|
Yes
|
|
| Identity and access control |
Windows Hello / Biometrics
|
An attacker cannot spoof, phish, or breach NGC (Next Generation Credential) to impersonate a user.
|
Yes
|
|
| Identity and access control |
Windows Resource Access Control
|
An identity (user, group) cannot access or tamper with a resource (file, named pipe, etc.) unless explicitly authorized to do so
|
Yes
|
|
| Cryptography API: Next Generation (CNG) |
Platform Cryptography
|
Algorithms are implemented to specification (e.g. NIST) and do not leak sensitive data.
|
Yes
|
|
| Health attestation |
Host Guardian Service (HGS)
|
Assess the identity and health of a caller issuing or withholding health claims necessary for downstream cryptographic operations.
|
Yes
|
|
| Authentication Protocols |
Authentication Protocols
|
Protocols are implemented to specification and an attacker cannot tamper with, reveal sensitive data, or impersonate users gaining elevated privileges.
|
Yes
|
Defense-in-depth security features
In some cases, a security feature may provide protection against a threat without being able to provide a robust defense. These security features are typically referred to as defense-in-depth features or mitigations because they provide additional security but may have by design limitations that prevent them from fully mitigating a threat. A bypass for a defense-in-depth security feature by itself does not pose a direct risk because an attacker must also have found a vulnerability that affects a security boundary, or they must rely on additional techniques, such as social engineering to achieve the initial stage of a device compromise.
The following table summarizes the defense-in-depth security features that Microsoft has defined which do not have a servicing plan. Any vulnerability or bypass that affects these security features will not be serviced by default, but it may be addressed in a future version or release. Many of these features are being continuously improved across each product release and are also covered by active bug bounty programs.
In some cases, defense-in-depth security features may take a dependency that will not meet the bar for servicing by default. As a result, these defense-in-depth security features will also not meet the bar for servicing by default. An example of this can be observed with Shielded Virtual Machines which takes a dependency on an administrator not being able to compromise the kernel or a Virtual Machine Worker Process (VMWP) which is protected by Protected Process Light (PPL). In this case, Administrator-to-Kernel and PPL are not serviced by default.
| Category | Security feature | Security goal | Intent is to service? | Bounty? |
|---|---|---|---|---|
| User safety |
User Account Control (UAC)
|
Prevent unwanted system-wide changes (files, registry, etc) without administrator consent
|
No
|
No
|
| User safety |
AppLocker
|
Prevent unauthorized applications from executing
|
No
|
No
|
| User safety |
Controlled Folder Access
|
Protect access and modification to controlled folders from apps that may be malicious
|
No
|
No
|
| Exploit mitigations |
Mark of the Web (MOTW)
|
Prevent active content download from the web from elevating privileges when viewed locally
|
No
|
No
|
| Exploit mitigations |
Data Execution Prevention (DEP)
|
An attacker cannot execute code from non-executable memory such as heaps and stacks
|
No
|
|
| Exploit mitigations |
Address Space Layout Randomization (ASLR)
|
The layout of the process virtual address space is not predictable to an attacker (on 64-bit)
|
No
|
|
| Exploit mitigations |
Kernel Address Space Layout Randomization (KASLR)
|
The layout of the kernel virtual address space is not predictable to an attacker (on 64-bit)
|
No
|
No
|
| Exploit mitigations |
Arbitrary Code Guard (ACG)
|
An ACG-enabled process cannot modify code pages or allocate new private code pages
|
No
|
|
| Exploit mitigations |
Code Integrity Guard (CIG)
|
A CIG-enabled process cannot directly load an improperly signed executable image (DLL)
|
No
|
|
| Exploit mitigations |
Control Flow Guard (CFG)
|
CFG protected code can only make indirect calls to valid indirect call targets
|
No
|
No
|
| Exploit mitigations |
Child Process Restriction
|
A child process cannot be created when this restriction is enabled
|
No
|
|
| Exploit mitigations |
SafeSEH/SEHOP
|
The integrity of the exception handler chain cannot be subverted
|
No
|
|
| Exploit mitigations |
Heap randomization and metadata protection
|
The integrity of heap metadata cannot be subverted and the layout of heap allocations is not predictable to an attacker
|
No
|
|
| Exploit mitigations |
Windows Defender Exploit Guard (WDEG)
|
Allow apps to enable additional defense-in-depth exploit mitigation features that make it more difficult to exploit vulnerabilities
|
No
|
No
|
| Platform lockdown |
Protected Process Light (PPL)
|
Prevent non-administrative non-PPL processes from accessing or tampering with code and data in a PPL process via open process functions
|
No
|
No
|
| Platform lockdown |
Shielded Virtual Machines
|
Help protect a VM’s secrets and its data against malicious fabric admins or malware running on the host from both runtime and offline attacks
|
No
|
No
|
Revision History
- September 10, 2018: First publication
- January 15, 2019: Added non-boundaries for Windows Server Containers, Administrator to Kernel
- January 24, 2020: Added non-boundary for Hyper-V Administrators Group; updated Administrator to Kernel non-boundary
- May 14, 2021: Updated description of Windows Container security features