Zero-trust is a phrase that has lost most of its meaning through overuse. But stripped to its original form, it says one simple, testable thing: no device, user, or session is trusted because of where it sits on the network. Every request is authenticated, authorized, and encrypted, regardless of origin.
Most MFPs fail this test the moment they are plugged in.
The three assumptions that made scan-to-email "safe"
Traditional MFP scanning inherited its security posture from the LAN era:
- The MFP is inside the firewall, so its traffic is trusted.
- SMTP is a solved problem because TLS exists.
- The recipient's inbox is their problem, not ours.
Every one of these is a network-trust assumption. Zero-trust architecture replaces all three with identity-trust and transport-trust assumptions — and once you do that, scan-to-email stops being a viable transport mechanism for sensitive records.
Where the assumptions break
1. "Inside the firewall" is no longer a security boundary
Modern threat models assume the LAN is already compromised. The 2023 PaperCut CVE (CVE-2023-27350) and the 2024 Xerox "Pass-Back" vulnerabilities (CVE-2024-12510 / 12511) both exploited MFPs that were, from a network perspective, "inside the firewall." The MFP was the pivot point, not the protected asset.
2. Hop-by-hop TLS is not end-to-end encryption
SMTP TLS protects individual hops, not the document itself. At every intermediate mail server the content is decrypted, inspected, and re-encrypted — a fact that most compliance frameworks (GLBA, HIPAA, PCI) increasingly acknowledge. Zero-trust requires the transport to be opaque to every party except the intended recipient.
3. Delivery is not where responsibility ends
Once a scan lands in a recipient's inbox, the sender has lost all control — retention, access, forwarding, backup, discovery. Zero-trust requires that authorization persist with the document, not expire at the mail boundary.
The test
Ask your security team: "If a single user's email credentials are stolen tomorrow, how many years of scanned documents does that give the attacker?" For most organizations running scan-to-email, the answer is "all of them." That is not a zero-trust posture.
What a zero-trust MFP scan actually looks like
A zero-trust scan-to-delivery architecture has four properties:
- Identity at the MFP, not just the network. The device authenticates to the transport service with device-specific certificates, not shared SMTP credentials.
- End-to-end encryption. AES-256-GCM on the content; TLS 1.3 on the channel. No intermediate decryption.
- Link-based delivery, not attachments. The recipient authenticates to retrieve; the document never leaves the vault until a verified request.
- Time-bound retention. A configurable retention window (default: 14 days) eliminates the permanent-copy problem at the root.
Why this matters to the CISO
The forward-looking CISO view: MFPs are printers until they scan. The moment they scan, they are data originators — and every data originator needs a zero-trust posture. Scan-to-email is the last place in most organizations where a sensitive document is produced, transmitted, and stored outside of a zero-trust perimeter without anyone noticing.
If your zero-trust architecture diagram has a dotted line around "MFPs — legacy," that's not zero-trust. That's zero-trust with a scan-to-email exception. Attackers notice that exception.
The pragmatic path
The honest answer for most security teams: you cannot retrofit zero-trust into scan-to-email. The transport is structurally incompatible. What you can do — and what most Botdoc deployments represent — is replace the transport, not the workflow. The MFP keeps its "Scan to Email" button. Under the hood, the button no longer uses SMTP. It uses an encrypted API endpoint with device-specific authentication, and the recipient gets a link, not an attachment.
From a zero-trust audit perspective, that single change closes the scan-to-delivery gap without a single workflow change for employees. It is one of the highest-leverage zero-trust moves available in 2026.