Microsoft is retiring third-party printer drivers. What that means for label printers

If your product prints shipping labels or receipts from Windows machines, the assumption that you can install a vendor driver on a customer's PC has an expiry date. Microsoft is steering Windows toward its own inbox IPP class driver, and Windows Protected Print mode does not merely discourage third-party drivers, it uninstalls them. Raw label languages like ZPL, EPL, and ESC/POS are not part of what the inbox driver promises, so that path needs testing now rather than during an incident.

Nothing has broken yet. The point of this post is what to test, on which machine, before it does.

What actually changed, and when

Date	Change	Reported by
Windows 11 24H2 and Server 2025	Windows Protected Print mode ships, off by default, enforceable by group policy	Microsoft
January 15, 2026	New third-party print drivers no longer published to Windows Update for Windows 11 and Server 2025 and later	PaperCut, MyQ
July 1, 2026	Windows prefers the inbox IPP class driver (Windows Ready Print) for new printer installs	ezeep
July 1, 2027	Third-party driver updates limited to security fixes	PaperCut

Two qualifications. Existing installed drivers keep working, and vendors can still ship installers outside Windows Update. The three dated rows come from print vendors' summaries of Microsoft's published plan, not from a Microsoft page we can link, so treat them as reported dates and confirm against Microsoft before you plan a migration around them. Only the first row is from Microsoft's own documentation.

Protected Print does not tolerate third-party drivers, it removes them

WPP is the aggressive part, and it is worth reading Microsoft's own description rather than a summary. When the mode is enabled on a machine, Windows:

• uninstalls printers that use third-party drivers,
• deletes those drivers from the driver store,
• blocks new third-party driver installations,
• prints only through Windows Ready Print, the built-in IPP class driver.

It is designed around Mopria certified printers. It is off by default today, and an administrator can turn it on for a fleet with group policy. That last clause is the one that should interest you: the decision may not be made by the team that owns your integration. A security or endpoint team consolidating on Microsoft's hardening guidance can enable this without anyone asking what your label printers speak.

Windows Ready Print covers documents, not your label language

IPP Everywhere and Mopria solved a real problem: a page of A4 or Letter, rendered to a raster the printer understands, with no vendor code on the client. For office document printing that is a strictly better world.

Label printing is a different shape. A ZPL label is not a rendered page, it is a small program:

^XA
^PW812
^LL1218
^MD10
^FO40,60^A0N,48,48^FDACME Fulfillment^FS
^FO40,140^BY3^BCN,120,Y,N,N^FD1Z999AA10123456784^FS
^XZ

The ^MD10 line sets print darkness. Nothing in the IPP document model has an opinion about darkness, ribbon burn, cutter behavior, peel-off sensors, or media calibration. Those are properties of the label language and the printer's firmware, addressed by sending bytes through a raw queue.

So the risk is specific and it is not "printing will break." It is that the raw queue for a thermal printer, which many vendors set up with their own driver package, may be the thing that becomes hard to install. Whether a given printer can be driven raw through an IPP class queue depends on the model and firmware. We are not going to tell you it works, and nobody should tell you it fails either. It is a per-model question, which is the whole argument for the pilot machine below.

Raw bytes are the portable layer, which is why they survive driver churn

The useful property of ZPL, EPL, and ESC/POS is that they are documented command sets that many vendors implement, and sending them requires no rendering intelligence on the host. That is why raw workflows have outlasted several generations of Windows driver policy: the host's only job is to hand an opaque byte stream to a queue.

The comparison with the document path is worth keeping in your head when you choose a format, and we laid it out in ZPL versus PDF for shipping labels. The short version is that a PDF label needs something to rasterize it, and that something is exactly the layer Microsoft is changing. A ZPL label needs a pipe.

Strategy one: keep the legacy drivers, and write down that you did

Perfectly legitimate, and the cheapest option for a single site you control. Existing drivers continue to work, and WPP stays off unless someone turns it on.

What makes this a strategy rather than an accident is documentation. Record which machines run vendor drivers, which printer models depend on them, that WPP must not be enabled on those machines, and who to talk to before an endpoint hardening project ships. An undocumented dependency on a driver that Microsoft is deprecating is how you discover this during a holiday shipping peak.

Strategy two: an IPP or generic queue with raw passthrough, where the printer supports it

Some label printers accept raw ZPL over an IPP or socket path, or work adequately through a generic or raw text queue. If yours does, you have removed the vendor driver from your dependency list.

Test it, do not assume it. Verify the full label, not a text line: barcode scan, darkness, label length, cutter or peeler behavior, and what happens on the first job after the printer sleeps.

Strategy three: give one host the raw path and put an API in front of it

The third option is to stop asking every machine to own printing. One host per site holds whatever local path works for its printers, and your application talks to that host over HTTP instead of to a driver.

This is the shape we build. RocketPrint is a remote printing API and desktop Station for software platforms: your backend POSTs a print job, and a small app beside the printer prints it, with no inbound networking, no drivers for raw label formats, and a durable job record. On Windows, Station sends raw jobs through a native Winspool helper and documents through a Chromium-based renderer; on macOS raw jobs use CUPS with the raw option. Printer ids stay stable across renames, which matters more than it sounds when someone reinstalls a queue.

Here is the boundary: that Winspool path is exactly the thing that has to keep working under WPP, and we have not tested it against every printer model with Protected Print enabled. If you are planning around this, our raw path is a candidate to test on your hardware, not a guarantee to cite. The same caveat applies to any vendor answering this question today.

A pilot-machine test plan you can run this week

One spare Windows 11 24H2 machine, one of each printer model you care about, half a day.

1. Baseline. Install the printers the way your customers do. Print a real label, a real receipt, and a document. Scan the barcodes with the scanner your operators use, not your phone.
2. Record the inventory. For each queue, note the driver in use and whether it is third-party. Get-PrinterDriver and Get-Printer | Select Name, DriverName, PortName in PowerShell give you the list to keep.
3. Turn WPP on. Enable Protected Print mode on the pilot machine only. Note which printers disappear.
4. Reinstall. Try to add each printer back with Windows Ready Print. Record which models are discoverable and which are not.
5. Print again, in full. Text is not a pass. Check barcode scannability, darkness, label length, cut or peel, and multi-copy jobs.
6. Test the raw path specifically. Send a raw ZPL byte stream through whatever queue survived and confirm the printer treats it as commands rather than printing the literal ^XA characters as text. That failure mode is the signature of a queue that is rendering rather than passing through.
7. Test recovery. Sleep the printer, unplug it, reconnect, and confirm queued work behaves the way your process assumes.
8. Write it down per model. The output of this exercise is a table of printer model against verified path, which is the artifact that makes the 2027 date boring for you.

If step 4 or step 6 fails for a model that matters, you have found the real decision: a different printer model, a host that owns the raw path, or a documented exception keeping WPP off those machines.

The honest summary

Windows document printing is getting better and less dependent on vendor code. Raw label printing sits outside that improvement, neither blessed nor broken, and the people who will have a calm 2027 are the ones with a per-model table produced on a pilot machine in 2026.

If you are moving off a per-desktop driver setup, migrating browser printing to a print API covers the application-side change, what "driverless" actually means covers the protocol underneath IPP, and printers and formats lists which content types we send down which path.

Dates and vendor summaries verified September 11, 2026.