Every healthcare organization in the U.S. has at least one copier in at least one clinic, back office, or admin floor. Most of them scan patient records. Very few of them scan patient records in a way that a HIPAA auditor in 2026 would call compliant. The gap is usually not malicious — it's just that scan-to-email was set up a decade ago by someone who is no longer at the organization, and no one has revisited it since.
This post is the checklist we wish every Covered Entity and Business Associate would run against their MFP fleet this quarter. It is not legal advice — but it maps one-to-one to the HIPAA Security Rule citations an auditor will actually walk through.
What HIPAA actually requires for transmission
The relevant citation is 45 CFR § 164.312(e)(1) — the Transmission Security standard. It has two implementation specifications:
- § 164.312(e)(2)(i) — Integrity Controls (addressable). Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection.
- § 164.312(e)(2)(ii) — Encryption (addressable). Implement a mechanism to encrypt ePHI whenever deemed appropriate.
"Addressable" is the word that trips up every organization. It does not mean optional. It means: implement it, or document in writing why an equivalent alternative is reasonable and appropriate. In 2026, with AES-256 being a free commodity and TLS 1.3 being universal, "we chose not to encrypt" has effectively no defensible justification for routine scan-to-delivery of patient records.
The auditor's opening question
"Show me, for a scan of a patient intake form sent from the front desk copier yesterday, the record of how that document was encrypted in transit, who accessed it, and when it was deleted." If you can't produce that record in under five minutes, the rest of the audit gets harder.
The 2026 HIPAA scanning checklist
Run every MFP that scans ePHI against the following. If you can check all 12, you are in good shape. If you can check fewer than 8, you have a material finding waiting to be discovered.
Transport & encryption
- End-to-end encryption on document content, not just the channel. AES-256-GCM at minimum. Hop-by-hop SMTP TLS does not satisfy this because the payload is decrypted at every relay.
- TLS 1.3 on the channel, with modern cipher suites. TLS 1.0 and 1.1 are deprecated; TLS 1.2 is acceptable only with AEAD ciphers. Run the external-facing test yourself — most organizations are surprised.
- No plaintext attachments traversing the public internet. If an attacker intercepts a message mid-flight, the payload must be unreadable without the recipient's authentication.
- Certificate-based device authentication. Each MFP authenticates to the transport service with a unique device certificate — not a shared SMTP username/password that survives employee turnover.
Access & authorization
- Recipient authentication before the document opens. Either a verified one-time code or an authenticated session. "Click the link to view" with no verification step does not satisfy authorization.
- Role-based access at the MFP itself. Badge-in or PIN-protected scan. A shared lobby copier that anyone can walk up to and scan-to-anywhere fails this control.
- Least-privilege delivery destinations. Users cannot type in arbitrary external email addresses from the MFP panel. Destinations are provisioned, or the delivery is via secure link that the recipient self-verifies.
Audit & lifecycle
- Full audit log of every scan. Who scanned, from which device, to which recipient, at what time, and the document fingerprint. The log retains for at least 6 years per § 164.316(b)(2).
- Delivery-confirmation log. Record of whether the recipient opened the document and when. Scan-to-email gives you no such confirmation — once it's sent, you don't know what happened.
- Automatic retention expiry. Documents self-delete from the transport layer after a defined retention window. Inboxes keep documents forever by default; that is the inverse of minimum necessary.
- Documented Business Associate Agreement with the transport vendor. Signed BAA before a single ePHI byte traverses the service. If you cannot produce the executed BAA, you cannot use the vendor for ePHI.
Risk analysis & documentation
- MFP scanning is named in your § 164.308(a)(1)(ii)(A) risk analysis. If the words "multifunction printer" or "scan to email" do not appear in your most recent risk analysis, you have a § 164.308 gap independent of the transport itself.
The three findings we see most often
From conversations with healthcare compliance leads at organizations ranging from single-clinic practices to multi-hospital systems, the same three findings surface repeatedly:
- Shared SMTP credentials on the MFP. The copier uses a single mailbox like scanner@clinic.org, whose password has not rotated in years. Anyone who has ever worked in IT knows it. This is the single highest-severity finding on most healthcare scanning audits.
- "TLS is on" mistaken for encryption at rest and in transit. The MFP vendor reassured the practice admin that "everything is encrypted." What they meant was opportunistic STARTTLS on outbound SMTP — which downgrades silently and does nothing for data-at-rest after delivery.
- No audit trail. When the OCR investigator asks for a list of every ePHI document scanned from a specific device in a specific week, the answer is "we don't have that." The absence of evidence of compliance is itself a finding.
HIPAA does not require you to use any specific product. It requires you to be able to prove that ePHI is protected in transit and that you have the records to demonstrate it. Scan-to-email, by its architecture, cannot produce those records. That is why the replacement is a transport-layer decision, not a workflow change.
What the fix looks like in practice
The pragmatic remediation sequence we see working in 2026:
- Inventory every MFP that scans ePHI. Most organizations discover they own 20–40% more scanning devices than their asset register shows.
- Disable direct SMTP scanning. Remove the shared-credentials mailbox from the device, or block port 25/587 outbound on the MFP VLAN.
- Deploy a zero-trust scan transport. The MFP keeps its "Scan to Email" button. Under the hood, the button no longer uses SMTP — it posts the document to an encrypted API endpoint, and the recipient retrieves via authenticated link. Employee workflow is unchanged.
- Sign the BAA, update the risk analysis, document the control. Three pieces of paper that close the audit finding.
- Run a 30-day sample audit. Pull a random week of scan logs, confirm every record has encryption, recipient authentication, and retention metadata. That sample is your evidence.
An organization with 25 MFPs can typically complete steps 1–4 in under three weeks of elapsed time. The blocker is almost never technical — it is getting the right stakeholders (IT, Compliance, the MFP vendor, the practice admin) in the same room once.
If you only do one thing this quarter
Pull the SMTP credentials off your MFPs. Even before you select a replacement transport. That single action removes the single most commonly exploited scan-to-email attack path and turns a high-severity finding into a moderate one overnight.
What HHS & OCR are signaling for 2026
HHS's Office for Civil Rights continued its pattern of resolution agreements in 2025–2026 that specifically name transmission security as a root cause. The pattern is consistent: the breach disclosure names a stolen email inbox, a misrouted fax, or a scanner that was internet-exposed, and the resolution agreement requires the entity to "implement encryption of ePHI in transit" within 90 days. Reading between the lines: OCR is no longer treating the "addressable" designation on § 164.312(e)(2)(ii) as optional in practice.
If the auditor's first question is "how is ePHI encrypted in transit from your scanning devices?" — and it now is, consistently — you want an answer that fits in a single sentence and is backed by a device-level audit log.