Windows Protected Print: The Driverless Future, and What Stops Working the Day You Enable It

Someone on your team reads that Windows can now print without third-party drivers. It sounds like an unambiguous win. Two decades of print spooler vulnerabilities, gone, because the spooler stops loading vendor code entirely. So they enable Windows protected print mode on a pilot ring, and the pilot ring stops printing.

Not all of it. The queues pointing at the new Mopria certified multifunction devices are fine. The finance team's cheque printer is gone. The label printers in the warehouse are gone. The pull-print client that everyone badges against is gone, because it installed itself as a print monitor DLL, and Windows protected print mode does not load print monitor DLLs any more.

This post is about what Windows protected print mode actually is, in plain English, and how to size that blast radius on your own fleet before you commit to it.

The problem: the queues that disappear the day you enable it

Start with the vocabulary, because three names get used interchangeably and they are not the same thing.

IPP is the Internet Printing Protocol. Microsoft describes it as an HTTP-based protocol where each request is an HTTP POST and printers are addressed by URI, for example ipps://printer.example.com/ipp/print. It is a standard, not a Microsoft feature.

Mopria is the alliance of printer manufacturers and software vendors that defines the standards for IPP printing and eSCL scanning. A Mopria certified device is guaranteed to conform. That certification is the practical test of whether a printer works without a driver.

Windows Ready Print is Microsoft's name for Windows' preferred way of talking to printers. It covers IPP, eSCL scanning and Universal Print. It does not require installing third-party drivers.

Windows protected print mode, WPP for short, is the switch. Microsoft's documentation is precise about what it does: it "exclusively uses Windows Ready Print". Exclusively is the operative word. Nothing else gets to print.

So the failure mode is not subtle. Microsoft states plainly that upon enabling WPP, "printers that use third-party drivers are uninstalled". It goes further. The driver is deleted from the print driver store, and it cannot be used while WPP is active.

Here is the honest list of what stops working, taken from Microsoft's own pages rather than from guesswork.

Why it happens: what WPP actually changes in the print stack

To understand why the change is this blunt, you need the chain that a print job travels today.

An application calls the Windows print APIs. Those APIs hand the job to the Print Spooler service, Spooler, running as C:\Windows\System32\spoolsv.exe. The spooler loads the printer's driver. It calls a print processor, then a language monitor, then a port monitor, to get bytes onto the wire. Most jobs pass through an XPS conversion handled by printfilterpipelinesvc.exe.

Every one of those steps is an opportunity to load somebody else's code into a highly privileged process. Microsoft's own framing of the problem is blunt: print bugs "accounted for 9% of all cases reported to the Microsoft Security Response Center (MSRC) over the past three years", and the spooler "runs as SYSTEM, which is one of the highest privilege levels in Windows".

The design that follows from that is to stop loading the third-party code, and then, because there is no third-party code left to break, tighten everything else. Microsoft documents four changes.

A different spooler process. "When users enable Windows protected print mode, normal spooler operations are deferred to a new Spooler process that implements the Windows protected print mode improvements." So the service name does not change. The process handling your jobs does.

Lower privileges. The new Spooler Worker process runs with "a new restricted token that removes many privileges such as SeTcbPrivilege, SeAssignPrimaryTokenPrivilege, and no longer runs at SYSTEM IL". IL is integrity level.

Per-user XPS rendering. XPS conversion moves out of SYSTEM. Microsoft names the process, PrintFilterPipelineSVC, as "the source of many memory corruption vulnerabilities", and states that running it as the user minimises the impact of those bugs.

Binary mitigations that were previously impossible. Because no third-party binary is in the process, Microsoft can switch on exploit mitigations that only work if every loaded module cooperates. The documented list is Control Flow Guard and Control Flow Enforcement Technology, child process creation disabled, Redirection Guard, and Arbitrary Code Guard.

That last point is the real answer to "why not just harden the old stack". These protections are, in Microsoft's words, "often all or nothing", and decades-old print drivers are not compatible with them. You cannot enable Arbitrary Code Guard in a process that is about to load a driver from 2009.

Two claims are worth quoting exactly, because they are the business case. WPP "prevents the installation of third-party drivers and enables additional security features", and it "mitigates over half of past reported security issues for Windows print". Over half. Not all. That honesty is useful when someone asks whether this ends print vulnerabilities forever.

How to verify: read every surface before you commit

Before any of the configuration, work out what you have. The order matters: state first, then inventory, then the surrounding surfaces.

The documented way to ask whether WPP is on

Microsoft ships an API whose entire job is answering this question. It is Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo, described in the documentation as providing "an API for querying whether Windows protected print mode is enabled on the current device". It has one property, IsProtectedPrintEnabled, and the documented requirement is Windows 11, version 24H2, introduced in 10.0.26100.0.

You can call it from Windows PowerShell. The command below resolves the WinRT type and reads the property. A return of False means WPP is off on this device right now, and True means it is on.

