Microsoft Rebuilt Print Management. That Is Not What Will Break Your Wristband Printers.

A modernized Print Management console showed up in Windows 11 Release Preview builds this month, and the consumer tech press has been covering it as a design story. It is a design story. Microsoft is rewriting a twenty-year-old MMC snap-in in WinUI 3, the same treatment it has given the Run dialog, File Explorer properties, and the file copy dialog. That is genuinely all it is.

The reason health care IT should care has nothing to do with the console and everything to do with what the console now manages. Three separate Microsoft print programs are converging in 2026, and one of them will eventually delete printer drivers off machines that are running clinical workflows. The new app is a convenient reminder to go find out which of your queues would survive that.

What actually shipped, and what did not

Print Management has been an MMC snap-in for years. On Windows 11 Pro, Enterprise, and Education it is an optional feature, not present by default, and not available on Home. You install it through Settings under Optional features or with a single DISM command:

DISM /Online /Add-Capability /CapabilityName:Print.Management.Console~~~~0.0.1.0

The new version is a packaged Windows app that appears as a top-level entry in All apps rather than under Windows Tools. It sits next to the snap-in. Testers report it does not auto-elevate, so you right-click and run as administrator. Windows Latest, which found it first in Beta and Experimental Insider builds in early August, confirmed it present in Release Preview builds 26100.9267 and 26200.9267 on August 14 as KB5120998, covering both 24H2 and 25H2.

Here is the part that matters for planning: Microsoft's own release notes for KB5120998 do not mention Print Management anywhere. No announcement, no documentation, no statement that the snap-in is going away. Release Preview is usually the last stop before general availability, and the September 8 Patch Tuesday cumulative is the obvious landing spot, but Microsoft can hold a preview feature back indefinitely and has done so before.

The practical guidance is boring and correct. Keep printmanagement.msc in your runbooks. Do not rewrite documentation, retrain staff, or build change tickets around a console that Microsoft has not publicly described. If the new app does ship broadly, test elevation behavior and printer migration export against your actual print servers before you trust it with a queue move.

Functionally, the testers who have used it describe the same administrative surface reorganized: a sidebar with All Printers, All Drivers, Printers Not Ready, and Printers with Jobs, a Print Servers node that still expands to Drivers, Forms, Ports, and Printers, a modern column picker, and restyled Rename Printer and Driver Properties dialogs. Some windows are still classic Win32. It is not Settings > Printers & scanners wearing a new coat. It is still a server and driver tool.

The three programs people keep conflating

Mixing these up produces bad change tickets, so it is worth being precise about which is which.

Windows Ready Print (WRP) is Microsoft's current name for the modern print platform, previously called the Modern Print Platform. It covers IPP printing, eSCL scanning, and Universal Print, and it uses the Windows inbox IPP class driver instead of vendor drivers. As of July 1, 2026, new printer installations on eligible Windows 11 and Windows Server 2025 devices default to Ready Print where the device supports it. Existing queues are not rewritten. Users and admins can turn the default off under Bluetooth & devices > Printers & scanners > Printer preferences, or through the Configure Windows Ready Print driver ranking policy under Computer Configuration > Administrative Templates > Printers. Worth knowing before you write the procedure: Microsoft's own announcement notes that once Windows protected print mode is enabled, you cannot disable the Default install printers using Windows Ready Print setting.

Windows Protected Print Mode (WPP) is the enforcement layer built on top of Ready Print. It blocks third-party driver installation entirely and uninstalls printers that depend on those drivers. It is off by default today. Enable it through Settings, through Computer Configuration > Administrative Templates > Printers > Configure Windows protected print, or through Intune with the OMA-URI ./Device/Vendor/MSFT/Policy/Config/Printers/ConfigureWindowsProtectedPrint set to <enabled/>.

End of servicing for legacy v3 and v4 printer drivers is a distribution policy, not a functional removal. Microsoft's published timeline for Windows 11 and Windows Server 2025 and later is three dated milestones: January 15, 2026, no new third-party printer drivers published to Windows Update, with updates to existing packages approved case by case; July 1, 2026, driver ranking modified to always prefer the Windows IPP inbox class driver; July 1, 2027, third-party driver updates limited to security-related fixes. Microsoft states directly that there are no plans to disable print features tied to the legacy driver platform, and that security fixes for that platform continue while the OS version is in support. Legacy drivers are being starved of Windows Update distribution and ranked behind IPP. Nobody's printer stops working on a Tuesday because of this.

