We talk a lot about protecting endpoints: restricting what users can and can’t do, deploying Windows ATP, mandating compliance – but what about the hardware itself? Sure, BitLocker can help protect against a utilman exploit but what prevents the OS being wiped away? You might have a shared device that you don’t want modified or need to restrict the use of the cameras.
Previewed at Ignite 2019, Microsoft anticipate a go-live date for DFCI of quarter one, 2021. If that sounds alien to you, Device Firmware Configuration Interface (DFCI) is the ability for Windows to pass management commands from Intune through to the UEFI framework – essentially leveraging cloud based management for BIOS settings.
Historically, the solution to protect the BIOS of an endpoint was via a password or to use an OEM specific solution, whether that be Microsoft’s Surface Enterprise Management Mode (SEMM), or something else. There are two big downsides to these; ease of management and cost. Local passwords are a ‘cost free’ solution but require intensive hands on time to manage and maintain, SEMM using System Centre Configuration Manager has its own costs and is rarely seen in the SMB portfolio in any case. DFCI is showing promise in providing a low cost and simple to manage solution.
At present, only the latest portfolio of Surface devices: the Surface Laptop 3, Surface Pro 7, as well as the Surface Pro X are supported. Microsoft are making their work on DFCI open source by way of Project Mu. I haven’t been able to track down any official announcements from the big three vendors: HP, Dell, and Lenovo. According to a post on the HP Developer Forums, however, HP may be considering their options.
I believe the plan is to support modern management natively. However whether that will be DFCI or something else is behind the scenes, and currently undefined.txvalp
Additionally, Microsoft have stated that DFCI relies on interfaces within the BIOS image, not the physical hardware. I can see the potential to then bring DFCI support to existing hardware through a simple BIOS update – a big bonus for organisations that have recently onboarded new hardware.
With the current preview build available now through Intune, three requirements must be met:
- Devices must include the DFCI feature within the BIOS, currently limited to a handful of Surface products
- Devices must be managed by Intune
- Devices must be registered with AutoPilot by an OEM or Cloud Solution Provider.
Microsoft have confirmed that devices enrolled into AutoPilot via importing a CSV file will not work, stating that self-registrations are not trusted.
By design, DFCI management requires external attestation of the device’s commercial acquisition through an OEM or a Microsoft CSP partner registration to Windows Autopilot.DFCI Management – Microsoft Docs
Unfortunately for clients who have used direct enrollment with Intune, DFCI will be a missed opportunity.
Let’s use it
Like most features within Intune, it’s a matter of creating a Configuration Profile and applying it to a scope. Interestingly, I don’t get the option to disable CPU & IO virtualization at the moment, and the Not Configured option could result in the setting being left enabled for users. According to the Surface configuration documents, Disabled should be available as an option.
Lastly, remember your target group should be an AzureAD Group containing the devices, not the users themselves.
Once the policy is deployed to a device, a reboot may be forced. This is potentially an issue for devices that are already in production, however not a major problem if it’s a part of the initial setup process.
If you’re needing to offboard a device, remember to retire/wipe the device then delete the listing within Intune. Finally you’ll need to boot into the UEFI menu and update the configuration via a network request.