Registry: the policy tree and the print stack

Two parent keys matter. The first is the Printers policy tree, which is where Group Policy and the Printers CSP write. The parent key is stated once here, so the table stays readable.

This is what the managed state looks like in Registry Editor on a device where the policy has landed. The value name is long, so the panel wraps it rather than clipping it.

The second parent key is the live print stack itself. This is where you read what is actually installed, rather than what policy asked for.

PowerShell: the inventory that actually answers the question

Three inbox cmdlets do the work. Get-Printer lists queues, Get-PrinterDriver lists drivers with their major version, and Get-PrinterProperty reads per-queue properties. Joining the first two on driver name is what turns a list into a verdict.

System files and DLLs: what is in the flow

Naming the binaries makes the chain concrete. Every path below is under C:\Windows\System32 unless stated.

Event Viewer: honest about what exists

Microsoft does not publish a set of event IDs specific to Windows protected print mode. Saying so is more useful than inventing some. What does exist is the standard print channel set, and several of those IDs are exactly the evidence you want when WPP removes a queue or blocks a module.

The channel is stated once above. The IDs below were read from the provider manifest on a Windows 11 build 26200 device with Get-WinEvent -ListProvider Microsoft-Windows-PrintService, so you can reproduce the list yourself rather than trusting this table.

Log files, services and scheduled tasks

There is no dedicated WPP text log. The driver activity, however, lands in the standard device install log, which is genuinely useful here because WPP's most disruptive action is a driver removal.

Services are simpler than people expect. The service name does not change under WPP. On a current build the Print Spooler is configured as below, and the two supporting services are demand-start.

Three scheduled tasks live under the printing path. None of them enable or disable WPP, but they are worth knowing about when you are explaining why a queue reappeared.

Does Microsoft ship a readiness tool?

No. This is worth being direct about, because it is the gap this post exists to fill. Microsoft's documented readiness guidance is manual and per-device: open Settings, look at each installed printer for the compatibility shield icon, and check the Mopria certified products list for anything with a scanner. There is no documented fleet inventory report, no Intune report, and no supported cmdlet that returns "this device is ready".

That is what the companion script does. It reads WPP state from both documented surfaces, joins every queue to its driver, classifies each driver as inbox-driverless, inbox-virtual, v3 or v4, flags every non-Microsoft print monitor DLL, and prints a blast-radius count. It never enables WPP and never removes a driver.

The fix: enable it deliberately, in waves

There are three ways to turn WPP on, and they are not equivalent. Settings is per-device and user-reversible. Group Policy and the Printers CSP are managed and, importantly, take the local off switch away.

Group Policy: the exact path

The setting lives in the Printers node of Administrative Templates, backed by Printing.admx. The steps below are Microsoft's own, expanded so nothing is assumed.

1. Press Start and open the Local Group Policy Editor, or open your domain Group Policy Management Console and edit the GPO you want to carry this.
2. Expand Computer Configuration.
3. Expand Administrative Templates.
4. Select Printers.
5. Right click Configure Windows protected print and choose Edit.
6. Select the Enabled radio button.
7. Click Apply, then OK.
8. Confirm the result on a target device by reading IsProtectedPrintEnabled with the PowerShell shown earlier. Do not confirm it by looking only at the registry, because the policy value encoding is not documented.

Intune: the CSP node, and the Settings Catalog equivalent

Microsoft documents the Intune configuration as a custom OMA-URI. The node is device-scoped, ADMX-backed, and documented as Windows 11, version 24H2 [10.0.26100] and later on Pro, Enterprise, Education and IoT Enterprise.

1. Sign in to the Microsoft Intune admin center at intune.microsoft.com.
2. Go to Devices, then Configuration.
3. Click Create, then New policy.
4. Set Platform to Windows 10 and later.
5. Set Profile type to Templates, choose Custom, then click Create.
6. Give the profile a name, for example Windows protected print - ring 1, then click Next.
7. On Configuration settings, click Add.
8. Set OMA-URI to ./Device/Vendor/MSFT/Policy/Config/Printers/ConfigureWindowsProtectedPrint.
9. Set Data type to String.
10. Set Value to <enabled/>, exactly as written, angle brackets included.
11. Click Save, then Next.
12. Assign the profile to your pilot group only. Not to All Devices. Review and create.

The Settings Catalog is the other route. Because this is an ADMX-backed policy from Printing.admx, it also appears in the catalog's Administrative Templates category under Printers, with the same friendly name, Configure Windows protected print. Microsoft's WPP documentation only publishes the custom OMA-URI, so if your tenant shows both, prefer whichever your organisation already standardises on and do not deploy both at once.

Settings: the per-device path, and the reversibility reality

End users and single-device testing use Settings. The path and the wording are documented.