WPP is the one that deletes things. And Microsoft has said, in its own FAQ, that Windows protected print mode will be enabled by default at a future date. No date is published. HP's technical documentation for its universal print drivers reads Microsoft's intent as flipping that default in 2027, while noting that how it gets implemented is undefined. Do not let that collapse into the July 1, 2027 milestone above; that date is Microsoft's published driver-servicing change, not a ship date for WPP-on-by-default. Treat HP's version as a vendor read on an unpublished schedule rather than a commitment, and treat the direction as settled either way. That is your planning window.

What WPP actually does to a print environment

Microsoft's justification is not soft. Print bugs accounted for 9 percent of all Windows cases reported to the Microsoft Security Response Center over the three-year window MORSE analyzed when the feature was announced, and Microsoft's assessment is that WPP mitigates over half of the print vulnerabilities in that set. The spooler runs as SYSTEM, is reachable by standard users, and loads third-party code on demand. PrintNightmare was not an accident of one bad patch. It was a structural consequence of that design.

So WPP is a defensible security control. It is also a destructive one, and the Microsoft FAQ is unusually blunt about the failure modes:

Non-compatible printers are uninstalled when WPP is enabled and cannot be reinstalled while it stays on. If you turn WPP back off, those printers do not come back on their own. You reinstall them manually. Removed drivers do not restore themselves.

Mopria certification is not a guarantee. Some Mopria certified printers get installed by default using third-party drivers, and those printers are removed when WPP is enabled. They can be reinstalled after the fact, but the queue breaks first.

Scanners are a separate compatibility question from printers on the same chassis. Microsoft's FAQ addresses "I enabled Windows protected print mode and now I can't see my scanner" directly, and the answer is that not all scanners are compatible. Print can stay up while scan goes dark on the same MFP.

And then there is the one that will catch somebody: when a client has WPP enabled, it cannot use Print Management to manage servers that have WPP disabled. That is Microsoft's documented behavior, not a bug report. Flip WPP on a jump box or admin workstation that manages hospital print servers and you have just locked yourself out of your own print infrastructure until the servers match.

Why this lands harder in health care

Clinical print is not the default printer in Settings. A 25-bed Critical Access Hospital with two attached rural health clinics is running something closer to this: a Windows print server publishing department queues, one or two large MFPs in HIM and registration with badge release and department codes that live in the vendor driver or a Print Support App, wristband printers at admitting, specimen label printers in lab, a prescription printer in the clinic, EHR thick clients or session hosts mapping printers into clinical sessions, and at least one USB-attached specialty device at a desk that never made it onto the print server.

Ready Print and WPP are built around Mopria-certified IPP devices. That covers most office MFPs manufactured in the last several years. It does not automatically cover a Zebra wristband printer on a med-surg unit, a thermal label printer in lab, or a legacy card printer at registration. If someone enables WPP on a clinical workstation or a session host without an inventory, working queues and their drivers disappear in one motion, and turning the policy back off does not undo it.

Print Management remains useful in that world for exactly the tasks it always did. Find Printers with Jobs after an EHR batch stacks up. Check which driver version a floor MFP is actually running. Export queues before a print server move. A WinUI shell does not change any of that. A WPP policy mismatch between the admin PC and the print server does.

The other print problem this month

Worth separating from all of the above, because the tickets will arrive at the same time. Microsoft has confirmed that after installing the August 2026 .NET Framework cumulative updates, some WPF applications fail with a System.IO.FileFormatException when printing or generating PDF or XPS content using certain fonts, including Calibri. This is not one KB. It is the August family, including KB5120708, KB5120705, and KB5120710 along with the SKU-matched packages, and it affects Windows 10, Windows 11, and Windows Server from 2012 through 2025. The issue has been isolated to the WPF TrueType font-subsetting path.

Microsoft's known-issue text does not name specific applications. Field reports do, and they point at WPF-based line-of-business software including some products that embed SAP Crystal Reports, which shows up in a great many health care billing and clinical reporting stacks. Treat that as a place to look first, not as a published compatibility list.

This has nothing to do with the print spooler, printer drivers, or Print Management. The application works fine until a user prints a report or exports a PDF, then fails. Microsoft's documented workaround is an AppContext switch in the affected application's config file, and Microsoft states plainly that the switch disables protections introduced in that same update. KB5120708 carries six .NET security fixes including three remote code execution CVEs, so uninstalling the update to fix printing is a worse trade than scoping the AppContext switch to the one application that needs it. A permanent fix is still pending.

If your clinical desktop apps started failing on print or PDF export after August 11, that is where to look. Do not go pulling printer drivers because a WinUI screenshot circulated on a forum.

What the Security Rule actually requires here

HIPAA does not name Print Management, IPP, or Windows Protected Print Mode. It requires a risk-based security program, and print falls inside it because ePHI moves through the spooler and across the wire, and because output is PHI the moment it hits the tray.

