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.

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.

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

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

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.

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.