[UPDATED]: Microsoft UEFI Signing Requirements

UEFI signing is a service provided by the Windows Hardware Dev Center dashboard by which developers submit UEFI firmware binaries for signing so they can be installed on secure boot enabled systems intended to support 3rd party EFI applications and option ROMs .  

While Microsoft reserves the right to sign or not sign submissions at its discretion, you should adhere to these requirements. These requirements are to ensure the security promise of secure boot, and to help expedite the turnaround of signing submissions. They apply to all third-party submissions requesting signing with the Microsoft Corporation UEFI CA 2011 or the new 2023 CAs (Microsoft Corporation UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023). They build upon the baseline requirements of the Windows Hardware Dev Center (HDC) and introduce additional criteria specific to UEFI Secure Boot. 

Microsoft may conduct follow-up reviews, including but not limited to questionnaires, package testing, and other security testing of these requirements before signing. The following list contains the latest requirements for the UEFI signing process: 

1. Only production quality code (for example, “release to manufacturing” code, rather than test or debug modules) that will be released to customers are eligible for UEFI signing. Internal-only code and tools are not eligible. For internal-use code, you should add your own key to the Secure Boot database UEFI variable or turn off Secure Boot during development and testing.  UEFI shell will not be signed and must not be included in production firmware.
   
2. Microsoft UEFI CA and Option ROM CA sign only those products that are for public availability and are needed for inter-operability across all UEFI Secure Boot supported devices. If a product is specific to a particular OEM or organization and is not available externally, you should sign it with your private key and add the certificate to the Secure Boot database. 
   
   
3. Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. The code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and will not be signed. 
   
   
4. If the code being submitted can be leveraged by malware, that code will not be signed and is subject to revocation. For example, older versions of shim that do not support SBAT revocations (i.e. versions 15.2 and backwards).
   
   
5. If there are known security vulnerabilities in your submission code, the submission will not be signed and is subject to revocation, even if your functionality doesn’t expose that code. For example, if your submission contains earlier/deprecated versions of a crypto module (e.g., OpenSSL 1.0) that contains known vulnerabilities, the submission will not be signed. 
   
   
6. Before submitting for signing, you must test your product following the Pre-Submission testing document (for UEFI Submissions). 
   
   
7. EFI submissions must use one of the two supported sub systems type: 
   • EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER (Option ROMs) and 
   • EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION_DRIVER (Applications).  
     
     
8. All EFI submissions must be packaged separately based on subsystem type to ensure proper signing certificate alignment. Submissions identified as containing subsystem EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER are considered Option ROMs and will be signed with the Microsoft Option ROM UEFI CA, while submissions identified as containing subsystem EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION_DRIVER are considered EFI Applications and will be signed with the Microsoft UEFI CA. Mixed packaging of Option ROMs and EFI Applications will result in rejection. 
   
   
9. Use of EFI Byte Code (EBC): Microsoft will not sign EFI submissions that are EBC-based submissions. 
   
   
10. If your submission is a disk encryption or a File/Volume based encryption, then you MUST either: 
    • Not encrypt the EFI system partition OR,  
    • If you do encrypt, be sure to decrypt it and make it available by the time Windows is ready to boot.  
      
      
11. If your submission is comprised of many different EFI modules, multiple DXE drivers, and multiple boot applications, Microsoft may request that you consolidate your EFI files into a minimal format. An example may be a single boot application per architecture, and a consolidation of DXE drivers into one binary.  
    
    
12. All Submitters must obtain an independent security audit of their UEFI submission at least once every 12 months with the exception of SHIM submissions undergoing the shim review board process (the shim review board process already includes a security review). 
    • The audit must be conducted by a qualified third-party security firm. We require submitters utilize the OCP SAFE Program. The security audit must contain at minimum a Scope 1 Code and Architecture Assessment audit.  
    • In the case where a known vulnerability has been identified in the submission, a new audit must be conducted immediately to confirm that the vulnerability has been addressed regardless of the annual cycle.  
    • If the submission has undergone a substantial code change, a new audit must be conducted regardless of the annual cycle prior to signing. A substantial code change can be defined as any modification that: 
      1. Alters core functionality or execution flow of the UEFI binary.
      2. Introduces new modules, drivers, or dependencies.
      3. Changes cryptographic operations, boot logic, or firmware interaction patterns.
      4. Impacts the security posture or trust boundary of the submission.
         
         

