Secure Printing

Overview

Secure printing (also called secure release, pull printing, or "follow-me" printing) is a family of print-subsystem behaviors whose shared purpose is to keep a document from emerging at a device tray until an authenticated, physically present user authorizes it, and to protect the job's contents while it moves across the network and while it rests on the printer or multifunction printer (MFP).

The term covers several distinct, composable mechanisms:

• Held / secure-release jobs — a job is queued in a held state rather than printed immediately.
• Release authentication at the device — the user unlocks the held job with a PIN, a proximity or badge card, a mobile app, or a QR-code scan.
• Encryption in transit — the submission channel is protected with TLS, standardized for the Internet Printing Protocol (IPP) as the ipps URI scheme and IPP-over-HTTPS binding.
• Data-at-rest protection — encryption of, and secure erasure from, the MFP's internal storage.

These are largely independent standards and features that vendors combine into a single "secure print" product. The core problem being solved is the "abandoned printout": in shared-device environments, an immediately printed confidential document sits in the output tray for anyone to read or take. Secure release closes that window; transit encryption and at-rest protection close the network-sniffing and device-storage windows.

History

The building blocks were standardized incrementally rather than as a single "secure printing" specification.

The Internet Printing Protocol model (RFC 2911, September 2000) already defined OPTIONAL Hold-Job, Release-Job, and Restart-Job operations along with a job-hold-until job-template attribute — the primitive that lets a job wait in a held state until it is explicitly released. RFC 3998 (March 2005) added administrative operations at the printer level, including Hold-New-Jobs and Release-Held-New-Jobs.

Transit security for IPP was originally attempted through the HTTP Upgrade mechanism. Because that approach proved unreliable in practice, the IETF and PWG defined a dedicated ipps scheme and IPP-over-HTTPS binding in RFC 7472 (March 2015).

In parallel, printer and MFP vendors built proprietary "secure print" and "job storage" features — PIN-protected stored jobs, disk overwrite, disk encryption — into device firmware, and third-party pull-printing servers grew up around them. Cloud print services later moved job holding and release orchestration into the cloud.

Architecture

A secure-printing deployment is layered across four planes:

• Submission client — the operating-system print path (a driver or driverless IPP) that emits the job, optionally tagging it as held and attaching a release credential such as a user-chosen PIN.
• Spool / hold point — where the held job waits. This can be the submitting workstation, an on-premises print or release server, the target device's own storage (job storage), or a cloud service.
• Release authentication at the device — a control-panel PIN pad, an embedded or external card reader (proximity or smartcard), a mobile app, or a QR code, tied back to an identity provider.
• Device storage subsystem — the MFP's non-volatile media (HDD, SSD, or eMMC) plus its encryption and secure-erase firmware, which govern data-at-rest exposure.

The transport that connects the submission client to the hold point (and the hold point to the device) is where TLS via ipps applies. Authentication may be enforced at the transport layer (for example HTTP Basic or Digest over TLS, or OAuth) and at the device release step, independently.

How it works

In the most common held-print flow, the user prints normally but the job is marked to be held. Depending on the product, the held job is retained on the workstation, a release server, the device itself, or the cloud. Nothing prints yet.

The user walks to an enrolled device and authenticates — entering a PIN on the panel, tapping a badge on a reader, or scanning a QR code with a phone app — and the system then releases the matching job or jobs to that device for printing. Pull or "follow-me" printing generalizes this so that a single held job can be released at whichever device the user chooses.

Vendor "secure PIN" printing is a device-local variant: the driver stores the job in the device's job-storage area behind a numeric PIN, and the job prints only when the PIN is entered at the panel.

In IPP terms, the held state corresponds to a pending-held job that a Release-Job operation (or a device or UI equivalent) moves to pending or processing. Transit confidentiality is provided by TLS; RFC 7472 requires TLS 1.2 or higher for ipps connections. At-rest protection is handled by the device: encrypting the storage volume and overwriting job data after completion.

Data flow

The path a job takes through a secure-printing subsystem generally follows six steps:

