Do label printers still work with Windows Protected Print? ZPL, EPL, and the Mopria question

Why industrial label printing Is one of the toughest challenges in the WPP ecosystem – and how to review

Do Zebra label printers still work with Windows Protected Print?

This single statement gives rise to two distinct consequences, which are regularly conflated in the discussion.

First, the driver. From Windows’ perspective, the ZDesigner driver from Zebra, the Honeywell driver, and the cab or SATO drivers are third-party drivers. When WPP is enabled, they are uninstalled and removed from the driver store. HP describes the effect unequivocally in its technical WPP white paper: „All v3 and v4 third party print drivers are prevented from installing onto Windows.”

Second, the reinstallation. That’s actually the hard part, and Microsoft is very clear on this: „Non-compatible printers are uninstalled and will be not able to be reinstalled while Windows protected print mode is enabled.” A label printer that Windows does not recognize as compatible cannot be reconfigured while WPP is active – not even with a different driver.

A clarification that is important for the rest of the discussion: Throughout the FAQ, Microsoft refers to “non-compatible printers,” not to “uncertified” devices. Nowhere is there any mention of a comparison against a list of certified devices. What matters is technical compatibility with the IPP Inbox driver; Mopria certification is Microsoft’s statement regarding which devices meet this compatibility requirement. HP describes the functional relationship as follows: „Failure to enable IPP Printing at the device will result in Windows seeing the device as a non-Mopria compliant device.”

This means the question “Does my Zebra printer still work?” is misguided. The printer works just as before. What has changed is the way Windows accesses it.

What happens to ZPL and EPL printing in WPP?

ZPL and EPL are not public standard PDLs. They are proprietary printer languages, and they are more than just a page format: A ZPL data stream contains coordinate instructions, field positions, font references, and – crucially – barcode commands, which the printer itself implements in module widths. The same applies to the related languages in this segment:

In practice, this means that whenever an application, a WMS, or SAP generates the ZPL stream itself and sends it via a Windows queue, the Windows driver was never responsible for rendering – it merely served as a conduit. It is precisely this conduit that WPP closes.

Are label printers Mopria-certified?

Current Membership List: August 13, 2026.

Against Alarmism: Membership is not a technical restriction, but rather a market signal. Any manufacturer is welcome to join, and the table is subject to change.

Against Procrastination: Simply joining the program is not enough. Mopria certification requires IPP-Everywhere compliance, and PWG Raster is mandatory for that. For a printer that has so far interpreted only proprietary printer languages, this is not a mere formality but requires an additional rendering chain in the firmware – in other words, development work that this class of devices has not needed until now. Anyone basing their planning on the assumption that the existing fleet will be certified in the future is planning based on an intention that, as of today (August 13, 2026), no manufacturer in this segment has publicly declared. Furthermore, between such a declaration and a certified existing fleet lie firmware and device lifecycles – which are typically significantly longer in label printing than in office printing.

A common misconception: My label printer supports IPP – does that mean it’s WPP-compatible?

Zebra Link OS printers support IPP . There is a documented device setting, `ip.ipp.mode`, with the values `ipp/ipps` and `ipps`. For printers purchased in the EMEA region after August 1, 2025, “ipps” is the default value – a date that coincides with the effective date of the cybersecurity requirements of the EU Radio Equipment Directive and is therefore not an indication of the maturity level of IPP implementation. It should be noted that IPP is not an unfamiliar concept in this segment.

Nevertheless, this does not imply WPP compatibility, because under WPP, three conditions must be met simultaneously:

The rule of thumb for fleet testing is therefore: IPP capability is a property of the transport path. WPP compatibility is a property of the entire path, including format and attributes. Anyone who checks only the data sheet for “IPP” will arrive at an overly optimistic conclusion.

What about the RAW path via a “Generic/Text-Only” queue?

The principle: the application generates the ZPL stream itself. On a Windows system, there is a queue using the Microsoft “Generic / Text Only” driver on a standard TCP/IP port, typically port 9100. Windows does not perform any rendering; it simply transmits the bytes. No manufacturer-specific driver is involved. The obvious conclusion – “WPP doesn’t apply to us” – should be viewed with caution for three reasons.

First, queue management. When WPP is active, the process of creating a queue changes completely. In a Microsoft Q&A thread specifically addressing this issue, the standard call specifying the port and driver fails; the only method that works is the one using the IPP address:

What is noteworthy here is that the failed call did not involve a third-party driver at all, but rather the IPP class driver itself: The driver was not the obstacle; rather, it was the approach involving the port and driver specifications. There is no corresponding report for the RAW variant with “Generic / Text Only” on a standard TCP/IP port – the application of this finding to that scenario is an inference, not a confirmed finding. It should also be noted that this is a community thread: The posts do not come from identifiable Microsoft employees, and the statement that the hardware must be Mopria-compliant and powered on is a community assessment, not product documentation.

