Microsoft UEFI CA Signing policy updates

This post describes UEFI Signing policy changes. These changes are important to help secure boot meet its security goals and also to maintain a reasonable turnaround time for signing UEFI submissions. This post also reiterates a few important parts of the existing UEFI signing policy licensing terms.

UEFI signing is a service provided by the Windows Dev Center hardware dashboard that lets you submit UEFI firmware binaries targeted to x86 or x64 computers for signing by Microsoft, so they can be more easily installed on computers running Windows that use secure boot and execute code signed with the UEFI CA.

While Microsoft reserves the right to sign or not sign submissions at its discretion, this list of requirements should be adhered to. Doing this will help you achieve faster turnaround times for getting your submission signed, and will also help avoid revocation. Microsoft might conduct follow-up reviews, including but not limited to questionnaires, package testing, and other security testing of these requirements before signing.

1. Starting March 15, 2014, UEFI submissions will require an EV certificate.

a. Starting March 15, 2014, SysDev will begin accepting EV certificates issued by either DigiCert or VeriSign for new submissions and renewals.

b. Existing submitters have until August 15, 2014, to move from existing non–EV code signing certificates to EV code signing certificates. This extension is provided to facilitate frictionless migration.

2. Only production quality code (for example, “release to manufacturing” code, rather than test or debug modules) that will be released to customers (no internal-only code or tools) are eligible for UEFI signing. For internal-use code, we suggest that you either turn off secure boot or add your own key to the SecureBoot database during development and testing.

3. Microsoft UEFI CA signs only those products which are for public availability and are needed for inter-operability across all UEFI Secureboot supported devices. If a product is specific to a particular OEM or Organization and is not available externally then we suggest you sign it with your private key and add the certificate to SecureBoot database.

4. 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. 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 won’t be signed.

5. If there’s a known malware vector related to code that uses certain techniques, that code won’t be signed and is subject to revocation. For example, the use of versions of GRUB that aren’t SecureBoot enlightened won’t be signed.

6. All code modules must be authenticated before execution. If this is not the case, submissions won’t be signed, and, if already signed, are subject to revocation.

a. If your submission loads a GRUB or other loaders, it must be SecureBoot enlightened.

For example, the latest GRUB 2 with SecureBoot patches.

b. Developers might assume that secure boot security requirements have been satisfied when their initial boot is complete. However, if a secure boot system permits launch of another operating system instance after execution of unauthenticated code, the security guarantee of secure boot is compromised. If this vulnerability is exploited, the submission might be revoked.

7. If your submission is a shim (handing off execution to another bootloader):

a. 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.

  • The private key must be protected with a hardware cryptography module. 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.

If embedded certificates are EV certificates, you meet all of the above requirements. We recommend that you use an EV certificate because this will speed up UEFI CA signing turnaround.

b. Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently.

c. 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.

d. Some shims are known to present weaknesses into the SecureBoot system. For a faster signing turnaround, we recommend that you use source code of 0.8 or higher from shim – GitHub branch.

8. You must test your product, following the Pre-Submission testing document (for UEFI Submissions), before submitting for signing.

9. If there are known security vulnerabilities in your submission code, the submission won’t be signed, even if your functionality doesn’t expose that code. For example, the latest known secure versions of OpenSSL are 0.9.8za and 1.0.1h, so if your submission contains earlier versions that contain known vulnerabilities, it won’t be signed.

10. Microsoft will not sign EFI submissions that use EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER. Instead, we recommend transitioning to EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER. This prevents unnecessary use of runtime EFI drivers.

11. Use of EBC code: Microsoft will not sign EFI submissions that are EBC-based submissions.

12. If your submission is a DISK encryption or a File/Volume based encryption, then you MUST make sure that you either don’t 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.

