Microsoft’s April 2026 Windows servicing cycle has run into one of the most disruptive failure modes in enterprise IT: unexpected BitLocker recovery prompts after reboot. The issue affects a narrow but highly sensitive set of Windows 11, Windows 10, and Windows Server 2025 systems, with Microsoft confirming that KB5082063, KB5083769, and related updates can push some devices into recovery on the first restart. For managed fleets, that is more than a nuisance; it is a boot-time lockout that can strand devices until the correct recovery key is available. Microsoft has already published mitigation guidance, but the broader lesson is harder to ignore: secure boot transitions, TPM policy settings, and encryption baselines are now tightly coupled, and monthly updates can expose weaknesses in that chain.
This episode is best understood as part of a larger Windows servicing story rather than as an isolated Patch Tuesday annoyance. Microsoft has spent much of 2026 modernizing the boot trust chain, rolling out Secure Boot-related changes while also trying to keep systems protected against serious vulnerabilities. That means the company is doing two things at once: hardening the platform and moving the installed base toward new trust anchors. When those changes intersect with BitLocker policy, even a small mismatch can surface as a recovery prompt instead of a normal boot.
The practical reason this matters is that BitLocker recovery is not a normal error state. It is a deliberate security boundary, and it appears before Windows fully loads, which makes remote remediation far harder. If a workstation is locked in an office, help desk staff may eventually sort it out. If a remote device is sitting at the recovery screen with no one nearby who has the 48-digit key, the machine becomes a support incident, a security concern, and a productivity loss all at once. That is why this class of bug causes disproportionate concern in enterprise environments.
Microsoft’s documentation indicates that the issue is not random and not universal. It requires a very specific combination of BitLocker, TPM validation policy, Secure Boot state, boot manager versioning, and certificate presence. That narrow trigger profile is good news in one sense, because most consumer PCs are unlikely to meet it. But it is also bad news in another, because the affected systems are often the most tightly managed and security-conscious ones in the enterprise, exactly the devices organizations care most about.
Another reason the episode is getting attention is that it arrives alongside other April 2026 servicing problems. Microsoft’s server updates have already been tied to separate startup and installation failures, which makes this feel less like a one-off mistake and more like a rough month for Windows servicing quality. The pattern matters because it changes how IT teams plan rollout, pilot rings, and rollback strategies. One bad update can erode confidence in the whole servicing pipeline.
The most important detail is that Microsoft does not describe this as a generic failure across all Windows systems. Instead, it says the issue affects devices where BitLocker is enabled on the operating system drive, the TPM validation profile explicitly includes PCR7, Secure Boot state shows PCR7 binding as “Not Possible,” the Windows UEFI CA 2023 certificate is present in the Secure Boot database, and the device has not yet transitioned to the 2023-signed Windows Boot Manager. That is a very specific set of preconditions, which explains why Microsoft frames the issue as more likely in managed enterprise environments than on personal PCs.
That distinction matters because it changes the remediation strategy. A corrupted patch would usually suggest uninstalling the update and waiting for a replacement. Here, Microsoft is saying the underlying problem sits at the intersection of policy and platform measurement, so the fix is often to realign the validation path rather than simply rip out the monthly cumulative update. That is a subtler, more enterprise-specific kind of problem.
The one-time nature of the event is also a clue that this is a binding transition issue, not a persistent encryption failure. In other words, the update appears to force a re-evaluation of boot trust, and BitLocker reacts to that re-evaluation by demanding a key. That behavior is consistent with the way BitLocker is designed, even if the timing is operationally ugly. Security systems often look like failures exactly when they are doing their job.
For enterprise administrators, the impact is amplified by scale. One machine in recovery mode is an inconvenience. Fifty machines in recovery mode is a support event. Hundreds of machines in the same policy state can create a wave of tickets, stalled workers, and emergency change approvals. The operational cost is often much higher than the actual technical defect, because the defect hits the boot boundary, where automation has fewer options and remote tools are less useful.
There is a second enterprise angle as well: fleets often contain mixed generations and mixed update states. Some devices may already be on the 2023-signed boot path, while others are still in pre-transition states. That unevenness is the enemy of clean servicing. When one cumulative update interacts differently with different hardware or firmware baselines, support teams suddenly have to diagnose not a single bug, but a matrix of states.
Even so, consumer confidence still takes a hit when BitLocker-related issues appear in the news. The average user may never touch PCR7 or think about boot manager signing, but they do understand a machine that suddenly asks for a recovery key. That is why even narrow enterprise bugs have a wider reputational shadow: they reinforce the familiar fear that Windows updates can be unpredictable.
PCR7 is the key measurement here because it is one of the platform configuration registers that BitLocker can use to decide whether the machine booted in the expected state. If a group policy explicitly requires PCR7, and the device reports that PCR7 binding is “Not Possible,” the machine is already in a fragile state before the update even lands. The April patch simply exposes that fragility.
That is the sort of problem that rarely shows up in a lab and often shows up in the field. Lab devices are usually clean, current, and curated. Real fleets are messy, with firmware variations, policy drift, and hardware histories that stretch across multiple Windows releases. Boot security changes are unforgiving because they expose everything that was already slightly out of alignment.
This also explains why the issue is likely to remain interesting to administrators even after the immediate fix ships. Secure Boot modernization is not a one-time event. It is a migration process, and migration processes often create friction exactly where security and availability intersect. Windows is not just being patched; it is being refit for a newer trust model.
The other major mitigation path is Known Issue Rollback. Microsoft says a KIR-style safeguard can be used where available to avoid the behavior that would otherwise trigger recovery. This is a useful enterprise tool because it can suppress a problematic code path without forcing organizations to discard the security benefits of the rest of the update. But it still requires planning, deployment discipline, and a support process that can move faster than a normal monthly cadence.
That tension captures the whole story. The update is meant to improve security, but the workaround requires a temporary relaxation of security controls to preserve availability. That is not hypocrisy; it is the reality of operating encrypted systems at scale. The hard part is knowing when the trade-off is justified and documenting the decision cleanly.
That creates the classic administrator’s dilemma: leave systems exposed, or accept some operational risk to stay patched. Microsoft’s decision to issue a remediation path rather than yank the update outright suggests the company believed the security benefits were still important enough to preserve. That is a telling signal about how the company is prioritizing patch hygiene versus rollback risk.
The balance is difficult because the failure mode is so early in the boot chain. An application bug can often be tolerated for a day. A boot trust issue is different. It can block the machine before normal recovery tools or remote support workflows are available, which is why IT teams tend to treat these defects with exceptional seriousness.
That lesson is likely to stick because it is painfully practical. Security teams and infrastructure teams do not get to choose whether boot trust matters. They only get to choose whether they learn that lesson in a lab, or on a Monday morning when a first reboot triggers recovery across part of the fleet. The latter is always more expensive.
In a sense, modern Windows servicing is becoming more layered and more brittle at the same time. Monthly cumulative updates now intersect with servicing stack updates, firmware trust changes, boot certificates, and enterprise policy enforcement. Each layer may work correctly on its own, yet still create a bad outcome when combined with the others. That is the hidden complexity of a platform that has to serve both consumers and highly managed enterprises.
The irony is that these changes are happening for good reasons. Microsoft is trying to harden the platform, reduce future certificate-expiration risk, and improve trust in the early boot sequence. But security improvements often have the ugliest deployment costs at the exact moment they succeed in surfacing configuration drift. That makes the rollout harder, not easier, even when the underlying goal is sound.
This also reinforces the value of release-health monitoring. Microsoft’s documentation is becoming part of the operational workflow, not just a reference library. In many cases, the support article itself is the incident-response tool. When a company names the trigger conditions precisely, it gives administrators a way to isolate risk before the first reboot becomes a help desk emergency.
Microsoft’s documentation also creates an opportunity for organizations to improve their own device hygiene. Many fleets have accumulated drift in BitLocker policy, Secure Boot state, and recovery-key handling over time. A bug like this forces teams to audit those assumptions and bring the encryption baseline back into view. That can be painful, but it is often valuable.
There is also a confidence problem. Every time a security update collides with boot behavior, administrators become more cautious about rolling out future updates, which can slow patch adoption and leave systems exposed longer than intended. That is the uncomfortable knock-on effect of update regressions: they do not just break machines, they can break trust in the patch process itself.
The longer-term question is whether Microsoft can keep modernizing Secure Boot and boot trust without repeatedly tripping over BitLocker. That challenge is not going away, because the platform is still in the middle of a broader trust transition. The more Microsoft hardens the boot path, the more it has to manage the operational side effects of that hardening.
What to watch next:
Source: hi-Tech.ua Microsoft has confirmed a BitLocker crash in recent Windows and Windows Server updates.
Overview
This episode is best understood as part of a larger Windows servicing story rather than as an isolated Patch Tuesday annoyance. Microsoft has spent much of 2026 modernizing the boot trust chain, rolling out Secure Boot-related changes while also trying to keep systems protected against serious vulnerabilities. That means the company is doing two things at once: hardening the platform and moving the installed base toward new trust anchors. When those changes intersect with BitLocker policy, even a small mismatch can surface as a recovery prompt instead of a normal boot.The practical reason this matters is that BitLocker recovery is not a normal error state. It is a deliberate security boundary, and it appears before Windows fully loads, which makes remote remediation far harder. If a workstation is locked in an office, help desk staff may eventually sort it out. If a remote device is sitting at the recovery screen with no one nearby who has the 48-digit key, the machine becomes a support incident, a security concern, and a productivity loss all at once. That is why this class of bug causes disproportionate concern in enterprise environments.
Microsoft’s documentation indicates that the issue is not random and not universal. It requires a very specific combination of BitLocker, TPM validation policy, Secure Boot state, boot manager versioning, and certificate presence. That narrow trigger profile is good news in one sense, because most consumer PCs are unlikely to meet it. But it is also bad news in another, because the affected systems are often the most tightly managed and security-conscious ones in the enterprise, exactly the devices organizations care most about.
Another reason the episode is getting attention is that it arrives alongside other April 2026 servicing problems. Microsoft’s server updates have already been tied to separate startup and installation failures, which makes this feel less like a one-off mistake and more like a rough month for Windows servicing quality. The pattern matters because it changes how IT teams plan rollout, pilot rings, and rollback strategies. One bad update can erode confidence in the whole servicing pipeline.
What Microsoft Confirmed
Microsoft has now acknowledged that some devices may enter BitLocker recovery after installing the April updates, especially when Secure Boot updates are involved. The company’s support notes for KB5082063 and KB5083769 say the prompt may appear on the first reboot after installation and that the condition is tied to a specific policy-and-firmware configuration. In practical terms, that means the bug is real, documented, and reproducible enough for Microsoft to spell out exact conditions.The most important detail is that Microsoft does not describe this as a generic failure across all Windows systems. Instead, it says the issue affects devices where BitLocker is enabled on the operating system drive, the TPM validation profile explicitly includes PCR7, Secure Boot state shows PCR7 binding as “Not Possible,” the Windows UEFI CA 2023 certificate is present in the Secure Boot database, and the device has not yet transitioned to the 2023-signed Windows Boot Manager. That is a very specific set of preconditions, which explains why Microsoft frames the issue as more likely in managed enterprise environments than on personal PCs.
Why the trigger conditions matter
This is not just a case of “update bad, BitLocker angry.” It is a trust-chain mismatch. Secure Boot changes how the machine validates its early boot path, and BitLocker watches those measurements closely to decide whether the platform still looks like the one it encrypted against. If policy says PCR7 must be part of validation, but the device is in a state where PCR7 binding is “Not Possible,” the boot transition can look suspicious enough to trigger recovery.That distinction matters because it changes the remediation strategy. A corrupted patch would usually suggest uninstalling the update and waiting for a replacement. Here, Microsoft is saying the underlying problem sits at the intersection of policy and platform measurement, so the fix is often to realign the validation path rather than simply rip out the monthly cumulative update. That is a subtler, more enterprise-specific kind of problem.
Why the first reboot is the dangerous moment
Microsoft says the issue typically shows up on the first restart after installation, then does not recur unless the relevant group policy changes again. That makes the bug feel episodic rather than permanent, but it does not make it harmless. The first reboot after patching is already a point of anxiety for administrators, and a BitLocker recovery prompt at that moment can turn a routine maintenance window into a recovery scramble.The one-time nature of the event is also a clue that this is a binding transition issue, not a persistent encryption failure. In other words, the update appears to force a re-evaluation of boot trust, and BitLocker reacts to that re-evaluation by demanding a key. That behavior is consistent with the way BitLocker is designed, even if the timing is operationally ugly. Security systems often look like failures exactly when they are doing their job.
Why Enterprises Feel This First
Microsoft’s own wording makes it clear that this is primarily an enterprise problem. The company’s guidance refers to group policy, TPM validation profiles, recovery key management, and the use of known-issue rollback mechanisms, all of which assume an IT-administered environment. That is a strong signal that the likely blast radius is managed fleets rather than consumer laptops with default settings.For enterprise administrators, the impact is amplified by scale. One machine in recovery mode is an inconvenience. Fifty machines in recovery mode is a support event. Hundreds of machines in the same policy state can create a wave of tickets, stalled workers, and emergency change approvals. The operational cost is often much higher than the actual technical defect, because the defect hits the boot boundary, where automation has fewer options and remote tools are less useful.
Managed fleets are more exposed
Managed systems are more likely to use explicit TPM validation profiles, and that is exactly where PCR7 comes into play. Organizations that hardened BitLocker beyond baseline settings may have done so for good reasons, but that hardening also creates more opportunities for a trust mismatch when Microsoft changes Secure Boot behavior. The stronger the validation, the less forgiving the platform becomes during boot-chain transitions.There is a second enterprise angle as well: fleets often contain mixed generations and mixed update states. Some devices may already be on the 2023-signed boot path, while others are still in pre-transition states. That unevenness is the enemy of clean servicing. When one cumulative update interacts differently with different hardware or firmware baselines, support teams suddenly have to diagnose not a single bug, but a matrix of states.
Why consumers are mostly shielded
Microsoft’s guidance suggests that ordinary consumer systems are far less likely to hit the condition because the trigger depends on a very specific combination of Secure Boot and BitLocker policy choices. Most home PCs do not run the kind of bespoke TPM validation setup that enterprise images commonly deploy. That does not make them immune, but it does make them less likely to be caught by the exact failure path Microsoft documented.Even so, consumer confidence still takes a hit when BitLocker-related issues appear in the news. The average user may never touch PCR7 or think about boot manager signing, but they do understand a machine that suddenly asks for a recovery key. That is why even narrow enterprise bugs have a wider reputational shadow: they reinforce the familiar fear that Windows updates can be unpredictable.
The Secure Boot and PCR7 Problem
At the center of this story is Secure Boot, which is not simply a switch you turn on and forget. It is a chain of trust that validates firmware, bootloaders, and early startup components before Windows takes over. When Microsoft changes the certificates or boot components in that chain, the measured values that BitLocker expects can shift, and that can trigger a recovery prompt even if nothing is “broken” in the ordinary sense.PCR7 is the key measurement here because it is one of the platform configuration registers that BitLocker can use to decide whether the machine booted in the expected state. If a group policy explicitly requires PCR7, and the device reports that PCR7 binding is “Not Possible,” the machine is already in a fragile state before the update even lands. The April patch simply exposes that fragility.
The 2023 boot manager transition
Microsoft’s documentation also points to the Windows UEFI CA 2023 certificate and the 2023-signed Windows Boot Manager. That detail matters because it suggests the company is managing a staged migration in boot trust assets, not just shipping ordinary security fixes. If a device has the new certificate but has not fully transitioned to the new boot manager, the boot chain may appear inconsistent from BitLocker’s point of view.That is the sort of problem that rarely shows up in a lab and often shows up in the field. Lab devices are usually clean, current, and curated. Real fleets are messy, with firmware variations, policy drift, and hardware histories that stretch across multiple Windows releases. Boot security changes are unforgiving because they expose everything that was already slightly out of alignment.
Why this is a trust-chain story, not a patch story
It is tempting to think of this as “the update caused BitLocker to break.” That is too simple. The better way to read it is that the update surfaced a latent configuration issue in the boot trust chain, and BitLocker interpreted that change as a reason to require recovery. That distinction matters because it explains why Microsoft is recommending policy review and protector suspension rather than urging everyone to uninstall the update outright.This also explains why the issue is likely to remain interesting to administrators even after the immediate fix ships. Secure Boot modernization is not a one-time event. It is a migration process, and migration processes often create friction exactly where security and availability intersect. Windows is not just being patched; it is being refit for a newer trust model.
The Workarounds Microsoft Recommends
Microsoft’s mitigation guidance is practical, if not especially lightweight. For affected systems, administrators are advised to remove or relax the TPM validation policy before deployment, refresh group policy, then suspend and re-enable BitLocker protectors so the device can rebuild its bindings cleanly. That is the kind of process you would expect when the issue lives in platform measurement rather than in user-facing application code.The other major mitigation path is Known Issue Rollback. Microsoft says a KIR-style safeguard can be used where available to avoid the behavior that would otherwise trigger recovery. This is a useful enterprise tool because it can suppress a problematic code path without forcing organizations to discard the security benefits of the rest of the update. But it still requires planning, deployment discipline, and a support process that can move faster than a normal monthly cadence.
The recommended admin sequence
Administrators trying to avoid the recovery prompt are being told to work methodically, not reactively. In broad terms, the safest path is to identify devices that match the trigger conditions, adjust policy if needed, apply the update only after the trust state is aligned, and then verify that the boot chain remains stable. That sequence is boring by design, and boring is exactly what you want when BitLocker is involved.- Confirm whether BitLocker is enabled on the OS drive.
- Check whether the TPM validation profile explicitly includes PCR7.
- Verify PCR7 binding status in system information.
- Determine whether the device has already moved to the 2023-signed boot manager.
- Apply policy changes or a KIR path before broad deployment.
Why the workaround is not trivial
There is a subtle cost to Microsoft’s recommended approach. Suspending BitLocker protectors and changing validation policy can temporarily reduce the device’s defense-in-depth posture, even if only briefly. In a security-sensitive organization, that is not a step to take casually. It has to be weighed against the risk of putting devices into recovery in the first place. The workaround is sensible, but it is not free.That tension captures the whole story. The update is meant to improve security, but the workaround requires a temporary relaxation of security controls to preserve availability. That is not hypocrisy; it is the reality of operating encrypted systems at scale. The hard part is knowing when the trade-off is justified and documenting the decision cleanly.
Why Microsoft Can’t Simply Skip the Update
One reason this issue is delicate is that the April 2026 security updates are not optional fluff. Microsoft’s own release notes indicate that the cycle addressed a large number of vulnerabilities, including zero-day issues that were already being exploited. In other words, skipping the update entirely is not an attractive answer for security-conscious organizations.That creates the classic administrator’s dilemma: leave systems exposed, or accept some operational risk to stay patched. Microsoft’s decision to issue a remediation path rather than yank the update outright suggests the company believed the security benefits were still important enough to preserve. That is a telling signal about how the company is prioritizing patch hygiene versus rollback risk.
Security gain versus operational pain
This is where the incident becomes bigger than a simple bug report. The same release that can produce BitLocker recovery prompts is also part of the security response to active threats. That means the update is not merely annoying; it is part of the defense line against real-world exploitation. Administrators therefore have to solve two problems at once: keeping the patch and avoiding the lockout.The balance is difficult because the failure mode is so early in the boot chain. An application bug can often be tolerated for a day. A boot trust issue is different. It can block the machine before normal recovery tools or remote support workflows are available, which is why IT teams tend to treat these defects with exceptional seriousness.
The enterprise calculus
Enterprises are increasingly expected to patch quickly, but “quickly” now has to include more preflight validation. The smarter organizations will not delay security updates indefinitely; they will tighten their pilot rings, verify boot readiness, and make sure recovery keys are escrowed before the update lands. That is not a retreat from patching. It is patching with better operational discipline.That lesson is likely to stick because it is painfully practical. Security teams and infrastructure teams do not get to choose whether boot trust matters. They only get to choose whether they learn that lesson in a lab, or on a Monday morning when a first reboot triggers recovery across part of the fleet. The latter is always more expensive.
The Broader Pattern in Windows Servicing
This is not the first time Microsoft has had to chase a Windows regression with an out-of-band response, and it probably will not be the last. The April 2026 cycle has already been associated with other server-side issues, including restart loops and installation failures on some Windows Server 2025 systems. That broader context matters because it shows the BitLocker issue is part of a wider servicing stress test, not an isolated stumble.In a sense, modern Windows servicing is becoming more layered and more brittle at the same time. Monthly cumulative updates now intersect with servicing stack updates, firmware trust changes, boot certificates, and enterprise policy enforcement. Each layer may work correctly on its own, yet still create a bad outcome when combined with the others. That is the hidden complexity of a platform that has to serve both consumers and highly managed enterprises.
Why the boot chain is increasingly fragile
The boot chain used to be a background concern for many organizations. Now it is becoming a first-class operational domain. Secure Boot certificate rollovers, boot manager transitions, and device encryption baselines are all converging into the same management surface, which means a routine update can unexpectedly become a platform trust event. That is a lot to ask of any servicing model.The irony is that these changes are happening for good reasons. Microsoft is trying to harden the platform, reduce future certificate-expiration risk, and improve trust in the early boot sequence. But security improvements often have the ugliest deployment costs at the exact moment they succeed in surfacing configuration drift. That makes the rollout harder, not easier, even when the underlying goal is sound.
What this means for patch planning
For IT departments, the implication is simple: update readiness now includes boot readiness. That means checking PCR7 state, confirming boot manager versioning, validating recovery key escrow, and staging deployment more carefully than before. The days of assuming an encryption policy will quietly survive every cumulative update are over.This also reinforces the value of release-health monitoring. Microsoft’s documentation is becoming part of the operational workflow, not just a reference library. In many cases, the support article itself is the incident-response tool. When a company names the trigger conditions precisely, it gives administrators a way to isolate risk before the first reboot becomes a help desk emergency.
Strengths and Opportunities
The most encouraging aspect of this incident is that Microsoft has been unusually specific. Administrators are not being asked to guess at vague symptoms; they are being given concrete configuration conditions, a reproducible trigger profile, and a set of mitigation steps. That is not a perfect outcome, but it is a manageable one.Microsoft’s documentation also creates an opportunity for organizations to improve their own device hygiene. Many fleets have accumulated drift in BitLocker policy, Secure Boot state, and recovery-key handling over time. A bug like this forces teams to audit those assumptions and bring the encryption baseline back into view. That can be painful, but it is often valuable.
- Microsoft identified a narrow trigger set rather than leaving the issue vague.
- The recovery prompt is described as a first-reboot event, not a permanent loop.
- Administrators have a policy-based mitigation path.
- Known Issue Rollback gives enterprises a second safety net.
- The update still carries important security fixes, including zero-day coverage.
- The episode can improve BitLocker key escrow and recovery readiness.
- Organizations can use the event to tighten pilot-ring discipline.
- Security and infrastructure teams can align on boot-chain validation.
Risks and Concerns
The obvious risk is disruption. BitLocker recovery prompts at boot are among the most stressful Windows failures because they happen before the user can do anything useful. Even a narrow issue can become expensive if it lands on the wrong devices at the wrong time, especially in distributed or remote-heavy organizations.There is also a confidence problem. Every time a security update collides with boot behavior, administrators become more cautious about rolling out future updates, which can slow patch adoption and leave systems exposed longer than intended. That is the uncomfortable knock-on effect of update regressions: they do not just break machines, they can break trust in the patch process itself.
- Recovery keys may not be immediately accessible to help desks.
- Remote users can be stranded away from support.
- Policy changes made in haste can weaken protection temporarily.
- Mixed device generations complicate troubleshooting.
- Update distrust can slow future patch deployment.
- Boot-chain transitions are hard to explain to non-technical users.
- The issue could expose forgotten policy drift in older fleets.
- Additional April servicing problems add noise to root-cause analysis.
Looking Ahead
The immediate question is whether Microsoft’s mitigation guidance fully contains the problem in production environments. Administrators will want to know whether the recovery prompt truly remains a first-reboot event and whether the recommended policy changes or KIR deployment eliminate the trigger cleanly across mixed fleets. If the answer is yes, this becomes a contained servicing defect. If not, it becomes another reason for more conservative rollout strategies.The longer-term question is whether Microsoft can keep modernizing Secure Boot and boot trust without repeatedly tripping over BitLocker. That challenge is not going away, because the platform is still in the middle of a broader trust transition. The more Microsoft hardens the boot path, the more it has to manage the operational side effects of that hardening.
What to watch next:
- Whether Microsoft closes the BitLocker known issue with a permanent servicing fix.
- Whether additional Windows Server or Windows 11 builds show the same recovery behavior.
- Whether enterprises adopt stricter preflight checks for PCR7 and boot-manager state.
- Whether the April 2026 servicing cycle produces more follow-on regressions.
- Whether Microsoft expands guidance for mixed-fleet Secure Boot transitions.
Source: hi-Tech.ua Microsoft has confirmed a BitLocker crash in recent Windows and Windows Server updates.