Second, the Port Monitor. Microsoft explicitly identifies the port monitor as part of the attack surface that WPP is designed to close: “A common attack on Windows would abuse the fact that a printer port monitor can be a Dynamic Link Library (DLL), and attackers would abuse this to load malicious code.” The resulting announcement of enforcement is the key phrase: „We’ll also enforce a restriction that ensures that only Microsoft Signed binaries required for IPP are loaded.” A RAW port monitor is not required for IPP. Microsoft summarizes the effect as follows: “In Windows protected print mode, many legacy configurations are no longer valid.”

Third, the driver itself. “Generic / Text Only” is a Microsoft driver, but it is a v3 driver in the classic driver model – not the IPP inbox driver. Microsoft consistently specifies the uninstallation procedure for third-party drivers; the policy description states that only “a subset of Windows inbox print drivers” remains permitted. Whether “Generic / Text Only” belongs to this subset is not documented. This is an open question and should be added to the test list.

What is documented here and what is not – clearly distinguished: It has been confirmed that WPP is intended to limit the loading of binaries to what is required for IPP, that port monitors are a designated target, that legacy configurations become invalid, and that incompatible printers cannot be reinstalled while WPP is active. What is not documented is the fate of an existing generic/text-only queue on a standard TCP/IP port after WPP activation. This is precisely why it is a mandatory test item – it is listed at the bottom of the test report, and anyone using this path in a production environment should measure it rather than assume its behavior.

One approach remains unaffected by all of this: If the application generates the ZPL stream and sends it itself via a TCP socket to port 9100 or via LPD to the device – without using the Windows print queue – the driver model is irrelevant. This approach is viable – but it must be tested on a per-application basis, cannot be managed through Windows Print Management, and provides neither centralized redirection nor status feedback nor logging. It addresses individual processes, not the fleet.

Zebra PDF Direct – is that the solution?

With PDF Direct, Zebra offers a device emulation that processes PDF files directly on the printer instead of converting them to ZPL within the application. According to Zebra’s own announcement, the feature is included free of charge starting August 31, 2020, with Link-OS 6.3 and later – previously, it was a paid option. It applies to the model series listed there, not to the entire fleet. This means that condition 2 from the table above – the device supports a standard format – can be met for some of the devices.

What this does not solve:

The question of compatibility remains unresolved. PDF Direct does not make a device Mopria-certified and does not indicate whether the device publishes the attributes expected by the IPP Inbox driver. Condition 3 remains the limiting factor.

Responsibility for barcode generation is changing. This is the most technically significant point. A ZPL barcode command describes the code symbolically to the printer; the device converts it into module widths that match the print resolution – in whole dots at 203 dpi. If, on the other hand, the barcode is supplied as a graphic in a PDF or as a raster image, the rendering pipeline determines the module widths, and rounding between the rendering and print resolutions becomes possible. Whether this affects the evaluation according to ISO/IEC 15416 (linear symbols) or ISO/IEC 15415 (2D symbols) in a specific case cannot be determined – it can only be measured using a verifier. For labels subject to GS1 requirements or customer-mandated grading, this measurement is part of the acceptance process, not an optional additional test.

Layout checking is performed indirectly. Zebra itself points out that generic PDF renderers “significantly reduce” label quality and increase runtime. That is precisely why the emulation is built into the device. For an existing environment, however, this means that label generation must be switched to PDF – a change to the application itself, not just a configuration change.

PDF Direct is therefore a key component for new labeling processes, not a migration path for an established ZPL environment.

Is Universal Print sufficient for label printing?

• „Label printing is currently limited to printing PDF documents.” A RAW or ZPL path is not supported.
• „However, since the industry standards for label printing are still a work in progress, full-featured support for label printing is not yet possible in Universal Print.”
• „Scaling is not supported.” The scaling value always remains “None,” regardless of the client’s specifications.
• „When printing to a label printer from a Windows application, the print preview will not show the correct size and scale the label printer will produce.”

In addition, there is a requirement that inadvertently closes the loop. The documented label path requires the Universal Print Connector: „Verify that label printers are installed on a PC running Universal Print connector 1.92.8740 or later.” The connector runs on a Windows system, and the printers must be installed on that system – „the connector can connect printers installed on that machine to Universal Print.”

This means that Microsoft’s own labeling path starts with exactly what WPP removes: a Windows print queue for an incompatible device. Anyone who enables WPP on the connector host should check this relationship beforehand rather than afterward.

Which label printing paths are affected? The classification

Three lines in this table are worth noting.

