Do Software PDF Printers Work Under Windows Protected Print?

TL;DR

Microsoft's built-in "Print to PDF" is an inbox driver and will likely survive Windows Protected Print Mode (WPP). Third-party software PDF printers (eDocPrinter, PDFCreator, Bullzip, CutePDF, and similar) rely on the v3 or v4 driver model that WPP removes from the client. When WPP is enforced, those virtual printers are uninstalled along with the rest of the third-party driver fleet. The path forward is either keep WPP disabled on workstations that depend on those drivers, or migrate the workflow to application-native PDF export (Word, Excel, Adobe, browsers all have it built in). Keeping WPP disabled is not the same as opting out of Windows Ready Print, the modern IPP-based platform that becomes the default for new printer installs in July 2026. On its own that platform does not strip these virtual printers from a machine; enabling WPP is what removes them.

How do software PDF printers work?

Software PDF printers are built on a Type 3 or Type 4 virtual driver that captures the print job and writes it to disk in PDF format. Adobe's Acrobat distiller, Microsoft's "Print to PDF" inbox driver, and third-party tools (PDFCreator, Bullzip, CutePDF, eDocPrinter, doPDF) all use the same architecture. Windows Protected Print (WPP) changes that architecture. WPP is the strict enforcement tier of Windows Ready Print, the modern IPP-based platform, and it does not accept the v3 or v4 driver model these tools depend on.

What happens to software PDF printers under WPP?

Is Microsoft Print to PDF affected by WPP?

This is shipped as an inbox driver in modern Windows. Because it's a Microsoft-supplied component and is part of the Windows print platform itself, it's expected to survive WPP enforcement. The driver is signed by Microsoft, ships with the OS, and isn't subject to the third-party driver removal that WPP performs.

What is the OneNote (Desktop) - Protected printer?

 Microsoft has shipped a WPP-compliant alternative for OneNote. It's the only third-party-style virtual printer Microsoft has explicitly carved out a WPP-compliant version for at the OS level.

What happens to eDocPrinter, PDFCreator, and Bullzip?

Different category. Tools like eDocPrinter, PDFCreator, Bullzip, CutePDF, and doPDF install as Type 3 or Type 4 drivers that the WPP removal process does not distinguish from any other third-party driver. When WPP is enabled on the client, those virtual printers are uninstalled. Reinstallation is blocked while WPP is enabled, because the installation path requires a third-party driver that the spooler no longer accepts. This removal is tied to enabling WPP specifically. Windows Ready Print becoming the default install path for physical printers does not, by itself, uninstall these virtual printers or block their installation. That behavior comes from WPP.

What happens to DMS and archive virtual printers?

Same category as third-party PDF tools. Solutions that capture print jobs into archives, document repositories, or workflow systems via a virtual printer driver depend on the same architecture and are removed under WPP.

Virtual, PDF, and archive printer vendors will need to adapt their products. The path is unclear for vendors that don't engage with the WPP architecture themselves.

What makes a PDF printer WPP-compatible?

For a third-party PDF printer ISV to ship a WPP-compatible version, the driver model can no longer be Type 3 or Type 4, the capture mechanism has to operate in a WPP-allowed context (typically a Print Support App-style user-mode component, which is the extensibility model Windows Ready Print expects, or a different architecture like share-sheet integration), and the signing and distribution model has to fit Microsoft Store or sideloadable enterprise distribution. This is not a small lift. Several of the established third-party PDF printer products are built around the v3/v4 driver model going back fifteen to twenty years, and a from-scratch rebuild is what's required to ship a WPP-compatible equivalent. Not every vendor will undertake it - the smaller and free-tier products are particularly at risk.

How does WPP affect your PDF and document workflows?

Microsoft Print to PDF and native Adobe export

Native paths survive. Microsoft Print to PDF is an inbox driver and stays available. Adobe products that use native PDF export (Save as PDF, Export to PDF) work unchanged; workflows that explicitly use "Adobe PDF" as a printer driver may be affected depending on the specific Adobe product version.

Free and low-cost PDF tools, including eDocPrinter

PDFCreator, Bullzip, CutePDF, doPDF, eDocPrinter, and similar are at risk of being removed by WPP. Each is a third-party virtual printer driver subject to WPP's driver removal. The path forward is either replacing them with Microsoft Print to PDF for workflows that don't need their advanced features, moving to application-native PDF export, or waiting for the vendor to ship a WPP-compatible version.

Document management and archive virtual printers

This is the highest-risk category for an enterprise. Workflows that depend on a virtual printer to capture documents into a DMS, ECM, or compliance archive fail when WPP removes the printer driver. The enabling path is engagement with the DMS vendor about their WPP roadmap. If the vendor doesn't have one, the architectural answer is to capture documents through a different mechanism (application-native export, file system watchers, API integration) rather than through a print path.

Does ezeep work under WPP?

ezeep is not in the software PDF printer category. ezeep handles printing to physical printers through cloud rendering; it does not present itself as a virtual PDF printer for capturing documents to disk. So WPP's effect on third-party virtual printer drivers is not directly an ezeep question. Because ezeep prints through cloud rendering rather than acting as a virtual PDF printer driver, the driver removal WPP performs does not apply to it.

Where ezeep does intersect this topic: for environments running document management workflows that combine "print to a physical printer" and "capture to a DMS," ezeep handles the physical printing path under Windows Ready Print and under WPP. The DMS-capture path needs to be addressed separately, through whichever DMS-side mechanism survives WPP. Combining the two questions makes the WPP planning conversation more focused: what's the print path, what's the document capture path, and which components are affected by WPP at each step.

How do you prepare for WPP enforcement?

Three concrete moves. All can be found in our Windows Protected Print Readiness Checklist.

1. First, inventory all virtual printer drivers currently installed across the fleet: Microsoft Print to PDF, third-party PDF tools, document management capture printers, archive printers, fax-by-print drivers.

2. Second, classify each by whether the workflow it supports has an application-native or API-based alternative that doesn't depend on a virtual printer driver.

3. Third, for the workflows that genuinely depend on a third-party virtual printer driver, engage the vendor about their WPP roadmap or plan for the workflow to move to a different mechanism.

Talk to an expert about virtual printer dependencies in your environment

If your document workflow depends on third-party virtual printer drivers (PDF tools, archive capture, DMS integration), WPP is a planning conversation, not a one-line answer. Let's walk through your environment.

Auditing The Whole Fleet?

Our checklist takes you device by device.

Get the WPP Checklist