1. Open Settings and go to Bluetooth & devices, then Printers & scanners.
2. Check each installed printer for the WPP compatibility icon.
3. For any device with a scanner, confirm it on the Mopria certified products list. If it is not certified, only printing will be available.
4. Scroll to Printer preferences and under Windows protected print mode select Set up.
5. Select Yes, continue for the prompts. The dialog identifies printers that need reinstalling.
6. Reinstall any compatible printers that were removed.
7. To reverse it later, return to the same place and select Turn Off, then Yes.

Defender and security policy: what actually applies

Be careful here, because it is easy to overclaim. Windows protected print mode is not a Microsoft Defender feature and it is not an Endpoint Security profile. It is an ADMX-backed Printers policy. There is no Defender Antivirus setting, no attack surface reduction rule and no App Control policy that turns it on.

Two genuine adjacencies exist. First, WPP applies exploit mitigations itself, and those mitigations are the same primitives you know from Exploit Protection: Control Flow Guard, CET, Arbitrary Code Guard, child process creation blocking and Redirection Guard. You do not configure them per-process for the spooler. WPP switches them on because there is no third-party binary left to break them. Second, Microsoft Defender for Endpoint device control includes printer protection, which restricts which printers a user may print to. That is a different control answering a different question. It governs destinations, not which drivers the spooler will load. Deploying one does not give you the other.

A migration order that does not create an outage

1. Run the readiness inventory across the fleet and aggregate the JSON. You are looking for the count of at-risk queues per device, and the distinct list of vendor drivers and print monitors.
2. Take the distinct printer models from that list and check each against the Mopria certified products list. Confirm IPP is enabled on the device itself, because Microsoft's guidance is explicit: "To use Windows protected print mode, ensure printers have IPP enabled."
3. For every vendor feature someone depends on, such as secure release, stapling or account codes, ask the vendor whether they ship a Print Support App. That is Microsoft's documented replacement path.
4. Reinstall pilot printers on the inbox IPP class driver while WPP is still off. This decouples "does driverless printing work here" from "does WPP break something else".
5. Only then enable WPP on the pilot ring, with the PrintService Operational channel already turned on.
6. Compare event 301 counts against your at-risk list. If a queue disappeared that your inventory said was ready, your inventory logic has a gap. Fix it before ring two.

Proof it worked: a real readiness run

The output below is a genuine run of the companion script on a Windows 11 build 26200 device, not an illustration. Device and print server identifiers have been replaced with redaction markers. Everything else, including the vendor names and the driver versions, is as it came out.

Read that output as a decision, not a report. Four of seven queues on one ordinary laptop would vanish. Six third-party v3 drivers would be deleted from the driver store. One vendor language monitor DLL, the pull-print hook, stops loading. Multiply that by a fleet and you have the change-advisory conversation you need to have before, not after.

The same script run under PowerShell 7 on the same device returns WPP=unknown rather than WPP=disabled, because the WinRT type does not resolve there. That is the honest answer, and it is the whole reason the script separates "read failed" from "read returned false".

References

• Windows protected print mode - Microsoft Learn. The setup and turn-off steps, what happens on enablement, XPS and fax reinstall, OneNote behaviour.
• Windows protected print mode for enterprises - Microsoft Learn. Group Policy steps, the Intune OMA-URI, and the Print Management restriction against non-WPP servers.
• More information on Windows protected print mode for enterprises and developers - Microsoft Learn. The spooler changes, module blocking, per-user XPS rendering, restricted token and binary mitigations.
• Windows Ready Print and Windows protected print mode - Microsoft Learn. What Windows Ready Print, Mopria and Print Support Apps are.
• Windows protected print mode FAQ - Microsoft Learn. Reversibility, scanners, Mopria printers installed with vendor drivers, and the statement that WPP will be enabled by default at a future date.
• Printers Policy CSP - Microsoft Learn. The ConfigureWindowsProtectedPrint node, its ADMX mapping to the WPP key and WindowsProtectedPrintGroupPolicyState value, and the supported OS.
• WindowsProtectedPrintInfo class - Microsoft Learn. The documented API for querying WPP state, and its 10.0.26100 requirement.
• End of servicing plan for third-party printer drivers on Windows - Microsoft Learn. The January 2026, July 2026 and July 2027 dates.
• What's new in Windows 11, version 24H2 for IT pros - Microsoft Learn. Where WPP is listed as a 24H2 feature, with the Settings and Group Policy paths.
• Device control in Microsoft Defender for Endpoint - Microsoft Learn. The printer protection capability, which is a separate control from WPP.
• Event ID 307 does not show the printed document name in Windows - Microsoft Support. Why job names are generic, and the policy that changes it.

Community deep-dives, each fetched and confirmed on topic

The sibling post on this site covers Point and Print driver-install hardening after PrintNightmare, including RestrictDriverInstallationToAdministrators and the Point and Print Restrictions settings. That is the interim control for fleets that cannot move to WPP yet. This post is about the destination.