You've enabled encryption in Microsoft 365. You've signed Business Associate Agreements. You've trained staff to type "Secure" in subject lines. And you're still exposed.
These myths persist because they're comforting. They let you check boxes without questioning whether the underlying architecture actually protects patient data. With the Office for Civil Rights (OCR) proposing to reclassify encryption from an addressable to a required safeguard, the gap between perceived compliance and actual security is about to become very expensive.
Here's what you probably believe about email encryption, and why it's wrong.
Myth 1: "We have encryption enabled, so our emails are encrypted"
Reality: Your platform prioritizes delivery over security, and it won't tell you when it fails.
Microsoft 365 and Google Workspace include a feature called "silent fallback." When a recipient's server doesn't support modern TLS protocols (TLS 1.2 or higher), these platforms downgrade to plain text transmission to ensure the message gets through. They don't bounce the email. They don't alert you. They just send it unencrypted.
This isn't a configuration error you can fix in settings. It's a design philosophy: delivery first, security second. According to a recent Paubox analysis, 52% of email-related breaches in 2025 involved Microsoft 365. You can have encryption "enabled" in your admin console and still suffer a reportable breach because your platform negotiated down to an insecure protocol without your knowledge.
The HIPAA Security Rule § 164.312(e)(1) requires transmission security. Silent fallback violates that requirement, but you won't know it happened unless you're auditing every outbound message at the protocol level.
Myth 2: "Secure portals solve the encryption problem"
Reality: Portals trade security compliance for usability failure, which creates new risks.
You're technically compliant when you send a portal link instead of PHI in the message body. But data from the National Library of Medicine shows 65% of portal users stop engaging after day one. Another 22% cite difficulty navigating basic functions.
What happens when a physician needs lab results now and the patient can't figure out the portal login? They call the office. The office emails the results directly. Or they text them. Or they fax them to a personal number. The secure portal didn't eliminate the risk, it just pushed it into less visible channels.
You're measuring portal adoption rates, but you should be measuring workaround frequency. Every time a staff member bypasses the portal because "the patient couldn't get in," you've created an unlogged, unencrypted transmission that won't show up in your risk analysis.
Myth 3: "Staff training will prevent email mistakes"
Reality: Manual security controls fail at scale, and you can't train your way out of a design flaw.
One clinic paid $25,000 for sending PHI to the wrong recipient via unencrypted email. That wasn't a training failure, it was a system design failure. When security depends on a human remembering to type "Secure" in the subject line or selecting the right recipient from autocomplete, you're building on a foundation that will crack.
A recent survey found 82% of healthcare IT leaders worry staff will miss a critical security step. They're right to worry. Cognitive load research shows that adding even one decision point to a routine task increases error rates significantly. Your staff are managing patient care, insurance verification, scheduling conflicts, and EHR alerts. Expecting them to also evaluate encryption requirements for every outbound message is unrealistic.
The HIPAA Security Rule § 164.308(a)(5) requires security awareness training, but it doesn't say training alone is sufficient. If your architecture requires perfect human performance to avoid breaches, your architecture is non-compliant.
Myth 4: "Addressable specifications give us flexibility to choose our approach"
Reality: OCR is proposing to make encryption a required safeguard, and "addressable" won't protect you much longer.
Under current regulations, encryption of ePHI in transit is an addressable implementation specification under § 164.312(e)(2)(ii). You can assess the requirement, document why you chose an alternative, and implement reasonable equivalent measures.
OCR's 2025 proposed changes would reclassify encryption from addressable to required. That means no more flexibility. No more documented alternatives. Encryption becomes a baseline expectation, and you'll need audit logs proving it was applied to every outbound message containing PHI.
This shift represents a broader regulatory trend: from policy-driven compliance to proof-driven accountability. It's not enough to have an encryption policy. You need technical controls that generate verifiable evidence that the policy was enforced on every transmission.
Myth 5: "We have a BAA with Microsoft, so we're covered"
Reality: A BAA doesn't override technical failures, and it won't prevent OCR penalties.
Your Business Associate Agreement with Microsoft establishes contractual obligations. It doesn't change how silent fallback works. It doesn't stop your emails from downgrading to plain text when a recipient's server is outdated. And it won't prevent OCR from holding you accountable when a breach occurs.
The first half of 2025 saw 107 email-related HIPAA breaches reported to HHS. Many of those organizations had BAAs in place. The agreement didn't fail, the underlying technology did.
A BAA is necessary but not sufficient. It's a legal document, not a security control. You still need to verify that the services covered by the BAA actually implement the safeguards you think they do.
What to do instead
Move to encryption-by-default architecture. That means selecting email platforms that apply encryption at the gateway level, automatically, for every outbound message, with no user decisions required and no silent downgrades permitted.
Audit your current platform's TLS negotiation behavior. Can you see when a message downgrades to an insecure protocol? Do you receive alerts? If not, you're operating blind.
Stop relying on portals as your primary secure communication method unless you've also measured workaround frequency. Survey your staff: how often do they bypass the portal because a patient or colleague couldn't access it? Those workarounds are your real risk surface.
Prepare for the proposed OCR changes now. Even if the final rule doesn't take effect until 2026, enforcement priorities are already shifting. Start generating the audit logs you'll need to prove encryption was applied. Document every transmission, every protocol negotiation, every exception.
And if your current approach requires staff to remember, toggle, or type something to trigger encryption, replace it. Human-dependent security controls don't scale, they don't audit well, and they won't survive the coming regulatory shift.