1. Rendering and tagging — the client renders the job (as a page-description language or driverless IPP) and sets hold and release attributes and any PIN. 2. Encrypted submission — the job travels to the hold point. Over IPP this uses the ipps scheme (IPP over HTTPS/TLS, on port 631 by default per RFC 7472, which inherits the IPP port from RFC 2910), so the payload and IPP operation attributes are protected in transit. 3. Held storage — the job rests in the pending-held state at the chosen hold point (workstation, release server, device job-storage area, or cloud). If stored on an MFP disk, at-rest encryption applies here. 4. User authentication at the device — PIN entry, badge or card tap, mobile app, or QR scan validates identity against the release system or identity provider. 5. Release and imaging — the matching job is released (via Release-Job or a vendor equivalent), transferred to the device over a secured channel if not already present, rasterized, and printed. 6. Post-print cleanup — temporary job files are deleted; secure-erase firmware overwrites the storage regions so residual data cannot be recovered; and unreleased or expired jobs are purged.

Operating system integration

Windows and Microsoft Universal Print. Universal Print is a cloud print service built on IPP and Mopria (driverless), authenticated with Microsoft Entra ID, that holds jobs in the cloud and supports secure release. An administrator enables holding jobs until secure release per printer share, and users release via a QR code scanned with the Microsoft 365 mobile app, integrated badge release, or a device secure PIN. Windows also supports Print Support Apps for vendor-specific features. Windows' local print path historically used the spooler and v3/v4 drivers, with driverless IPP the modern direction.

macOS and Linux (CUPS). CUPS — the print system used by macOS and most Linux distributions — speaks IPP natively, supports the ipps secure transport, and supports IPP authentication; it can express held jobs via the IPP hold/release model. Driverless printing on these platforms is based on IPP Everywhere.

Device firmware. The release-authentication interface, job-storage and PIN features, disk encryption, and secure-erase controls live in the printer or MFP firmware and its embedded web server, independent of the client operating system.

Relationship to standards

• RFC 2911 (IPP/1.1 Model and Semantics, September 2000) — defines the OPTIONAL Hold-Job (§3.3.5), Release-Job (§3.3.6), and Restart-Job (§3.3.7) operations and the job-hold-until attribute (§4.2.2): the standardized primitive for held jobs. All are OPTIONAL, so a given printer may not implement them.
• RFC 3998 (IPP Job and Printer Administrative Operations, March 2005) — adds printer-level Hold-New-Jobs and Release-Held-New-Jobs and related administrative operations.
• RFC 7472 (IPP over HTTPS Transport Binding and the ipps URI Scheme, March 2015) — defines the ipps scheme and IPP-over-HTTPS binding, mandates TLS 1.2 or higher, and uses default port 631.
• PWG 5199.10-2019 (IPP Authentication Methods, IPPAUTH) — best-practice guidance that a printer should only challenge a client for authentication over a secure (TLS) connection; it references HTTP Basic (RFC 7617) and Digest (RFC 7616) and OAuth 2.0 bearer tokens.
• PWG 5100.14 (IPP Everywhere v1.1, 2020) — the driverless-printing baseline underpinning modern secure driverless submission.
• Newer PWG work — IPP System Service (PWG 5100.22, v1.1, 2025), IPP OAuth Extensions (PWG 5100.23, v1.0, 2025), and IPP Privacy Attributes (2018) extend the secure-printing surface. A prototype draft, "IPP Encrypted Jobs and Documents" (TRUSTNOONE), explores end-to-end job encryption but is a prototype draft, not a ratified standard.

Relationship to technologies

• TLS — the transport-security foundation for ipps and for authenticating release and administrative sessions.
• PKI and certificates — device and certificate-authority certificates enable certificate-based authentication and establish trust for ipps.
• Identity and access — cloud secure release ties the release step to an identity provider (for example Microsoft Entra ID), and OAuth is being standardized into IPP. Card release relies on proximity or smartcard technologies and directory lookups that map cards to users.
• Storage security — disk or volume encryption (AES) and secure-erase or overwrite algorithms protect at-rest data; self-encrypting drives push encryption into the media itself.
• Mobile — QR-code release and companion apps bring the release step to the user's phone.

