Windows 11 Update KB5079391 Pulled: What IT Teams Should Do Now

What Happened With KB5079391

Microsoft released KB5079391 as a non-security preview update for Windows 11 in early 2025. Within hours of deployment, IT administrators reported widespread installation failures producing error code 0x80073712 — a Windows component store corruption error that halts the update process entirely. Microsoft has since pulled the update from Windows Update while it investigates the root cause. The 0x80073712 error typically signals that files required by the Windows servicing stack are missing, corrupted, or in a state the installer cannot reconcile. In practice, affected machines either stall mid-installation or roll back without completing the update, leaving systems in an indeterminate state that can complicate future patching cycles. Microsoft confirmed the issue via the Windows Health Dashboard, advising organisations not to attempt manual installation workarounds until a revised build is published. The original report was covered by BleepingComputer, which noted the scale of affected deployments across managed environments.

Why a Non-Security Update Still Creates a Security Problem

The immediate instinct is to treat a failed non-security update as an inconvenience rather than a threat. That instinct is wrong. Here's the problem: when a preview update fails and rolls back, it can leave the Windows Update client itself in a degraded state. Organisations that push KB5079391 through a management platform such as Microsoft Endpoint Configuration Manager or Intune may find that subsequent security updates queue behind the failed job, or that update compliance reporting shows machines as current when they are not. This creates a measurable gap. A machine that appears patched in your dashboard but has a broken update stack will miss the next Patch Tuesday rollout. If that rollout addresses a remotely exploitable vulnerability — and most months it does — those machines carry elevated risk for the entire window between patch release and the point where someone notices the failure. The broader pattern matters too. According to the Ponemon Institute's 2023 State of Vulnerability Management report, 57% of breach victims attributed their incident to an unpatched known vulnerability. A broken update mechanism is functionally the same as no patching at all, regardless of intent.

How This Affects UK and New Zealand Organisations Specifically

For UK organisations subject to Cyber Essentials or Cyber Essentials Plus certification, the stakes are concrete. Cyber Essentials requires that high-risk and critical patches are applied within 14 days of release. A broken update pipeline does not earn an exemption — assessors check patch state, not patch intent. Organisations in regulated sectors including financial services, healthcare, and critical national infrastructure face additional exposure. The FCA expects firms to maintain demonstrable control over their endpoint environments. A fleet of machines with silently failed updates is a compliance finding waiting to happen. For New Zealand and Australasia-based organisations, the same principle applies under the NZ Privacy Act 2020 and the Australian Signals Directorate's Essential Eight maturity framework, which lists application patching as a baseline control. A failed Windows update that compromises future patch delivery directly undermines Essential Eight compliance posture. What this means in practice: organisations need visibility at the individual device level, not just aggregate compliance percentages. Aggregate dashboards mask the machines that matter most to an attacker.

What Should Your Patch Management Process Look Like After This?

The KB5079391 incident is a useful forcing function for reviewing your update pipeline. A sound patch management process does five things consistently: First, it stages rollouts. Preview or optional updates should never go to production endpoints before a controlled pilot group validates them. Microsoft flags preview updates precisely because they carry higher instability risk than cumulative or security updates. Second, it monitors for failure, not just completion. Most management platforms report success/failure at the job level. You need granular error code reporting so that a 0x80073712 failure on 200 machines appears as an alert, not a footnote in the next weekly report. Third, it correlates patch state with vulnerability exposure. Knowing that a machine failed an update is only useful if you also know what vulnerabilities that machine is now carrying. Without that correlation, you cannot prioritise remediation. Fourth, it validates rollback integrity. When Windows rolls back a failed update, the component store may still be in a degraded state. A DISM /CheckHealth scan post-rollback should be part of your standard failure response runbook. Fifth, it separates preview updates from security updates in policy. Optional non-security previews serve a different purpose from critical patches. They should be in separate deployment rings with longer dwell times in test environments.

• Stage preview updates to a pilot group before broad deployment
• Alert on error codes, not just failed job counts
• Correlate patch failures with open CVEs on affected devices
• Run DISM health checks after any failed update rollback
• Keep preview and security update rings separate in your MDM policy

How Attack Surface Management Catches What Dashboards Miss

The fundamental problem with relying on your patch management dashboard alone is that it only shows you what it knows about. Devices that fall off your management plane — a remote worker's laptop that has not checked in for three weeks, a VM spun up outside standard provisioning, a legacy system someone forgot to enrol — are invisible to your patching toolchain but fully visible to an attacker scanning your perimeter. This is where continuous attack surface management becomes directly relevant. Hadrian, which Kyanite Blue offers as part of its attack surface management practice, continuously maps your externally visible assets and identifies exposure points that internal tooling does not track. When a patch fails silently and a vulnerable service becomes accessible, Hadrian surfaces that exposure before an attacker does. The combination of strong endpoint controls and external visibility closes the gap that incidents like KB5079391 expose. Internal dashboards tell you what your tools think is true. External scanning tells you what an attacker would actually find.

Endpoint Protection Cannot Be Paused While You Wait for Microsoft

Microsoft will issue a revised build of KB5079391, but there is no published timeline. In the interim, organisations should treat the patch gap as an active risk, not a waiting room. For UK organisations, Coro's unified endpoint protection provides layered controls that remain active independent of Windows Update status. Behavioural detection, email security, and cloud application controls do not depend on the Windows servicing stack being healthy — they operate in parallel, which matters precisely when that stack is broken. For New Zealand and Australasia-based organisations, ESET's enterprise endpoint protection operates at the kernel level and maintains its detection capabilities regardless of update pipeline state. ESET's LiveGrid threat intelligence network continues to push signature and behaviour updates through its own delivery mechanism, independent of Windows Update. Sophos MDR adds another layer that patch management cannot replicate: 24/7 human-led threat detection and response. If an attacker exploits a vulnerability during the window between a failed patch and its replacement, Sophos MDR analysts identify and contain the activity in real time. A broken update pipeline does not mean you are defenceless — but it does mean your detection capability becomes more important, not less. BlackFog is worth considering in this context as well. Ransomware operators specifically hunt for machines with degraded update states because they represent easier initial access. BlackFog's anti data exfiltration technology stops the data theft phase of ransomware attacks, which is where organisations lose the most — both financially and reputationally — even when the encryption payload is eventually recovered from backup.

The Practical Steps to Take Right Now

If you have already pushed KB5079391 to your environment, take the following steps before Microsoft releases a fix. First, pause further deployment of the update immediately. If you are running Windows Server Update Services or Intune, decline the update in your catalogue so it does not continue to attempt installation on machines that have not yet received it. Second, identify affected machines by querying for the 0x80073712 error code in your management platform's event logs or compliance reports. Prioritise any machines in internet-facing roles or handling sensitive data. Third, run DISM /Online /Cleanup-Image /CheckHealth on a representative sample of affected machines to assess whether the component store is genuinely corrupted or whether the failure was confined to the update job itself. Fourth, verify that the Windows Update client on affected machines will successfully accept the next security update when Microsoft releases it. You can test this by checking that the Update Orchestrator Service is running and that Windows Update history shows the last successful security update correctly. Fifth, document the incident in your risk register. A patch failure affecting a material number of endpoints is a risk event, regardless of whether it caused a breach. If you are Cyber Essentials certified or working towards certification, your assessor may ask about it.

Frequently Asked Questions