13. SHIM submissions are exempt from obtaining an independent security audit only if your SHIM is handing off execution to an open source bootloader. In this case you must first submit to the SHIM review board and be approved before submitting to Microsoft for signing. This review board will check to ensure the following: 

    • Code signing keys must be backed up, stored, and recovered only by personnel in trusted roles, using at least dual-factor authorization in a physically secured environment. Additionally, keys must either be retained at the same level of security or be destroyed and rendered unrecoverable, including after expiration of the certificates.  
    • The private key must be protected with a hardware cryptography module which must have a security level at least equal to FIPS 140-2 Level 2. This includes but is not limited to: HSMs, smart cards, smart card–like USB tokens, and TPMs. 
    • The operating environment must achieve a level of security at least equal to FIPS 140-2 Level 2. 
    • We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround.  
    • Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently. 
    • If you lose keys or abuse the use of a key, or if a key is leaked, any submission relying on that key will be revoked. Discovery of loss, abuse or leakage must be reported here: MSRC Researcher Portal  
    • For this, we require that you use source code of 15.8 or higher from shim - GitHub branch for this SHIM. 
    • For iPXE SHIM, we recommend that you use source code from this iPXE shim 
      
      
14. For other usages of SHIM that do not meet the open source/public SHIM criteria, your submission must:  
    • Package all code that executes before ExitBootServices within a single bootloader. 
    • Obtain an independent external security audit from the OCP SAFE Program before being submitted for review and signing to Microsoft. 
      
      
15. If your submission contains iPXE functionality, then additional security steps are required. Previously, Microsoft has completed an in-depth security review of 2Pint’s iPXE branch. For new submissions with iPXE to be signed, they must complete the following steps: 
    1. Pull and merge from 2Pint's commit: iPXE - GitHub branch
    2. Get a security review from a verified vendor on the OCP SAFE Program. Refer vendor to the iPXE Security Assurance Review . Emphasis of the review should be on: 
       • NFS functionality is not included.
       • Non-UEFI loaders are not included 
       •  Ensuring all known reported security problems are fixed (identified in the iPXE Security Assurance Review.   
    3. Share the specific commits that are made to the project, allowing Microsoft to ensure the expected changes are made
       
       
16. All developers should build full support for NX firmware. Since these app characteristics cannot be detected statically, setting IMAGE_DLLCHARACTERISTICS_NX_COMPAT attests that the submitted application has been successfully implemented and tested.
    
    
17. Memory requirements:
    • • Submissions must not assume all memory ranges are valid; specifically, the first page of memory i.e., page 0 (PA 0 – 4kb). That allows null pointer detection to be turned on in firmware.  
      • PE-COFF metadata  
        • Section Alignment of the submitted PE file must be aligned with page size.  This must be 4kb, or a larger power of 2 (ex 64kb) 
        • Section Flags must not combine IMAGE_SCN_MEM_WRITE and IMAGE_SCN_MEM_EXECUTE for any given section.If Implemented: PE-COFF Attestation
        • DLL Characteristics must include IMAGE_DLLCHARACTERISTICS_NX_COMPAT   
      • The application must not run self-modifying code; meaning that the code sections of the application may not have the write attribute.  
      • If the application attempts to load any internal code into memory for execution, or if it provides support for an external loader, then it must use the EFI_MEMORY_ATTRIBUTE_PROTOCOL appropriately.  This optional protocol allows the caller to get, set, and clear the read, write, and execute attributes of a well-defined memory range
        • Loading internal code into memory must maintain WRITE and EXECUTE exclusivity. It must also change the attributes after loading the code to allow execution.  
        • External loaders must support the protocol if available on the system. The loader must not assume newly allocated memory allows code execution (even of code types).  
        • Stack space cannot be used for code execution.   
          
          
18. All submissions must contain a valid signed SPDX SBOM in a custom “.sbom” PE section. The following are mandatory fields that must be included in the sbom section following the established guidance for sbom field generation. Here’s the Microsoft SBOM tool to aid SBOM generation. 

• • • Vendor package name
    • File name/ software 
    • Software version/ component generation (shim)
    • Product-name
    • Vendor/Company name (this must exactly match the verified company name in the submitter’s EV certificate on the Microsoft HDC partner center account)
    • OEM Name
    • OEM ID 

For questions about the UEFI Signing process, contact uefisign@microsoft.com