Changing print architecture is an operational change, and that has a specific hook. 45 CFR 164.308(a)(1)(ii)(A) makes risk analysis a Required implementation specification: an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Risk management at 164.308(a)(1)(ii)(B) is also Required. The Evaluation standard at 164.308(a)(8) calls for periodic technical and nontechnical evaluation in response to environmental or operational changes affecting the security of ePHI. Enabling WPP, changing driver ranking defaults, or migrating queues off vendor drivers is that kind of change. Write the analysis before the policy ships, not after the labels stop printing.

Access control at 45 CFR 164.312(a)(1) requires technical policies and procedures that allow access only to persons or software programs granted rights under 164.308(a)(4). Unique user identification at 164.312(a)(2)(i) is Required. Person or entity authentication at 164.312(d) is a standard with no implementation specifications, which means it is simply mandatory under 164.306(c). A shared department printer with no release control does not meet that model the moment a face sheet lands in the output tray with nobody standing there.

Audit controls at 164.312(b) is likewise a standard rather than an addressable specification. There is no alternative-measures option: implement hardware, software, or procedural mechanisms that record and examine activity in information systems containing or using ePHI. If Ready Print or a Print Support App drops the job accounting, user code, or badge release metadata your current stack logs, that is a control gap, not a cosmetic driver change. Find out what you are logging today before you change the path.

Transmission security at 164.312(e)(1) requires technical measures guarding against unauthorized access to ePHI transmitted over a network. Encryption at 164.312(e)(2)(ii) is Addressable, and Addressable does not mean optional. It means you assess whether the specification is reasonable and appropriate, implement it if so, and if not, document why and implement an equivalent alternative where reasonable. IPP over TLS is the obvious control for network print. A raw TCP 9100 queue carrying discharge summaries is the thing you have to justify in writing, not the default you get to keep because it has always been there.

One caveat on that word Addressable. HHS published a Notice of Proposed Rulemaking on January 6, 2025 that would remove the Required and Addressable distinction entirely and make nearly all implementation specifications Required, with limited exceptions. That proposal is not final. The comment period closed in March 2025, OCR is still working through roughly 4,700 comments, the spring 2026 target for a final rule came and went, and HHS states on its own fact sheet that the current Security Rule remains in effect during the rulemaking. Nothing there changes what you owe today. It does change how much weight to put on a documented alternative to encrypted print traffic as a long-term position, because if the rule finalizes as proposed, the documentation pathway that currently justifies an unencrypted clinical queue is gone.

Physical safeguards get overlooked in print conversations and should not be. Facility access controls at 45 CFR 164.310(a)(1), workstation use at 164.310(b), and workstation security at 164.310(c) are all standards, all mandatory. Whether a networked MFP itself meets the 164.304 definition of a workstation is a judgment call your compliance officer gets to make, since the definition covers a computing device or any other device performing similar functions along with electronic media in its immediate environment. The workstation that submits the job is unambiguously in scope either way, and so are the physical surroundings of the device that produces the output. A modernized Print Management UI does nothing for 164.310(c). Badge release, PIN hold, or a locked utility room does.

One more that applies directly if an IPP-first refresh means new hardware. Device and media controls at 164.310(d)(1) carry two Required specifications: Disposal at 164.310(d)(2)(i) and Media re-use at 164.310(d)(2)(ii). Multi-function devices have storage. If you are trading in, leasing back, or reassigning MFPs as part of a Ready Print migration, removing ePHI from that storage before the device leaves is not optional and not addressable. It is Required, and it is the single most likely place for a print modernization project to create a reportable breach.

None of those sections require Windows Protected Print Mode. WPP can reduce spooler attack surface, which is a reasonable risk treatment under 164.308(a)(1). It can also take down specimen labels, and the Security Rule does not hand out credit for a control that breaks clinical output.

Inventory first

Everything above reduces to one prerequisite. You cannot make a defensible decision about Ready Print or WPP without knowing which queues depend on vendor drivers. If you have a Windows print server, that inventory is a short script, and the PrintManagement PowerShell module is already on the box.

