The Device Firmware Configuration Interface (DFCI) brings new levels of security and usability to PC configuration management. It is a new feature of UEFI that enables secure programmatic configuration of hardware settings that are typically configured within a BIOS menu by a human. High value configuration can be moved to UEFI BIOS where it is resilient against malware, rootkits, and non-persistent physical tampering. Whereas traditional UEFI security implementations required a physical touch, DFCI securely enables zero-touch remote configuration of these settings built uponMicrosoft Intune and authorized by Windows Autopilot. DFCI can provide additional assurance by configuring and locking hardware security features before launching the OS (e.g. disabling microphones or radios). Note that for management of servers in a datacenter, DFCI does not presume to be the solution. Redfish may be a more suitable solution for the datacenter.
Traditional UEFI management solutions were either not secure, allowing malware to control them, or not scalable, requiring a physical touch by IT or OEM for authentication. DFCI is zero touch, leveraging the existing Windows Autopilot device registration for DFCI authorization.
PC configuration is typically performed via Active Directory Group Policy, System Center Configuration Manager (SCCM), or Modern Device Management (MDM) such as Microsoft Intune. All of these solutions store their managed configuration in the OS disk partition. Unfortunately, this configuration can be bypassed by the PCs default ability to boot other operating system instances via external media (e.g. USB), network (e.g. PXE), & alternate disk partitions, or by simply re-installing the OS. Device Firmware Configuration Interface (DFCI) places high value configuration settings into PCs UEFI BIOS. UEFI DFCI storage is both visible to all OS instances, persistent, surviving OS reinstalls and disk reformats, and tamper-resistant, defending itself from malware and rootkits. UEFI executes before the OS and can disallow booting of specified devices, for example USB or network PXE. Further, DFCI can leverage hardware security to enforce some policies with higher assurance than typical OS configuration. For example, it could disable power to cameras or radios in a way that they could not be re-enabled by an OS, malware, or rootkit.
- Disabling cameras, microphones, and/or radios in manufacturing and other secure facilities
- Disabling boot to USB and network for single purpose and KIOSK devices
- Disabling local user access to all UEFI settings to maintain the out of box configuration
DFCI enablement is comprised of:
- UEFI BIOS implementation
- Windows Autopilot participation
If an OEM or its Partners already participate in the Windows Autopilot program, no additional Autopilot work is required, the only remaining work should be the UEFI BIOS implementation.
The pre-existing Windows Autopilot device registration workflows remain unchanged for DFCI, no additional work is required. It should be noted that Autopilot self-registrations are not trusted for the purpose of DFCI management (e.g. from Intune, Microsoft Store for Business, & Business 365).
DFCI enablement in UEFI BIOS requires implementation of DFCI interfaces and semantics, and inclusion of a public Microsoft certificate. There is precisely one (1) Microsoft zero-touch certificate that is shared by all DFCI-enabled systems to authenticate zero-touch provisioning requests. Thus there is no requirement to inject the certificate at manufacturing, it may simply be included in the UEFI BIOS image. The DFCI source code and public certificate are available on GitHub under a permissive open source license (SPDX-License-Identifier: BSD-2-Clause-Patent).
- https://github.com/microsoft/mu_feature_dfci/tree/main/DfciPkg
- https://github.com/microsoft/mu_feature_dfci/tree/main/ZeroTouchPkg
There is also an example UEFI BIOS menu that demonstrates how to integrate DFCI:
Some platforms may choose to implement less secure deployment methods for certain settings. DFCI allows a platform to supply either an allow list, or a disallow list, of a set of settings that may be deployed using unsigned packets. Unsigned settings may only be deployed when no DFCI Owner has been enrolled in the system unless that DFCI owner has specifically allowed certain settings to be set by unsigned packets. See the section on platform integRation for more information.
- Scenarios: Building the Microsoft Scenarios with DFCI
- Integration: Integrating DFCI code into your platforms
- Architecture: DFCI Code Internals
Copyright (C) Microsoft Corporation. All rights reserved. SPDX-License-Identifier: BSD-2-Clause-Patent