Line 5 is the case that is most often misjudged. A native SAP label device type—such as one from the LZEB family for ZPL II or LB_CAB for cab-JScript – generates the finished data stream in the SAP spool. No Windows driver renders anything here. Nevertheless, the path is affected if the transfer takes place via a Windows host with a print queue: The problem is not the rendering, but the queue, which no longer exists for an incompatible device when WPP is active. The distinction between device type and connection type is therefore not a mere formality – it determines the outcome.

For consistency with our post “Does Windows Protected Print Affect SAP Printing?”: There, this scenario is rated as “not affected, with a queue restriction” because data stream generation remains driver-free. For label printers, this very restriction applies because the device is not compatible. The assessments do not contradict each other – they address different links in the same chain. In practice, the queue is the decisive link.

Line 7 is not transitive. Coupling type E decouples only the section between the SAP spool and the Output Management System. It does not, in and of itself, prove WPP independence, but rather shifts the question to the next level: What matters is how the OMS subsequently outputs the data.

Line 10 does not apply across the board. Whether an output layer prints without a driver is a matter of configuration, not product category. If it prints via Windows print queues, the same validation rule applies to this section as to any other Windows host. This applies to every product in this category, including our own.

How do I check our label print paths? A six-step verification process

1. Track label processes, not printers. Which processes generate labels? Typical examples include: goods receipt, putaway, order picking, shipping and freight labels, production orders and batch labeling, quality inspection and sample labels, maintenance, and asset and shelf labeling. For each process, the system that triggers the label is noted.

2. Determine the creating instance for each process. Does SAP generate the data stream using a device type? Does label software generate it using a manufacturer driver? Does a WMS or MES generate it using its own ZPL templates? Does a line-side application generate it? That is the question that distinguishes line 1 from line 2 in the classification.

3. Trace the transport route to the device. For each path: via which host, via which queue, via which port, using which driver. For SAP, also record the device type and the connection type from transaction SPAD – both, not just one of them. For connection type U, you must also specify whether the destination is the device itself or a Windows host; the connection type alone does not determine the case.

4. Inventory Windows systems in the data path. Packing station PCs, label servers, SAPSprint hosts, Universal Print Connector hosts, Citrix VDAs, line PCs. The following information is recorded: operating system version, installed label drivers, port configuration, and WPP status. This list also serves as the list of systems on which WPP activation takes effect.

5. Check on the device side to see what is actually available. For each model and firmware version: Is IPP enabled? Which address and which document formats are published? Is PDF Direct available? The attribute query via ipptool -tv ipp://<device>/ipp/print get-printer-attributes.test shows, under “document-format-supported,” what the device supports. Compare this in parallel with the Mopria list of certified products – the data sheet and certification status are not the same.

6. Prioritize over process criticality. The question isn’t “which device is affected,” but “which process has come to a standstill and how long can it keep going.” A shelf label printer and a shipping label printer appear to be equivalent in the device list. If the second one is down, the goods-out process comes to a standstill.

Test Report for the WPP Pilot Study

These points should be checked on a test system before WPP is enabled in a label-printing environment. All of them can be verified using built-in tools; the “Derivable from documentation” column indicates where the answer is already available and where actual measurements are required.

What deadlines apply – and what is already in effect today?

Both are true at the same time. There is no end date – and there is a path whose endpoint no longer involves third-party drivers.

What a device replacement resolves – and what it doesn’t

Two additional points should be considered in this context. Label printers have significantly longer lifecycles in warehouse and manufacturing environments than office equipment; a fleet that operates for ten years does not follow a three-year refresh cycle. And part of the lost functionality was never a feature of the printer to begin with, but rather one of the driver or the print queue: centralized rerouting in the event of a device malfunction, status feedback to the process, and logging for batch traceability.

The reliable sequence is therefore: first classify processes and data streams, then decide which part is a hardware issue and which is an architectural issue. The second category is not reduced by any procurement process.

The question behind the question: Where does the label data stream originate?

This issue does not affect any specific device category or manufacturer, but rather a responsibility &ndaash; the assumption that a Windows system is the location where a label job is converted into a device-ready data stream.

The key question for your own planning is therefore not “Are our label printers WPP-capable?”, but rather: Where is the label data stream generated – in a component whose driver model is determined by others, or in an output layer that the company itself controls? Whoever answers this question for label printing has also answered it for the plotter, the CAD sheet, and the SAP form.

Frequently Asked Questions

Will label printing be canceled on a specific date?

No. WPP is now optional and disabled by default. Microsoft has announced that it will be enabled by default at a “future date” without specifying a date, and on February 25, 2026, clarified that support for legacy drivers has not ended. Another date has been set: Starting July 1, 2027, updates for third-party drivers will be limited to security-related fixes.

