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:
    1. Does the vulnerability violate the goal or intent of a security boundary or a security feature?
    2. 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

Yes

Kernel boundary

 A non-administrative user mode process cannot access or tamper with kernel code and data. Administrator-to-kernel is not a security boundary. Yes

Yes

Process boundary

An unauthorized user mode process cannot access or tamper with the code and data of another process. Yes

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

Yes

User boundary

A user cannot access or tamper with the code and data of another user without being authorized. Yes

Yes

Session boundary

A user logon session cannot access or tamper with another user logon session without being authorized. Yes

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

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

Yes

Virtual Secure Mode boundary

Data and code within a VSM trustlet or enclave cannot be accessed or tampered with by code executing outside of the VSM trustlet or enclave. Yes

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

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

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

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

Yes

Identity and access control

Windows Hello / Biometrics An attacker cannot spoof, phish, or breach NGC (Next Generation Credential) to impersonate a user. Yes

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

Yes

Cryptography API: Next Generation (CNG)

Platform Cryptography Algorithms are implemented to specification (e.g. NIST) and do not leak sensitive data. Yes

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

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

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

User safety

 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

Yes

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

Yes

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

Yes

Exploit mitigations

Code Integrity Guard (CIG) A CIG-enabled process cannot directly load an improperly signed executable image (DLL) No

Yes

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

Yes

Exploit mitigations

SafeSEH/SEHOP The integrity of the exception handler chain cannot be subverted No

Yes

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

Yes

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