In my last article, “Why Microsoft Had to Rethink Printing,” I explained the vulnerabilities introduced by downloading print drivers from a server—commonly associated with the Print Nightmare class of issues. Much of this risk stems from a client model that depends on static configuration files to determine printer capabilities, along with dynamically loaded libraries to process print jobs. Legacy printing methods such as LPR and port 9100 (RAW) rely heavily on vendor-specific components to interpret and render print data. As discussed previously, this model created an attack surface that could allow arbitrary code execution in the SYSTEM context, particularly when using features like “Point and Print.” Beyond security concerns, port 9100 printing simply streams raw bytes to the printer without structure, metadata, or negotiation. This can result in unintended or garbled output—at best a nuisance, at worst a source of confusion during troubleshooting or incident response. Additionally, both LPR and RAW printing lack encryption, making intercepted print data potentially recoverable in transit. In effect, these legacy methods operate as “fire-and-forget” mechanisms, sending data to printers with minimal feedback or control over the outcome. Clearly, more structured print architecture was needed.
To address these limitations, the designers of the Internet Printing Protocol (IPP) in the late 1990s rethought the printing model from the ground up. One of the most significant changes was enabling printers to describe their capabilities dynamically in a standardized, structured format. This eliminated the need for clients to rely on static, model-specific configuration files.
Equally important was the introduction of a formal request/response protocol built on top of HTTP. IPP operations are encapsulated within the body of HTTP requests, allowing the protocol to leverage an existing, robust transport mechanism. This design decision was key to the eventual adoption of the protocol. By using HTTP, IPP gained immediate compatibility with common network infrastructure such as firewalls, proxies, and routing systems, avoiding the need for custom port configurations similar to those required for port 9100 printing.
Moreover, HTTP provides a mature framework for secure communication. With IPPS (IPP over HTTPS), encryption, authentication, and data integrity are handled through established TLS mechanisms rather than proprietary solutions. This not only improved security but also simplified implementation and interoperability across platforms.
The structured nature of IPP also enabled richer interaction between client and printer. Instead of sending an arbitrary byte stream and relying on the printer to infer intent, the client explicitly declared the operation, document format (via MIME type), and job parameters before submission. This allowed for more precise control and predictability in print operations.
At the core of IPP is the ability for clients to query printer capabilities dynamically using the Get-Printer-Attributes operation. This is one of several standard operations defined by the protocol, including Print-Job, Validate-Job, Create-Job, Send-Document, Cancel-Job, and Get-Job-Attributes. These operations form a structured, transactional model for managing print jobs.
An IPP message, when encapsulated within an HTTP request, is represented as a sequence of bytes encoded according to the IPP specification. This encoding defines how operations, attributes, and values are structured and interpreted. Unlike legacy methods, the printer does not attempt to infer the Page Description Language (PDL) from raw data. Instead, the client specifies the document format explicitly using a MIME type, ensuring that the printer processes the job correctly. This distinction has important implications, particularly for environments such as mainframe printing to terminal emulators using Windows pass-through mechanisms, which will be discussed later. Some common attributes that an IPP printer may expose via Get-Printer-Attributes include:
printer-state
ipp-versions-supported
document-formats-supported
document-format-preferred
queued-job-count
printer-resolution-default
output-bin-default
print-scaling-supported
orientation-requested
sides-default
printer-resolution-supported
media-type-supported
paper-kind
paper-input-tray
These attributes allow the client to dynamically determine the printer’s capabilities and configure print jobs accordingly, eliminating the need for static configuration files.
To submit a print job, a client typically uses the Print-Job operation, specifying the target printer, source document, MIME type, and relevant job parameters. The printer returns a job ID that can be used for monitoring and control. However, because Print-Job may begin processing immediately, the job could be completed before the client had an opportunity to act on it. To address this, IPP also supports a more controlled workflow using Create-Job followed by Send-Document. This approach allows the client to obtain a job ID before printing begins, enabling actions such as validation or cancellation prior to execution. Importantly, job control operations in IPP are executed on the printer itself, not just within the client’s print queue. This avoids scenarios common in Windows environments where a job canceled locally may still print because it has already been stored in the printer’s memory.
The structured request/response model of IPP provides additional operational benefits. Because printing only begins after valid operations are processed, intermittent or malformed data sent to the IPP/IPPS port (typically TCP 631) does not result in unintended output. This prevents issues such as random pages being printed due to network scans or port probes—an all-too-common occurrence with port 9100 printers.
A key advantage of IPP over HTTP (IPPS) is that it leverages the existing web infrastructure. Instead of defining a custom TCP port like 9100, the printer exposes a standard HTTP(S) endpoint, so clients only need a URL. This simplifies setup and allows printing to benefit from existing network capabilities like TLS security, authentication, proxy traversal, and standardized addressing. With raw printing over port 9100 (often called “Jet Direct” or “RAW”), Windows has to treat the printer like a generic TCP endpoint. That means manually defining a port, worrying about port numbers, and sometimes dealing with driver quirks. Additionally, HTTP is inspectable and well understood. Tools like curl or browser-based diagnostics can interact with endpoints, which makes troubleshooting issues much easier than with legacy print protocols.
Additionally, IPPS (IPP over HTTPS) enables encrypted transport without additional protocol complexity. In an era where data security is critical, this is a significant advantage. While TLS typically requires the client to trust the printer’s certificate authority, in practice, Windows often allows IPP/IPPS printer installation without strict enforcement of certificate validation, simplifying deployment in many environments.
Microsoft termed the new print architecture “Modern Print” – however this is not a simple marketing ploy. Printers are required to be Mopria compliant, meaning they are certified to promote consistent and reliable printing experience across different brands and models. Mopria certified devices can print from Android devices and Windows 10/11 computers without needing to install additional drivers or software. This is accomplished by supporting a common set of Page Description Languages, allowing the devices to interpret and render print jobs consistently, regardless of the manufacturer. When paired with IPP/IPPS, this experience offers true driver independence and a substantially less complex and more robust print experience than the existing Microsoft print architecture.
Finally, in response to the widespread concerns created by the “Print Nightmare’ vulnerabilities. Microsoft suggests clients implement a security focused feature called Windows Protected Print (WPP). This feature requires implementation of IPP (and more specifically IPPS) as it narrows what the spooler service accepts as legitimate print functionality. Specifically, WPP restricts the types of print drivers and protocols that can interact with the spooler, reducing the attack surface for potential exploits. This approach is designed to limit or mitigate vulnerable functionality and limits the spooler's exposure to only trusted and secure printing operations. Once enforced, older type 3 driver technology, legacy print components, and legacy print protocols such as port 9100 and LPR will no longer function. Implemented with IPPS, a transformation from legacy print to a more secure, robust, interoperable, and user-friendly print subsystem in Windows can be realized. This is the classic win-win scenario for the Windows ecosystem and enterprises that employ them.
Further Reading
For readers who want a deeper understanding of Windows printing architecture—both legacy and modern—consider:
Adopting Internet Printing Protocol for Windows
This book provides a comprehensive exploration of the Windows print subsystem, from driver architecture to network printing protocols, making it a valuable reference for engineers and system administrators.
Coming Next
In the next article, we’ll take a deeper look at some of the implementation issues enterprises may encounter when transitioning to Modern Print.
Top comments (0)