Two named vulnerabilities — YellowKey and Bitskrieg — show that BitLocker without a startup PIN can be bypassed. The permanent fix is in the June 2026 Patch Tuesday. But patching alone is not enough: organisations that keep using TPM-only remain structurally exposed. How do the attacks work, how do you configure TPM+PIN via Intune, and what should you do this week?
In the first half of June 2026, two vulnerabilities dominated security discussions: YellowKey and Bitskrieg. Both target BitLocker, the disk encryption active on virtually every business Windows laptop. What they share: they affect devices running BitLocker on the most common setting — TPM-only, without a startup PIN. The definitive fix shipped on 9 June 2026 as part of Patch Tuesday, but patching alone does not fully address the underlying architectural weakness.
YellowKey (officially CVE-2026-45585) was disclosed in early May 2026 by a Dutch security researcher, complete with a proof-of-concept on GitHub. Microsoft could not deliver a full patch immediately and published interim mitigation guidance. Bitskrieg (CVE-2026-50507) followed the same trajectory: a separate exploit path in the same component, also fixed in the June update. IT teams that understand both CVEs and adjust their Intune policy are structurally better protected than those who only apply the patch.
YellowKey abuses the Windows Recovery Environment, the recovery mode available by default on Windows 11 (24H2, 25H2, and 26H1) and Windows Server 2025. An attacker with physical access — a stolen or unattended laptop — boots the device into WinRE. There, the attacker places specially prepared files on a USB drive or the device's EFI partition. By exploiting a vulnerability in how WinRE processes the BootExecute registry value, the attacker activates a command prompt with access to the BitLocker-protected volume.
The reason this works on TPM-only devices: with TPM-only BitLocker, the TPM chip releases the encryption key automatically at every boot without any user action. WinRE inherits that trust from the main environment when the recovery image has not been properly sealed. YellowKey exploits precisely that gap. On devices using TPM+PIN, the attack does not work: the PIN instructs the TPM to release the key only after the user provides confirmation, even inside WinRE.
The CVSS score is 6.8 — not the highest tier, because physical access is required. But with stolen laptops being a common business incident, that threshold is lower than it seems. The combination of a public proof-of-concept and a six-week period without a definitive patch generated significant discussion in the security community.
Bitskrieg (CVE-2026-50507) operates via a fundamentally different mechanism. It exploits a race condition in the logic BitLocker uses to reseal itself after a cumulative Windows update is installed. During the installation window, the volume master key is temporarily present in plaintext in system memory before the TPM reseals the key.
An attacker with local administrator rights can read the key from a hibernation file or a crash dump during that short window. Bitskrieg requires a higher entry bar than YellowKey — local admin rights are needed — but it becomes far more dangerous in scenarios where an attacker already has an initial foothold. Combined with phishing or a compromised admin account, Bitskrieg forms a realistic escalation chain.
TPM-only is the default or recommended setting in most Intune configuration profiles. The motivation is understandable: users do not need to enter a PIN at every boot, which reduces friction and limits helpdesk calls. But both vulnerabilities reveal a fundamental limitation: with TPM-only, the chip releases the key automatically whenever the system is in the correct state, even without any user confirmation.
That is precisely the attack angle of YellowKey and Bitskrieg: they create or exploit a situation the TPM recognises as the correct state. TPM+PIN adds a human in the loop. Without the correct PIN, the TPM will not release the key — not in WinRE, not during an update cycle, not via a crash dump. The PIN is the additional lock that neutralises software exploits in the pre-boot environment.
The definitive security updates for YellowKey and Bitskrieg shipped on 9 June 2026 as part of the regular monthly update. Devices that have received this update are protected against the known exploit paths. Check in your Intune dashboard via Reports > Windows updates whether all devices have processed the June update. Devices that are behind deserve priority; look for patterns in older hardware models or non-automatically updated feature branches.
One caveat: the patch closes the specific vulnerabilities but does not resolve the architectural weakness of TPM-only. A future vulnerability in WinRE or BitLocker's reseal logic could again be exploited via TPM-only devices. The lessons of YellowKey and Bitskrieg are structural: TPM+PIN is the defence-in-depth that prevents future variants.
Adjusting the BitLocker startup policy in Intune is done through Endpoint Security or a Settings Catalog profile. Navigate to Endpoint Security > Disk encryption and open the existing BitLocker profile, or create a new Windows profile via Devices > Configuration profiles > Settings Catalog.
The relevant setting is called 'Require additional authentication at startup.' Set this to Enabled. Then set 'Configure TPM startup PIN' to 'Require startup PIN with TPM.' Save the profile and assign it to the target group.
Four considerations for the rollout. First, users of already-encrypted devices must set a PIN once. Communicate this in advance and point them to the Company Portal or send an email instruction. The PIN prompt appears at the next restart. Second, the minimum PIN length is six characters and the maximum is twenty. Advise users not to equate their PIN with their Windows password. Third, ensure all BitLocker recovery keys are stored in Entra ID. If a user forgets their PIN, the IT team retrieves the recovery key from the Entra portal. Fourth, create an Intune compliance policy that checks for BitLocker encryption with recovery key backup in Entra — devices without a registered key are then flagged as non-compliant.
Four actions for the coming working days. First, verify that the June 2026 updates have been applied to all Windows devices. Use the update reporting in Intune or the Defender portal to identify devices that are behind. Second, review your current BitLocker policy. Is 'Require additional authentication at startup' set to Not Configured or TPM-only? If so, adjustment is needed. Third, plan a staged rollout of TPM+PIN. Start with a pilot group of five to ten devices, evaluate the user experience and recovery key storage, then scale up. Fourth, ensure recovery keys are synchronised to Entra ID for all encrypted devices in your fleet. A quick win is running an Intune query for devices without a registered key.
YellowKey and Bitskrieg underline that disk encryption is not a static security control. Policy requires periodic review as the threat landscape and Windows architecture evolve. Want help reviewing your BitLocker policy in Intune, rolling out TPM+PIN, or validating your recovery key storage in Entra? Contact Zarioh for a no-obligation conversation.
