Microsoft’s April 14, 2026 Windows security updates intentionally block vulnerable versions of the third-party kernel driver psmounterex.sys, meaning some backup applications can still create images but may fail when mounting, browsing, or restoring those images as virtual drives. That is the plain operational answer, but it undersells the larger story. Microsoft has not merely broken a backup feature; it has drawn a brighter line around what Windows will tolerate inside the kernel. For admins, the message is uncomfortable but overdue: if your recovery workflow depends on an old vulnerable driver, your recovery workflow is now part of the attack surface.
The affected driver, psmounterex.sys, is not a glamorous component. It exists to let backup software expose disk images as mountable virtual drives, the sort of convenience feature that saves time during a file-level restore or forensic check. Precisely because it sits in the kernel, however, it also occupies one of the most privileged positions in Windows.
That is why Microsoft’s April 2026 update matters beyond the immediate annoyance of failed mounts and confusing VSS messages. The company is saying that a signed driver with a known privilege-escalation flaw is no longer acceptable simply because it shipped with legitimate software. Trust, in this case, is no longer inherited from the installer.
The specific vulnerability, CVE-2023-43896, concerns Macrium Reflect 8.1.7544 and earlier, where a buffer overflow in the driver could allow local attackers to escalate privileges or execute arbitrary code. The flaw was disclosed and patched years before this Windows-side enforcement change, which makes the timing important. Microsoft is not reacting to a brand-new bug; it is closing the grace period.
For users, the visible symptom may be mundane: a backup image that used to mount no longer mounts. For defenders, the invisible win is more important: one more known-vulnerable kernel pathway is removed from the menu of techniques available to attackers.
That split behavior is exactly what will make this incident confusing in the field. If backups continue to run, many users will assume the product is healthy. The failure will appear later, at the moment someone tries to inspect or restore from an image, which is the worst possible time to discover that a convenience driver has been silently pushed out of the trust boundary.
This is also why the affected functionality should not be described merely as “backup broken.” The core act of writing an image may remain intact. What fails is the workflow around accessing that image through a vulnerable kernel driver. That distinction matters for triage, because it tells admins where to focus testing: not just scheduled backup jobs, but mount, browse, granular restore, and recovery drills.
The industry has trained users to equate a green backup job with safety. April 2026 is a reminder that a backup is only as good as the restore path, and the restore path often depends on parts of the stack that rarely receive daylight until something goes wrong.
Attackers understand this very well. A vulnerable but legitimately signed driver can become a ready-made bridge into kernel mode, a technique often described as bring your own vulnerable driver. The attacker does not need to defeat Microsoft’s signing model outright if a trusted driver already contains the primitive needed to tamper with memory, disable protections, or escalate privileges.
Microsoft’s vulnerable driver blocklist is one response to that reality. It targets drivers with known security vulnerabilities, malicious behavior, abused signing certificates, or behavior that undermines the Windows security model. In practical terms, it allows Windows Code Integrity to say: this binary may be signed, but it is not safe enough to load.
That is a philosophical shift as much as a technical one. Signature once functioned as a broad proxy for trust. In modern Windows, signature is increasingly only the beginning of the conversation. A signed driver can still be stale, exploitable, or operationally unacceptable.
The psmounterex.sys block is therefore less an outlier than a case study. Microsoft is applying the same logic to backup software that it has applied elsewhere: kernel code must be current enough to remain trusted, not merely old enough to be familiar.
That tension is unavoidable. A serious image-backup product needs to interact with volumes, snapshots, boot records, locked files, and sometimes virtualized views of disks. It may need drivers to do that work efficiently. But “necessary” is not the same as “risk-free,” and the kernel does not care whether a flawed memory operation came from a backup vendor or a malware author.
This is the uncomfortable truth under Microsoft’s support note. Backup vendors are part of the kernel supply chain. Their drivers can become exploitation tools if they remain vulnerable on customer systems after fixes exist. Administrators cannot treat them as benign utilities sitting off to the side of the security model.
The fact that psmounterex.sys is tied to image mounting rather than image creation makes the lesson sharper. A feature designed for convenience can carry kernel-level consequences. Mounting a backup image in Explorer feels like a userland operation; the driver that enables it is not.
That mismatch between user perception and technical privilege is one of Windows’ oldest security problems. The interface says “browse files.” The architecture says “load kernel code.”
That context makes the April 2026 change notable. Microsoft is accepting user-visible failures in order to prevent vulnerable versions of psmounterex.sys from loading. It is a decision that will frustrate some users, especially those running older backup software on otherwise stable machines, but it is not arbitrary.
The old bargain — keep compatibility until the user upgrades voluntarily — breaks down when vulnerable signed drivers are actively useful to attackers. The more Windows hardens user-mode applications, browser sandboxes, credential stores, and endpoint defenses, the more attractive kernel drivers become as shortcuts around the system’s intended boundaries.
Microsoft’s enforcement posture is also a signal to vendors. Patching a driver is not enough if old versions remain widely deployed and trusted indefinitely. Eventually the platform owner may enforce the upgrade path at the loading boundary.
That is a harder world for software compatibility, but probably a more honest one. If a driver is dangerous enough to be on the vulnerable blocklist, then allowing it to load indefinitely because some restore workflow might depend on it is not neutral. It is a security decision in favor of the vulnerable code.
That is why IT teams should not treat this as a help-desk curiosity. A backup product that passes nightly job checks but fails mount testing is in an ambiguous state. It may still protect against bare-metal loss while failing at the faster, more common task of retrieving individual files or validating image contents.
The correct response is to test restores on patched machines, not simply check backup logs. If the software uses psmounterex.sys and the installed version is vulnerable, Code Integrity may block the driver. Event Viewer becomes the source of truth, because user-facing backup errors may misleadingly point toward VSS rather than the driver block.
The VSS angle is especially treacherous. Volume Shadow Copy Service is already a familiar suspect when backup software fails, so admins may burn time restarting services, re-registering writers, or chasing snapshot-state errors. In this case, VSS may be the messenger rather than the culprit.
The practical diagnostic chain should run backward from the new enforcement behavior. If mounts fail after installing the April 14, 2026 or later Windows security update, and if Code Integrity logs show psmounterex.sys being blocked, the issue is not a random backup regression. It is Windows enforcing a block against a known vulnerable kernel driver.
There will always be pressure to find a quick bypass, especially in small environments where backup software was installed years ago and then forgotten. That pressure is understandable. A user who needs one file from yesterday’s image does not want a lecture about kernel integrity.
But the security model cannot be built around the emergency exception as the default operating mode. If the driver was patched years ago, the operational failure is not the April 2026 update alone. It is the accumulated technical debt of leaving old kernel components in production.
For managed environments, this should trigger a software inventory exercise. Admins need to know which endpoints and servers have affected backup versions installed, whether the driver is present, whether current software releases replace it with a fixed version, and whether restore testing passes after patching. That work is dull, but it is cheaper than discovering the answer during ransomware recovery.
Consumer users face a simpler version of the same problem. If Macrium Reflect or another backup application begins failing to mount images after April’s Windows update, the first move should be to install the latest supported version of the backup product. If the product is unsupported, the user should assume the failure is a warning about age, not merely a compatibility nuisance.
Microsoft says the blocklist has been enabled by default for Windows 11 devices since the Windows 11 2022 Update and can also be enforced when Memory Integrity, Smart App Control, or S mode is active, with caveats for older server versions. It is also updated through major Windows releases, optional updates, and occasionally regular servicing. In other words, the exact enforcement state can vary by OS version, configuration, and update history.
That variability is a problem for fleet management. Two machines with the same backup application may not behave identically if one has newer blocklist enforcement, HVCI enabled, or a different servicing state. The result is the sort of “works on my machine” troubleshooting that drives admins toward superstition unless they check Code Integrity logs and policy state.
The deeper shift is that Windows security is becoming more policy-driven and more revocation-driven. It is not enough to ask whether a binary is installed and signed. Admins increasingly need to ask whether the platform still considers it loadable under current policy.
That is a healthier security posture, but it is not frictionless. Every policy-based security gain creates a documentation and testing burden. Microsoft can block known-bad drivers, but customers still have to map that enforcement to real business processes.
That timeline will feel unfair to users who never heard of the CVE and never thought of their backup tool as an attack surface. But from Microsoft’s perspective, the delay is already the compromise. The company did not block everything the day the vulnerability became public; it allowed time for vendor updates and ecosystem movement.
At some point, however, compatibility becomes complicity. If Microsoft continues to allow known vulnerable kernel drivers to load forever, it preserves legacy workflows by subsidizing attacker opportunity. If it blocks them, it breaks some workflows while reducing a class of abuse.
There is no painless answer here. Windows remains valuable precisely because it runs decades of hardware and software, and that long tail is part of the platform’s economic strength. But the long tail is also where vulnerable drivers go to become undead infrastructure.
The April 2026 update is a reminder that the kernel is not a museum. Old code does not earn permanent residency because it once solved a practical problem.
The second task is to look for Code Integrity evidence. If Event Viewer reports that psmounterex.sys was blocked from loading, the failure is not a generic VSS issue. It is a direct consequence of Windows enforcing the vulnerable driver blocklist.
The third task is vendor alignment. Backup software should be updated to a release that no longer depends on a vulnerable version of the driver. If the vendor cannot clearly state whether a given version is affected, that uncertainty should be treated as a risk in its own right.
The fourth task is policy discipline. Organizations that use App Control for Business, HVCI, Smart App Control, or other hardening features need a way to stage and audit driver-policy changes before they collide with business-critical tooling. That does not mean avoiding enforcement. It means treating kernel-driver trust as a managed lifecycle.
The final task is communication. Help desks should know that April 2026-era failures involving mounted backup images may be caused by driver blocking. Otherwise, users will receive generic VSS troubleshooting advice that misses the new behavior entirely.
For enthusiasts, the lesson is to keep backup tools current and test actual restores, not just scheduled jobs. For sysadmins, the lesson is to inventory low-level software with the same seriousness applied to endpoint agents and VPN clients. For vendors, the lesson is that a signed driver is no longer a permanent passport into the Windows kernel.
This is also a cultural change. Windows users have long treated driver breakage as evidence that Microsoft has overreached. Sometimes that criticism is deserved. But in a world where attackers routinely abuse legitimate drivers, “it used to load” is not a security argument.
Microsoft’s decision will inconvenience some users. It may also prevent some compromised machines from turning a stale backup driver into a kernel foothold. The industry should be mature enough to hold both facts at once.
Source: Microsoft Support April 2026 Windows security updates introduce protections to known vulnerable kernel drivers - Microsoft Support
Microsoft Turns a Backup Driver Into a Security Boundary
The affected driver, psmounterex.sys, is not a glamorous component. It exists to let backup software expose disk images as mountable virtual drives, the sort of convenience feature that saves time during a file-level restore or forensic check. Precisely because it sits in the kernel, however, it also occupies one of the most privileged positions in Windows.That is why Microsoft’s April 2026 update matters beyond the immediate annoyance of failed mounts and confusing VSS messages. The company is saying that a signed driver with a known privilege-escalation flaw is no longer acceptable simply because it shipped with legitimate software. Trust, in this case, is no longer inherited from the installer.
The specific vulnerability, CVE-2023-43896, concerns Macrium Reflect 8.1.7544 and earlier, where a buffer overflow in the driver could allow local attackers to escalate privileges or execute arbitrary code. The flaw was disclosed and patched years before this Windows-side enforcement change, which makes the timing important. Microsoft is not reacting to a brand-new bug; it is closing the grace period.
For users, the visible symptom may be mundane: a backup image that used to mount no longer mounts. For defenders, the invisible win is more important: one more known-vulnerable kernel pathway is removed from the menu of techniques available to attackers.
The Error Message Is the Wrong Place to Start
Microsoft says affected systems may show failures when backup applications try to mount image files as virtual drives, browse backup contents, or restore from images. Some users may see VSS-related errors such as snapshot timeouts orVSS_E_BAD_STATE, while Event Viewer may record Code Integrity events showing that psmounterex.sys was blocked from loading. The critical clue is that full image backup creation may still succeed while image-mount operations fail.That split behavior is exactly what will make this incident confusing in the field. If backups continue to run, many users will assume the product is healthy. The failure will appear later, at the moment someone tries to inspect or restore from an image, which is the worst possible time to discover that a convenience driver has been silently pushed out of the trust boundary.
This is also why the affected functionality should not be described merely as “backup broken.” The core act of writing an image may remain intact. What fails is the workflow around accessing that image through a vulnerable kernel driver. That distinction matters for triage, because it tells admins where to focus testing: not just scheduled backup jobs, but mount, browse, granular restore, and recovery drills.
The industry has trained users to equate a green backup job with safety. April 2026 is a reminder that a backup is only as good as the restore path, and the restore path often depends on parts of the stack that rarely receive daylight until something goes wrong.
The Kernel Has Become Too Valuable to Trust by Reputation
Windows has lived for decades with a vast ecosystem of third-party kernel drivers. Storage, backup, security, gaming anti-cheat, hardware monitoring, VPNs, virtualization, and endpoint tools have all wanted low-level access. That ecosystem gave Windows flexibility, but it also created an enormous privilege-management problem.Attackers understand this very well. A vulnerable but legitimately signed driver can become a ready-made bridge into kernel mode, a technique often described as bring your own vulnerable driver. The attacker does not need to defeat Microsoft’s signing model outright if a trusted driver already contains the primitive needed to tamper with memory, disable protections, or escalate privileges.
Microsoft’s vulnerable driver blocklist is one response to that reality. It targets drivers with known security vulnerabilities, malicious behavior, abused signing certificates, or behavior that undermines the Windows security model. In practical terms, it allows Windows Code Integrity to say: this binary may be signed, but it is not safe enough to load.
That is a philosophical shift as much as a technical one. Signature once functioned as a broad proxy for trust. In modern Windows, signature is increasingly only the beginning of the conversation. A signed driver can still be stale, exploitable, or operationally unacceptable.
The psmounterex.sys block is therefore less an outlier than a case study. Microsoft is applying the same logic to backup software that it has applied elsewhere: kernel code must be current enough to remain trusted, not merely old enough to be familiar.
Backup Software Is Not Exempt From the Rules of Exploitation
Backup tools occupy a strange place in enterprise security. They are treated as sacred infrastructure, because they are the last line of defense after ransomware, hardware failure, accidental deletion, or botched patching. Yet they often require exactly the sort of deep system access that makes security teams nervous.That tension is unavoidable. A serious image-backup product needs to interact with volumes, snapshots, boot records, locked files, and sometimes virtualized views of disks. It may need drivers to do that work efficiently. But “necessary” is not the same as “risk-free,” and the kernel does not care whether a flawed memory operation came from a backup vendor or a malware author.
This is the uncomfortable truth under Microsoft’s support note. Backup vendors are part of the kernel supply chain. Their drivers can become exploitation tools if they remain vulnerable on customer systems after fixes exist. Administrators cannot treat them as benign utilities sitting off to the side of the security model.
The fact that psmounterex.sys is tied to image mounting rather than image creation makes the lesson sharper. A feature designed for convenience can carry kernel-level consequences. Mounting a backup image in Explorer feels like a userland operation; the driver that enables it is not.
That mismatch between user perception and technical privilege is one of Windows’ oldest security problems. The interface says “browse files.” The architecture says “load kernel code.”
Microsoft Is Choosing Breakage Over Silent Exposure
There is a reason Microsoft historically moves cautiously with driver blocklists. Blocking a kernel driver can break devices, software, or workflows, and in rare cases can contribute to crashes. The company has acknowledged that it balances security risk against compatibility and reliability, and that the blocklist delivered through Windows may lag the broader recommended list to avoid mass disruption.That context makes the April 2026 change notable. Microsoft is accepting user-visible failures in order to prevent vulnerable versions of psmounterex.sys from loading. It is a decision that will frustrate some users, especially those running older backup software on otherwise stable machines, but it is not arbitrary.
The old bargain — keep compatibility until the user upgrades voluntarily — breaks down when vulnerable signed drivers are actively useful to attackers. The more Windows hardens user-mode applications, browser sandboxes, credential stores, and endpoint defenses, the more attractive kernel drivers become as shortcuts around the system’s intended boundaries.
Microsoft’s enforcement posture is also a signal to vendors. Patching a driver is not enough if old versions remain widely deployed and trusted indefinitely. Eventually the platform owner may enforce the upgrade path at the loading boundary.
That is a harder world for software compatibility, but probably a more honest one. If a driver is dangerous enough to be on the vulnerable blocklist, then allowing it to load indefinitely because some restore workflow might depend on it is not neutral. It is a security decision in favor of the vulnerable code.
The Real Outage Is in Restore Confidence
The most immediate operational risk is not that backups stop being created. Microsoft explicitly notes that full image backups may still succeed. The risk is that organizations discover, during an incident, that image mounting, browsing, or restore workflows do not behave as expected after April’s updates.That is why IT teams should not treat this as a help-desk curiosity. A backup product that passes nightly job checks but fails mount testing is in an ambiguous state. It may still protect against bare-metal loss while failing at the faster, more common task of retrieving individual files or validating image contents.
The correct response is to test restores on patched machines, not simply check backup logs. If the software uses psmounterex.sys and the installed version is vulnerable, Code Integrity may block the driver. Event Viewer becomes the source of truth, because user-facing backup errors may misleadingly point toward VSS rather than the driver block.
The VSS angle is especially treacherous. Volume Shadow Copy Service is already a familiar suspect when backup software fails, so admins may burn time restarting services, re-registering writers, or chasing snapshot-state errors. In this case, VSS may be the messenger rather than the culprit.
The practical diagnostic chain should run backward from the new enforcement behavior. If mounts fail after installing the April 14, 2026 or later Windows security update, and if Code Integrity logs show psmounterex.sys being blocked, the issue is not a random backup regression. It is Windows enforcing a block against a known vulnerable kernel driver.
The Vendor Update Is the Fix, Not the Workaround
Microsoft’s guidance is blunt: update the backup software, and contact the application vendor if you are unsure whether your version is affected. That is the only answer that scales. Disabling platform protections to keep a vulnerable driver alive may restore a feature, but it also restores the exposure Microsoft is trying to remove.There will always be pressure to find a quick bypass, especially in small environments where backup software was installed years ago and then forgotten. That pressure is understandable. A user who needs one file from yesterday’s image does not want a lecture about kernel integrity.
But the security model cannot be built around the emergency exception as the default operating mode. If the driver was patched years ago, the operational failure is not the April 2026 update alone. It is the accumulated technical debt of leaving old kernel components in production.
For managed environments, this should trigger a software inventory exercise. Admins need to know which endpoints and servers have affected backup versions installed, whether the driver is present, whether current software releases replace it with a fixed version, and whether restore testing passes after patching. That work is dull, but it is cheaper than discovering the answer during ransomware recovery.
Consumer users face a simpler version of the same problem. If Macrium Reflect or another backup application begins failing to mount images after April’s Windows update, the first move should be to install the latest supported version of the backup product. If the product is unsupported, the user should assume the failure is a warning about age, not merely a compatibility nuisance.
The Blocklist Is Becoming a Patch Channel of Its Own
The vulnerable driver blocklist has sometimes been treated as a sidecar feature: important, but secondary to the monthly cumulative update. That framing is becoming less useful. When a blocklist update changes whether software can load kernel code, it becomes a functional patch channel with direct operational consequences.Microsoft says the blocklist has been enabled by default for Windows 11 devices since the Windows 11 2022 Update and can also be enforced when Memory Integrity, Smart App Control, or S mode is active, with caveats for older server versions. It is also updated through major Windows releases, optional updates, and occasionally regular servicing. In other words, the exact enforcement state can vary by OS version, configuration, and update history.
That variability is a problem for fleet management. Two machines with the same backup application may not behave identically if one has newer blocklist enforcement, HVCI enabled, or a different servicing state. The result is the sort of “works on my machine” troubleshooting that drives admins toward superstition unless they check Code Integrity logs and policy state.
The deeper shift is that Windows security is becoming more policy-driven and more revocation-driven. It is not enough to ask whether a binary is installed and signed. Admins increasingly need to ask whether the platform still considers it loadable under current policy.
That is a healthier security posture, but it is not frictionless. Every policy-based security gain creates a documentation and testing burden. Microsoft can block known-bad drivers, but customers still have to map that enforcement to real business processes.
Compatibility Debt Now Has a Kernel Interest Rate
The psmounterex.sys case is a textbook example of compatibility debt accruing interest. A vulnerable driver is disclosed. The vendor patches. Some customers update. Others do not, because the old version still works. Then, years later, the platform refuses to keep pretending that “still works” is the same as “still safe.”That timeline will feel unfair to users who never heard of the CVE and never thought of their backup tool as an attack surface. But from Microsoft’s perspective, the delay is already the compromise. The company did not block everything the day the vulnerability became public; it allowed time for vendor updates and ecosystem movement.
At some point, however, compatibility becomes complicity. If Microsoft continues to allow known vulnerable kernel drivers to load forever, it preserves legacy workflows by subsidizing attacker opportunity. If it blocks them, it breaks some workflows while reducing a class of abuse.
There is no painless answer here. Windows remains valuable precisely because it runs decades of hardware and software, and that long tail is part of the platform’s economic strength. But the long tail is also where vulnerable drivers go to become undead infrastructure.
The April 2026 update is a reminder that the kernel is not a museum. Old code does not earn permanent residency because it once solved a practical problem.
Where IT Should Look Before the Next Restore Test Fails
The first administrative task is to separate backup creation from backup usability. A scheduled image that completes successfully is not enough. The restore path must be tested after the April 2026 Windows security updates are installed, especially on machines that rely on image mounting as a virtual drive.The second task is to look for Code Integrity evidence. If Event Viewer reports that psmounterex.sys was blocked from loading, the failure is not a generic VSS issue. It is a direct consequence of Windows enforcing the vulnerable driver blocklist.
The third task is vendor alignment. Backup software should be updated to a release that no longer depends on a vulnerable version of the driver. If the vendor cannot clearly state whether a given version is affected, that uncertainty should be treated as a risk in its own right.
The fourth task is policy discipline. Organizations that use App Control for Business, HVCI, Smart App Control, or other hardening features need a way to stage and audit driver-policy changes before they collide with business-critical tooling. That does not mean avoiding enforcement. It means treating kernel-driver trust as a managed lifecycle.
The final task is communication. Help desks should know that April 2026-era failures involving mounted backup images may be caused by driver blocking. Otherwise, users will receive generic VSS troubleshooting advice that misses the new behavior entirely.
The April Patch Teaches a Narrow Lesson With a Wide Blast Radius
This incident is narrow in the sense that it names one driver and one class of backup workflow. It is wide in the sense that it previews the future of Windows compatibility. Known-vulnerable kernel components are going to have shorter lives, and the platform will increasingly enforce that reality whether or not every dependent application is ready.For enthusiasts, the lesson is to keep backup tools current and test actual restores, not just scheduled jobs. For sysadmins, the lesson is to inventory low-level software with the same seriousness applied to endpoint agents and VPN clients. For vendors, the lesson is that a signed driver is no longer a permanent passport into the Windows kernel.
This is also a cultural change. Windows users have long treated driver breakage as evidence that Microsoft has overreached. Sometimes that criticism is deserved. But in a world where attackers routinely abuse legitimate drivers, “it used to load” is not a security argument.
Microsoft’s decision will inconvenience some users. It may also prevent some compromised machines from turning a stale backup driver into a kernel foothold. The industry should be mature enough to hold both facts at once.
The Recovery Checklist Now Starts With Driver Trust
Before treating this as another Patch Tuesday oddity, organizations should translate it into a few concrete habits. The details are specific to psmounterex.sys, but the operating principle will recur.- Test image mounting, file browsing, and restore workflows after installing the April 14, 2026 or later Windows security updates.
- Check Code Integrity logs when backup software reports VSS timeouts,
VSS_E_BAD_STATE, or unexplained image-mount failures. - Update affected backup applications rather than weakening Windows driver-blocking protections to preserve old behavior.
- Inventory third-party kernel drivers used by backup, storage, security, VPN, and hardware-management tools across managed fleets.
- Treat a successful backup job as incomplete evidence until the restore path has been tested on a fully patched system.
Source: Microsoft Support April 2026 Windows security updates introduce protections to known vulnerable kernel drivers - Microsoft Support