Forum Discussion

StuartK73's avatar
StuartK73
Steel Contributor
May 18, 2026

YellowKey BitLocker Exploit

Hi All

I hope you are well.

Anyway, the YellowKey BitLocker Exploit has came to my attention.

We already have automatic  / silent BitLocker encryption enabled.

So, is there anything we should be doing (preferably via Intune) to mitigate this new exploit?

 

SK

14 Replies

  • Hi StuartK73​ ,

    From what I understand, Microsoft’s script is intended to apply the current mitigation for the YellowKey / CVE-2026-45585 issue, so yes, I would deploy that first rather than immediately moving everyone to TPM+PIN.

    For Intune, I would personally use a remediation approach if possible:

    • Detection script: check whether the mitigation is already applied
    • Remediation script: apply Microsoft’s mitigation when missing
    • Start with a small pilot group
    • Then expand in rings

    I would not disable WinRE permanently unless Microsoft specifically recommends it for your scenario. I would also not rush into TPM+PIN for every user unless your risk profile requires it, because that can create a lot of operational impact.

    So my approach would be:

    Apply Microsoft’s mitigation script via Intune, validate on pilot devices, monitor BitLocker/WinRE behavior, and keep TPM+PIN for higher-risk devices or users where physical access risk is a bigger concern.

    • StuartK73's avatar
      StuartK73
      Steel Contributor

      Hi Buddy

      Many thanks for your very informative reply.

      Can you elaborate on:

      • Detection script: check whether the mitigation is already applied
      • Remediation script: apply Microsoft’s mitigation when missing

      As I can only see the X 1 MS script and I'm not sure how to detect and remediate scripts from that.

      Info appreciated.

       

      Stuart

  • peptixcalc's avatar
    peptixcalc
    Copper Contributor

    I think the biggest problem right now is that many organizations rely heavily on TPM-only BitLocker deployments because they are easy to scale with Intune and Entra ID, but YellowKey seems to expose the weakness of relying only on transparent unlock mechanisms when physical access is possible.

    From what I understand so far, Microsoft’s mitigation script mainly reduces the current attack surface, but it does not completely replace stronger protections like TPM+PIN. For high risk environments, adding pre-boot authentication still seems like the safest long term approach, even if deployment across existing fleets is painful.

    Disabling WinRE temporarily also makes sense as an emergency mitigation until Microsoft provides a cleaner permanent fix. I also agree with others here that USB restrictions and BIOS passwords alone are not enough on many modern devices.

    For Intune environments, a remediation script checking WinRE status and mitigation compliance sounds like the most scalable approach right now. Surprised Microsoft did not publish an official Intune remediation package already.

    I was actually reading through a few security and infrastructure discussions while testing monitoring setups on one of my own utility projects recently:
    https://peptixcalc.com/

    Curious to see whether Microsoft eventually pushes an automatic mitigation through Defender or BitLocker policy updates.

  • StuartK73's avatar
    StuartK73
    Steel Contributor

    Hi All

    I see MS have updated the post and provided a script.

    Could someone please clarify the following:

     

    • Does running the script mitigate / fix the vulnerability?
    • Do we still need to set BitLocker PIN's?
    • Do we still need to set BIOS's PIN's?
    • Do we still need to disable WinRE?
    • What are the settings for deploying this script via PowerShell via Intune?
    • Does anyone know how to compile an Intune remed script?

    Info appreciated

     

    Stuart

    • StuartK73's avatar
      StuartK73
      Steel Contributor

      Thanks buddy, although I'm not sure what MS are asking us to do here on Entra ID joined / Intune enrolled devices that are in numerous offices throughout the country, as these do look like per device commands to me and we don't really want BitLocker PINs. Am I missing something?

       

      SK

      • RyanSteele-CoV's avatar
        RyanSteele-CoV
        Steel Contributor

        Good question. In theory, it ought to be possible to create a PowerShell Remediation script that checks whether the mitigation has been applied and runs the commands to apply it if needed. Why didn't Microsoft provide one?

        Edit: The article was updated on May 21 to include a PowerShell remediation script.

  • Klaas123's avatar
    Klaas123
    Copper Contributor

    Yes, I would also like to see a proper response from Microsoft. (has been 7 days since release now...)

    We are moving toward deploying TPM+PIN, but rolling this out across an existing fleet is quite troublesome and will take a significant amount of time.

    That said, the creator of the exploit has mentioned that they have a PoC capable of bypassing TPM+PIN as well (unreleased).

    As an immediate mitigation, we have deployed a remediation script to disable WinRE, until Microsoft has a fix.

    USB boot restrictions, BIOS passwords etc..., are  relatively easy to bypass on most hardware...

  • Radzik_PL's avatar
    Radzik_PL
    Brass Contributor

    I’ve been wondering about this too — looks quite serious.

    From what I see, YellowKey abuses WinRE + FsTx to get a shell with the BitLocker volume already unlocked, no password or recovery key needed. So in practice, with physical access, default BitLocker setups can be bypassed.

    For now, likely worth tightening things around

    •  pre-boot auth (TPM+PIN),
    • USB boot restrictions,
    • physical access controls.

    Curious how Microsoft will address this.

  • lee42's avatar
    lee42
    Copper Contributor

    The silence from Microsoft on this issue is deafening!

    You should be looking at requiring a startup PIN. Intune will allow you to set the PIN as a requirement, but I don't believe that will apply except to net new volumes, existing volumes will need to be updated by the user - which makes sense, they need to know the PIN.