We haven’t activated WPP. Are we sure?

For existing installations, the answer is yes – for now. However, keep in mind the second, more gradual phase: As of July 1, 2026, Windows will prioritize the IPP Inbox driver for newly added printers. The fact that existing installations remain unaffected stems from how the priority change works, but this is not explicitly documented – check if in doubt.

Can we just leave WPP disabled on the label workstations?

Yes, via Group Policy or Intune, and that makes sense as a temporary measure. However, it is not a long-term solution: The driver priority list will take effect even without WPP; starting in July 2027, only security updates will be available; and default activation has been announced. Any exception should be documented—including the rationale and a review date.

Our application generates ZPL on its own. So that means we’re not affected, right?

Only if the application delivers the data to the device itself. If it runs through a Windows queue, the path is affected – not because of the rendering, but because of the queue. This is row 2 of the classification table and the most common misconception on this topic.

Does this also apply to receipt printers, cash register printers, and labeling systems?

By the same logic, yes: ESC/POS, Star, and Bixolon command sets are not public standard PDLs. The fact that a manufacturer is a Mopria member – Epson, for example, as the creator of ESC/POS – says nothing about the certification of its receipt and point-of-sale printers. You should always check the model, not the manufacturer.

What about mobile label printers for handheld devices?

Printing from Android or iOS devices does not go through the Windows print stack and is not affected by WPP. This applies to scenarios where a Windows system acts as an intermediary between the application and the device.

Where can I find the SAP page for this topic?

Whether SAP print paths are affected depends on the combination of device type and connection type. The article Does Windows Protected Print Affect SAP Printing? contains the complete impact matrix, the SAPSprint analysis, and a testing procedure using transaction SPAD.

Context

The questions raised by Windows Protected Print in label printing – where the data stream originates, how a device-specific format reaches its device, and how output is rerouted and logged in the event of a device malfunction—are the very questions at the heart of output management. Whether a specific output path is affected is determined not by the product category, but by the integration method used. This applies to every platform, including ours – and it is the reason why we start with an assessment of the current situation rather than a product selection.

Sources

Microsoft Learn: Windows protected print mode FAQ

Microsoft Learn: More information on Windows protected print mode for enterprises and developers

Microsoft Learn: Windows Ready Print

Microsoft Learn: End of Servicing Plan for Third-Party Printer Drivers on Windows

Microsoft Learn: Printers Policy CSP – ConfigureWindowsProtectedPrint

Microsoft Learn: Universal Print limited support for label printing

Microsoft Learn: Universal Print connector overview

Microsoft Q&A: Add a local IPP printer queue programmatically or with PowerShell when Windows protected print mode is enabled – Community-Thread, keine Produktdokumentation und kein Microsoft-Statement

HP: Windows Protected Print – Technical Whitepaper

Mopria Alliance: Member Companies

Mopria Alliance: Member Benefits

Mopria Alliance: Certified Products

PWG: IPP Everywhere – Übersicht und Formatanforderungen

PWG 5100.14: IPP Everywhere v1.1

PWG 5100.20: IPP Everywhere Printer Self-Certification Manual v1.1

Zebra Technologies: ip.ipp.mode – SGD-Befehlsreferenz

Zebra Technologies: IPP/IPPS Configuration Guide for Link-OS Printers (P1140936-01EN)

Zebra Developer Portal: Printers Include Free PDF Direct with Link-OS 6.3

Zebra Technologies: PDF Direct – Virtual Device Support

Zebra Technologies: Solution Guide – Zebra Printers and SAP Smart Forms.  

Zebra Technologies: Device Type Used to Print to a Zebra Printer from SAP Smart Forms

SAP KBA 2135619: Background graphic is not printed to Zebra printer

cab Produkttechnik: FAQ – SAP-Anbindung über Gerätetyp LB_CAB und Kopplungsart U

ISO/IEC 15416: Bar code print quality test specification – Linear symbols

ISO/IEC 15415: Bar code print quality test specification – Two-dimensional symbols

WindowsPro: Windows Protected Print Mode (WPP) konfigurieren

CUPS: ipptool Manual

Microsoft-Statement vom 25. Februar 2026 zu Legacy-Druckertreibern, veröffentlicht bei Windows Central

About this blog post

This article describes publicly documented behavior of Microsoft Windows, the IPP standard, and the label printing architecture. Statements regarding the impact on individual print paths are inferences drawn from this documentation and do not replace an assessment of the specific system environment. Where a statement is not documented, it is marked in the text as an inference or a test point. This article does not contain any compatibility guarantees for individual products, product versions, or device models. The information regarding Mopria membership is current as of August 13, 2026.