Relationship to manufacturers

Vendor implementations layer proprietary features on the standards above; exact feature names and options vary by product and current documentation.

• HP — "HP Secure Print" holds a client-side, PIN-protected job for release. Device data-at-rest protection is provided by the HP Secure Hard Disk accessory, documented as hardware full-disk AES encryption (AES-128 by default, configurable to AES-256), together with secure-erase and overwrite features described in HP LaserJet Managed MFP hard-disk security documentation.
• Xerox — image and disk overwrite features and encryption of customer data at rest on device storage, per Xerox product-security documentation, plus PIN/secure-print and follow-you release in Xerox print-management products.
• Microsoft — Universal Print provides cloud-held jobs with QR, badge, and PIN release; it is a service and OS-level integrator rather than a hardware maker.
• Third-party pull-print platforms — release-station software that integrates across many device brands using the IPP held-job model and card-reader ecosystems.

Marketing terms such as "secure print," "private print," and "follow-me" map onto the same underlying held-job, device-authentication, and storage-protection primitives, but the names are not interchangeable across vendors.

Modern relevance

Secure printing remains standard practice in healthcare, legal, financial, and government environments, where uncollected printouts are a confidentiality and compliance exposure.

Several trends sustain its relevance. The shift to shared or floating desks and "print-anywhere" workforces favors pull printing, which follows the user to any device. The move to driverless IPP and cloud print relocates held jobs to cloud services and folds release into cloud identity. And heightened attention to MFP storage as a data repository — especially at device decommissioning — keeps encryption and secure erase in focus.

Newer PWG efforts, including OAuth-based authentication and encrypted-jobs prototypes, indicate that the standards community is extending confidentiality from transit-only protection toward stronger end-to-end and identity-based models.

Common misconceptions

• "Secure print encrypts my document." Held or secure-release printing primarily controls when and by whom a job is released. Confidentiality in transit is a separate concern handled by TLS (ipps), and at-rest protection is a separate device feature. A held job is not automatically encrypted end-to-end.
• "IPP is inherently secure." Plain IPP (the ipp scheme, typically port 631) is not encrypted by default; security comes from the ipps/IPP-over-HTTPS binding (RFC 7472) and from authenticating over TLS.
• "A PIN is strong authentication." Device PINs are convenience credentials — often short and reusable — and are weaker than badge, smartcard, or federated-identity release.
• "Deleting a job clears it from the MFP." Without secure-erase or overwrite, job data can persist on the device's disk; at-rest encryption and secure erase are what actually mitigate storage recovery.
• "Hold-Job and Release-Job are mandatory IPP features." They are OPTIONAL operations in RFC 2911; a given printer may not implement them.
• "Pull printing is a single standard." It is a product pattern built from standard primitives plus proprietary release servers and readers; there is no single "pull printing" protocol.

Timeline

1. 2000

   RFC 2911 (IPP/1.1) defines the OPTIONAL Hold-Job, Release-Job, and Restart-Job operations and the job-hold-until attribute.

2. 2005

   RFC 3998 adds IPP administrative operations, including Hold-New-Jobs and Release-Held-New-Jobs.

3. 2015

   RFC 7472 defines the ipps URI scheme and IPP-over-HTTPS binding, mandating TLS 1.2 or higher.

4. 2018

   PWG publishes the IPP Privacy Attributes registration.

5. 2019

   PWG 5199.10 IPP Authentication Methods (IPPAUTH) best practice is published.

6. 2020

   PWG 5100.14 IPP Everywhere v1.1 establishes the driverless baseline.

7. 2023

   Microsoft documents Universal Print secure release with a QR code.

8. 2025

   PWG publishes IPP OAuth Extensions (PWG 5100.23) and IPP System Service v1.1 (PWG 5100.22); the IPP Encrypted Jobs and Documents (TRUSTNOONE) work exists as a prototype draft.