Function Get-PrintDriverInventory ($ServerList, $OutputPath) {

    $Results = New-Object System.Collections.Generic.List[PSObject]

    foreach ($Server in $ServerList) {

        Write-Host "Collecting print queues from $($Server)"

        try {
            $Printers = Get-Printer -ComputerName $Server -ErrorAction Stop
        }
        catch {
            Write-Warning "Unable to query $($Server): $($_.Exception.Message)"
            continue
        }

        foreach ($Printer in $Printers) {

            $Driver = Get-PrinterDriver -ComputerName $Server -Name $Printer.DriverName -ErrorAction SilentlyContinue

            if ($null -eq $Driver) {
                $Platform = "Driver not found"
            }
            else {
                switch ($Driver.MajorVersion) {
                    3       { $Platform = "v3 legacy" }
                    4       { $Platform = "v4 legacy" }
                    default { $Platform = "Other" }
                }
            }

            if ($Printer.DriverName -like "*IPP Class Driver*") {
                $ReadyPrint = "Yes"
            }
            else {
                $ReadyPrint = "No"
            }

            $Row = [PSCustomObject]@{
                Server     = $Server
                Queue      = $Printer.Name
                Driver     = $Printer.DriverName
                Platform   = $Platform
                InboxIPP   = $ReadyPrint
                PortName   = $Printer.PortName
                Shared     = $Printer.Shared
                Location   = $Printer.Location
            }

            $Results.Add($Row)
        }
    }

    $Results | Export-Csv -Path $OutputPath -NoTypeInformation
    Write-Host "Wrote $($Results.Count) rows to $($OutputPath)"
}

Get-PrintDriverInventory -ServerList @("PRINT01","PRINT02") -OutputPath "C:\Temp\PrintInventory.csv"

That gets you the print servers. It does not get you the USB-attached label printer in the lab or the wristband printer nobody documented, so run it against clinical workstations and session hosts too, or accept that the gaps in your inventory are the devices most likely to break. Treat the output as a starting inventory rather than a driver classifier: driver name matching between the queue and the driver store is not always clean, and inbox IPP does not always announce itself with the string the script looks for. Anything the script cannot place is a row to go look at, not a row to ignore.

Then work through the list by function rather than by brand. Mark every queue that prints ePHI. Mark every specialty device: wristband, specimen label, prescription, card, charge slip. Check each model against Mopria's certified products list rather than assuming that a network printer equals a Ready Print printer.

From there the decisions get easier. Decide Ready Print defaults separately from WPP, because preferring IPP for new office MFPs is a different risk conversation than deleting third-party drivers off a nursing station. Do not enable WPP anywhere in the management path until clients and servers are on the same side of the policy. Reserve WPP for a tested ring, which for most rural organizations means a new clinic with certified hardware or a locked-down kiosk that prints to one known device, not the med-surg floor.

Review the print policies together while you are in there: Configure Windows protected print, Configure Windows Ready Print driver ranking, Point and Print restrictions, package point and print, and whether users can add printers at all. And make sure nobody applies a well-meaning security baseline that flips WPP domain-wide because the setting name sounds like it belongs in a HIPAA checklist.

The quieter version of that problem is doing nothing. Leaving Configure Windows protected print at Not Configured leaves the Settings toggle live on the endpoint, and HP's guidance for its universal print drivers notes that setting the policy to Disabled does not stop a workstation administrator from turning WPP on from Settings either. Anyone with local admin can delete managed queues from a Settings page in about four clicks, and they will not know that is what they did. If clinical staff or department leads carry local admin on your workstations, and in a lot of small organizations they do, decide that policy deliberately rather than by default.

Test the clinical exceptions before anything else. Wristband and specimen printers, EHR-initiated print jobs, secure release PIN and user code fields, and scan-to-EHR on the same MFP that prints fine. Microsoft's documentation is explicit that multi-function devices work over IPP with print and fax on IPP endpoints and scan through WS-Scan or eSCL, but "works over IPP" and "works the way your HIM department has it configured" are different claims.

Microsoft is modernizing a twenty-year-old admin console because it is rewriting Windows UI in WinUI 3. That is the whole story on the app. The useful thing to do with the attention it generated is write down what still prints in your organization, which of those jobs carry ePHI, and which of those devices survive an IPP-first world.

The console can look like Windows 11. The queue that prints discharge instructions still has to work Monday morning.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

• Microsoft Learn, Discover Windows Ready Print
• Microsoft Windows IT Pro Blog, Introducing Windows Ready Print and Modernized Driver Selection
• Microsoft Learn, Windows protected print mode for enterprises
• Microsoft Learn, Windows protected print mode FAQ
• Microsoft Learn, More information on Windows protected print mode for enterprises and developers
• Microsoft Learn, End of servicing plan for third-party printer drivers on Windows
• Microsoft Support, August 11, 2026 KB5120708 Cumulative Update for .NET Framework 3.5 and 4.8.1
• Microsoft Security Blog, A new, modern, and secure print experience from Windows
• Windows Latest, Microsoft just rebuilt one of Windows 11's oldest tools in modern UI
• BleepingComputer, Microsoft: August updates break printing, PDF export in WPF apps
• Mopria Alliance, Certified Products
• eCFR, 45 CFR Part 164, Subpart C, Security Standards
• Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM, January 6, 2025)
• HHS.gov, HIPAA Security Rule NPRM Fact Sheet