Comments (34)

  1. WM says:

    Where can this pre-submission testing document be found?

  2. Sathya says:

    Could we get more details on this like what are the tests and how they applicable to IHV provided boot services driver etc?. More like step be step version of what needs to be done prior to signing submission

  3. JJ Cox says:


    Please review the PreSubmission Testing webpage linked above and let us know if you have additional questions.

  4. Myria says:

    If Windows fails requirement 5b, will Microsoft revoke its signature?

  5. geofft says:

    How do vendors (and users) of third-party OSes distribute revocations like this morning's security advisory 2871690 to machines that don't have a Windows partition? Is there a feed of blacklists that we can put in our own security updates?

  6. ANTHONY M says:

    Gigabyte is changing my mobo BIOS OVER TO UEFI BIOS. I'll be honest here.  I have NOT a clue on how to do the change over yet. Is there anything that I need to do before I try this conversion?  If so, then please advise. Even better are there any areas in M Soft that can help me with this??



  7. Hi Anthony. Because your question isn’t directly about certification, we aren’t the best resource for you. I recommend that you contact your motherboard vendor. Hope this helps.

  8. JJ Cox says:

    Hi geofft,

    Yes, we are working on an alternative distribution channel for the revocation lists that is directly consumable by 3rd-parties without requiring a functioning Windows 8.x installation.  We'll post here when we have more information.

  9. Dee says:

    So is it still okay to boot unsigned linux kernel if the ExitBootServices is called or is the requirement that it *has* to be signed to boot if secureboot is enabled.  

  10. John Doe says:

    I wonder where to anti-monopoly regulators are looking. MS has gone as far as to policing what licenses we should use. What a blatant monopoly abuse.

  11. Dee says:

    What exactly is the point of requiring an EV certificate in the SHIM?  As long as shim is checking the code to be executed by checking it (using a certificate), that's all that is needed to ensure it's okay.   What additional would be needed if it was an EV type?  Because you can't provide the CA itself.

    6. If your submission is a shim (handing off execution to another bootloader):

       a. Certificates embedded in the shim must all be EV Certificates, and the Organization attribute in all these embedded certificates must be same as the Organization attribute in the EV Certificate on file for the SysDev account.

  12. Ed says:

    The UEFI sign-up process points new registrants at

    > VeriSign Code-Signing Certificates for Microsoft Authenticode  ($99 USD)


    Is there a new process to obtain an EV certificate to sign up, or does one need both the certificate mentioned above and an EV certificate?

  13. Dee says:

    Still questioning the EV requirement within the shim (6a) – the more I think about, the less sense it makes.  If we put our own private strong certificate built using openssl (we know who we are) within the SHIM to verify all our loading of binaries, that is just as strong as using an EV certificate.  There is no advantage to having to use an EV certificate within the shim to verify our binaries.  Now for submitting to MS, an EV certificate is fine.  Once signed, that shim can't be altered with another certificate (only our private certificate can be in there or it would have never been loaded by the UEFI secure boot code).

  14. Hi Dee,

    (about loading unsigned kernel)

    As mentioned in 5.b above, it is strongly recommended to load only signed kernel modules to avoid security vulnerabilities which may result in possible future revocation (if and when exploits are found compromising SecureBoot). This latest article in ITWire(…/63120-microsoft-changes-policy-on-third-party-signing-of-efi-code) might help with deeper understanding of the security need of this, and the adoption of these practices by other operating system vendors, such as Fedora.

    (about EV in SHIMs)

    The rationale for requiring EV inside SHIM is to get a better guarantee of key management and trustworthiness. Signing SHIM is equivalent to cross signing a CA to trust other non-UEFI CA signed modules.  Hence the higher security bar for SHIM. We, of course, appreciate this feedback and we will continue discussing with various partners on the impact this change may have on their build infrastructure.

  15. Hi Ed,

    The Developer Portal is working towards supporting EV certificates from both DigiCert and VeriSign, and we will bring this capability online soon. In the interim, if you are planning to sign up and submit, you can continue to use VeriSign’s Non-EV Code Signing certificate as stated in the sign up workflow, though we would recommend you use VeriSign’s EV certificate to be forward compatible with future requirements (See answer to Dee’s question on EV certificates). If you use a VeriSign’s EV certificate then you don’t need VeriSign’s $99 certificate for sign up.  

  16. Dee says:

    Thanks CT – on the EV in SHIM; We currently provide our own (public) certificate inside shim which was generated via openssl (along of course with the private key).  We sign our binaries (from what shim loads all the way to the kernel/main binary) with the private key (which we keep protected).   In that case EV certificates don't mean anything, we are 100% sure of who we are and since we will be signing shim (which has our private embedded certificate) with our verisign EV certificate matching the one in sysdev, you're sure that the signed shim we provide is from us and the certificate within it is also under our trust.  If someone modified our shim, secure boot wouldn't load it.  or am I missing something?

  17. Sathya says:

    Is the developer portal is updated with option to buy EV certificate, if not can we use our old NonEV- verisign certificate until we can buy the EV certificate?.  Also whether the old signcode tools will work fine with EV certificate?

  18. Ed says:

    Thanks CT for the update.  You described the situation we're in now: we don't currently have any certificate, but plan to submit a shim loader for signing in the near future.

  19. Hi Ed,

    You will require a EV, follow this link to further help you step by step in achieving this:…/br230795.aspx

  20. geofft says:

    Hi certification folks, I'm curious if there's an update on how OSVs can distribute MS revocations (and request to get our own hashes revoked, if the need arises). We do have Windows 8 machines in our build infrastructure, so we can script something to run on a Windows 8 box to pull down revocations if that's the best answer for now.

  21. Hi geofft,, we are working on making signed revocation list available to OSVs (and all others), we should have an update on this soon (in couple of weeks). For now, please do go ahead pull down revocations from a Win8 box. And to your comment on support for custom hashes revocation, we wont be supporting providing a custom revocation list but if you find any of your components (or any other malicious EFI modules) to be security compromised and to be revoked then please do report through steps posted here…/ff852094.aspx or email to

  22. Tom S says:

    Item 5 in this FAQ disagrees with Item 3.

    Item 5: "For example, (use) the latest GRUB 2 with SecureBoot patches."

    Item 3: "For example, GRUB 2 is licensed under GPLv3 and won’t be signed."

    Suggest picking a different example than GRUB 2 for Item 5 if it is prohibited… though I question if that is pursuant to regulator approval for Windows 8. There was no "GPLv3 exemption" in the secure boot proposal submitted to regulators that I can find.

  23. Hi Tom, GRUB 2 itself wont be signed, but SHIMs which are designed to further load boot loaders like GRUB are signed. #5 calls out that though your submission (like SHIM) can load a boot loaders like GRUB 2, only if those boot loaders honor secureboot requirements (authentication of all the code that is loaded and executed subsequently)

  24. Tom S says:

    Thanks for clarifying – so long as Microsoft permits signing a SHIM that they know will bootstrap GRUB 2, no objections here.

  25. sergei_d says:


    Could you please clarify if it is possible to use a EV code signing certificate with Organization other than the company name set up inside a SysDev profile (e.g. issued in customer's name) for UEFI shim submissions?

  26. Suhas manangi says:

    sergei_d, can you please write an email to and we can discuss this and understand what you are trying to accomplish and what is accepted.

    Thank you


  27. sergei_d says:

    Hi Suhas,

    Thanks for your response. I will contact you at the above mentioned e-mail shortly.

  28. RichardH says:

    Hi certification team,

    if using EV certificate inside SHIM the GRUB signature is bound to the validation of the EV certificate. So do we have to reissue new SHIM versions for any certificate prolongation or is there any kind of timestamping allowed?

    Thank you


  29. JonasG says:

    Hi certification team!

    We are currently signing all our UEFI binaries using the SysDev portal but are now considering to move to a Shim-based loader and use our EV certificate to sign the UEFI binaries ourselves to shorten the turnaround time for our releases.

    Do you have any more detailed requirements regarding 7b?

    "Submitter must design and implement a strong revocation mechanism for everything the shim loads, directly and subsequently."



  30. VINICIO SANTOS says:


  31. Michael says:


    is there any possibility to view the exact signing policy (not only updates, the whole legal doc) *before* obtaining the EV certificate (the website suggests that you see the legal document once you signed up a company on the dashboard)? Also, is it possible for an individual or a group of individuals ("hobbyists") to sign up for getting loaders signed if they are no company (if we manage to get an EV certificate, that is)?

    Last but not least, what are the exact requirements for loaders that require human interaction before loading anything unsigned (like shim MokManager or Linux Foundations Preloader)? Is a two-key combination (like pressing Left key to switch No to Yes, and Return to confirm) enough, or do we need multiple keys (I'd like to avoid letters or function keys as they depend on keyboard layout and function keys are often hard to type on notebooks).

    Reason why I'm asking is that currently the situation for hobbyists who want to bundle system diagnostics software (*not* a Linux kernel) that can boot from UEFI Secure Boot means that they either use MJG shim or the preloader – requiring 10+ keystrokes on every boot to whitelist the executable, which becomes permanently stored (unless manually removed) for subsequent boots, thus making the system potentially more insecure (if anyone ever booted an UEFI shell that way, UEFI shell is whitelisted and could used by anybody else without confirmation?). Having a simple shim loader that requires human interaction before every boot would be our preferred solution.