Windows Server

Shared Printing Broke After the Print RPC Hardening (CVE-2021-1678)? Patch Clients First

Published June 10, 2026 · by The FixHub Team

You hardened the print spooler against CVE-2021-1678 (or a security baseline did it for you), and now network printing is broken between your print server and clients. Or you’re about to enable the hardening and want to do it without taking printing down.

The mistake that breaks printing: the fix for CVE-2021-1678 raises the authentication level on the printer IRemoteWinspool RPC interface, controlled by a registry value. Most guides just tell you to set that value — and skip the prerequisite. Before you enable server-side enforcement, every client must already have the January 12, 2021 Windows update (or later). A hardened (enforcing) server talking to an unpatched client = failed RPC = no printing. The other common bad advice is to “fix” it by setting the value to 0, which simply removes the protection.

The control: RpcAuthnLevelPrivacyEnabled

The hardening is a single REG_DWORD at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print
  • RpcAuthnLevelPrivacyEnabled = 1 → enforcement on (raised auth level on the printer IRemoteWinspool interface) — the secure state.
  • RpcAuthnLevelPrivacyEnabled = 0 → protection disablednot recommended.
  • Value absent → default behaviour for your patch level.

The correct order (so printing doesn’t break)

  1. Patch every client first. Confirm all machines that print to the server have the January 12, 2021 cumulative update or later installed. This is the step that prevents the outage.
  2. Then enable enforcement on the server: set RpcAuthnLevelPrivacyEnabled = 1 and reboot the spooler/server.
  3. Test printing from a patched client. With both ends current, RPC negotiates the higher auth level and printing works — securely.

If printing is already broken

  • Don’t set the value to 0 as a permanent fix — that drops the CVE-2021-1678 protection.
  • Instead, find the unpatched clients and update them (they’re the ones failing). Once patched, they print again against the enforcing server.
  • If you need printing back immediately while you patch stragglers, removing/zeroing the value is a temporary stopgap only — re-enable = 1 as soon as clients are current.

If a single workstation shows the printer as “offline” rather than failing with an RPC error, that’s a different problem — see printer says offline in Windows 11. For broader standalone-server hardening, see hardening a standalone Windows Server.

FAQ

Where do I set this — server or clients? The RpcAuthnLevelPrivacyEnabled enforcement value goes on the print server. The prerequisite patch must be on the clients (and the server). Order matters: patch clients, then enforce on the server.

Will enforcement break non-Windows print clients? Clients that can’t negotiate the higher RPC auth level may fail. Inventory non-Windows printing paths before enforcing, and update their drivers/agents.

Is leaving it disabled (0) really that bad? It re-exposes a spooler RPC elevation-of-privilege vector. Treat 0 as temporary only; the goal state is 1 with all clients patched.

Sources: Microsoft — Managing deployment of printer RPC binding changes for CVE-2021-1678 (KB4599464)