Windows 10 S security features and requirements for OEMs

Windows 10 S is a specific configuration of Windows 10 Pro that offers a familiar Windows experience that’s streamlined for security and performance. Windows 10 S provides the best of the cloud and full featured apps, and is designed for modern devices. Microsoft Defender is always on and always up-to-date.

Windows 10 S will only run verified apps from the Store and verified drivers from Windows Update. Windows 10 S provides supports Azure Active Directory, and when paired with MSA or Intune for Education, Windows 10 S defaults to storing files to OneDrive.

Features enabled for Windows 10 S

Windows 10 S Mode protects customers by using a combination of code integrity policies, hardware, and certification for apps. Windows 10 S will only run executable code that is signed with a Windows, WHQL, ELAM, or Store certificate from the Windows Hardware Developer Center Dashboard. This includes companion apps for drivers.

Features Windows 10 S Windows 10 Home Windows 10 Pro
Non-store apps Yes Yes
Domain join on premise Yes
Azure AD domain join Yes Yes
Windows Store apps (including Win32 centennial apps) Yes Yes Yes
OneDrive automatic setup and sync; Requires MSA Yes Configurable Configurable
Microsoft default apps set Yes Configurable Configurable
Windows update for business Yes Yes
Windows Store for business Yes Yes
Mobile Device Management (MDM) Yes limited Yes
BitLocker Yes Yes
Enterprise state roaming with Azure AD Yes Yes
Shared PC configuration Yes Yes

Windows 10 S default modern app configuration

  • Email: Mail
  • Maps : Maps
  • Photo viewer : Photos
  • Search : Bing
  • Video player: Movies & TV
  • Web browser: Edge
  • OneDrive automatically configured for MSA accounts so that documents, Photos, and Desktop are automatically synced and the user has 5GB of standard storage.

Memory integrity protection

Memory integrity is a virtualization-based security (VBS) feature available in Windows 10, Windows 11, and Windows Server 2016 or higher. Memory integrity and VBS improve the threat model of Windows and provide stronger protections against malware trying to exploit the Windows kernel. VBS uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised. Memory integrity is a critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS. Memory integrity also restricts kernel memory allocations that could be used to compromise the system, ensuring that kernel memory pages are only made executable after passing code integrity checks inside the secure runtime environment, and executable pages themselves are never writable.

Note

Memory integrity is sometimes referred to as hypervisor-protected code integrity (HVCI) or hypervisor enforced code integrity, and was originally released as part of Device Guard. Device Guard is no longer used except to locate memory integrity and VBS settings in Group Policy or the Windows registry.

Memory integrity is turned on by default on clean installs of Windows 10 in S mode and Windows 11 on compatible hardware as described in memory integrity enablement. On other systems that don't meet the memory integrity auto-enablement requirements, customers can opt in using any of the methods described in how to enable memory integrity.

Kernel mode code integrity, protected by memory integrity, prevents the execution of unsigned or improperly signed binaries in the kernel. Using unsupported binaries should only be done during lab or factory image customization, or during deployment where the execution environment is either WinPE or Audit Mode.

For more information, see Memory integrity and virtualization-based security

User mode code integrity policy

Windows 10 in S mode is implemented using a policy that enforces user mode code integrity (CI). Once the CI policy is enabled on a system, it is enabled in two places:

  • Windows 10 S, enforced at boot
  • UEFI firmware policy, enforced during firmware load and OS boot

Signed drivers and Windows 10 S

Driver signing is different for Windows 10 S. To install on Windows 10 S, driver packages must meet the following requirements:

  • Driver packages must be digitally signed with a Windows, WHQL, ELAM, or Store certificate from the Windows Hardware Developer Center Dashboard.
  • Companion software must be signed with a Microsoft Store Certificate.
  • Does not include an *.exe, *.zip, *.msi or *.cab in the driver package that extracts unsigned binaries.
  • Driver installs using only INF directives.
  • Driver does not call blocked inbox components.
  • Drivers does not include any user interface components, apps, or settings. Instead, use Universal applications from the Microsoft Store, for example:
    • Hardware Support Apps
    • UWP device apps
    • Centennial Apps
    • Driver and firmware servicing uses Windows Update and not an updater app.

For more information, see Windows 10 S Driver Requirements and Publish a driver to Windows Update.

What's not supported

Windows 10 S does not allow any apps that aren't in the Store. A second limitation is that Windows 10 S does not allow on-premise domain joins. Additionally, some Windows customizations and some apps are not supported. For more information, see Planning a Windows 10 S deployment

The following components are blocked from running in Windows 10 S. Any script or application that calls one of these blocked components will be blocked. If your manufacturing process uses scripts or applications that rely on blocked components, you can temporarily enable manufacturing mode for configuring and testing, but you can't ship a PC with manufacturing mode enabled.

  • bash.exe
  • cdb.exe
  • cmd.exe
  • cscript.exe
  • csi.exe
  • dnx.exe
  • kd.exe
  • lxsmanager.dll
  • msbuild.exe
  • ntsd.exe
  • powershell.exe
  • powershell_ise.exe
  • rcsi.exe
  • reg.exe
  • regedt32.exe
  • windgb.exe
  • wmic.exe
  • wscript.exe