A messaging feature is HIPAA-compliant only when every layer touching PHI is covered, not just the message itself: encryption in transit (TLS 1.2+) and at rest (AES-256), a signed Business Associate Agreement with the messaging vendor and every sub-processor that handles that data, role-based access controls that actually limit who can open a thread, automatic session timeouts, and an audit log that can tell you who read, sent, or deleted a message and when. Most “secure chat” SDKs get encryption right and quietly fail somewhere else — push notifications that leak PHI onto a lock screen, retention that outlasts HIPAA’s minimum-necessary standard, a BAA that covers the vendor but not the push service underneath it. Compliant messaging isn’t a checkbox tacked on after the chat UI ships. It’s an architecture decision, made before the first message bubble gets designed, covering data flow, storage, notifications, and logging end to end.

Misdelivery — PHI sent to the wrong recipient — has been one of the top three causes of healthcare breaches every year since 2014, and Verizon’s 2026 Data Breach Investigations Report still puts it near the top of the sector’s error-driven incidents. A chat thread is one of the easiest places for that to happen: the wrong patient selected from a dropdown, a diagnosis sitting in a push preview on a locked screen. Most of what ranks for “HIPAA compliant messaging app” right now is a vendor listicle ranking five SDKs, or a compliance-101 post that stops at “encrypt your data and sign a BAA.” If you’re building or embedding messaging into a custom iOS, Android, or web app — not shopping for a Slack-for-healthcare tool — that’s not enough to build from. Here’s what has to be true at the transport, storage, notification, and audit layers before messaging is safe to ship, and where build-your-own and embedded-SDK decisions diverge for a team doing telehealth app development or any product where care teams and patients talk to each other inside the app.

What “HIPAA-Compliant Messaging” Actually Means

HIPAA never actually defines “compliant messaging.” The Security Rule defines a set of Technical Safeguards that any system touching electronic PHI has to satisfy, and a messaging feature is one more system that has to satisfy them. 45 CFR § 164.312 lays out four standards that matter most for a chat feature specifically: access control (only authorized users get into a thread, and access can be revoked), audit controls (a record of who accessed or altered PHI and when), integrity (protection against a message being improperly altered or destroyed), and transmission security (protecting PHI while it’s moving across a network — the encryption-in-transit requirement most teams already know about).

Encryption is one line item inside one of those four standards, not the whole rule. A messaging feature that encrypts every packet perfectly but has no audit log, no access revocation, and no integrity checks on stored messages has satisfied roughly a quarter of what the Security Rule requires. That gap is exactly where most “secure chat” marketing copy stops, and where an actual compliance review starts.

The 6 Technical Requirements Every Compliant Messaging Feature Needs

Transport and At-Rest Encryption

TLS 1.2+ for anything moving between device, server, and recipient; AES-256 for anything sitting in a database, backup, or attachment store. Every vendor already advertises this one, and it’s necessary — just not sufficient. Get it wrong and nothing else here matters, because the data’s exposed before it reaches any other safeguard. Get it right and you’ve cleared transmission security and part of integrity; the other five are what most teams skip.

Business Associate Agreements — Vendor and Sub-Processor

A signed BAA with your messaging vendor is table stakes. What most teams miss is that HHS’s own guidance on business associate obligations makes clear a subcontractor that creates, receives, maintains, or transmits PHI on a business associate’s behalf is itself a business associate — meaning the push service, the SMS gateway, and any cloud storage vendor holding attachments need their own BAA, not just the platform on top of them. Ask your vendor for their sub-processor list. If they can’t produce one, that’s the answer.

Role-Based Access Controls and Message-Level Permissions

Not every care-team member needs to read every thread. A front-desk scheduler and an attending physician shouldn’t have identical access to a patient-to-provider thread just because they’re logged into the same app. Permissions should be scoped to what a role actually needs — care-team messaging visible to the care team, patient threads visible to the assigned provider and whoever’s covering, and real deprovisioning when someone leaves. This is the access control standard from 164.312, applied to a chat feature instead of the whole app.

Automatic Session Timeout / Auto-Logoff

A messaging session that stays open indefinitely on an unattended device is a PHI exposure waiting to happen, and it’s specifically named as an addressable implementation specification under the Security Rule’s access control standard. A reasonable idle timeout, forced re-authentication after it, and a hard logoff on backgrounding — none of this is exotic engineering, and all of it gets skipped by teams that build the chat UI first and the security model second.

Audit Logging — Immutable, Exportable, Complete

Every read, send, edit, and delete on a PHI-bearing thread needs a timestamped record of who did it — that’s the audit controls standard, and “we have server logs somewhere” doesn’t satisfy it. A compliance review needs those logs exportable and legible by a human, not buried in debug output — the requirement off-the-shelf SDKs fail most quietly, since their logging is built for engineering debugging, not for a trail a compliance officer can use.

Secure Push Notifications — the Leak Point Most Teams Miss

This is the one that catches experienced teams off guard. Send “Dr. Patel sent you a message about your biopsy results” as a push notification, and PHI just sat on a lock screen in a coffee shop. Researchers who examined 21 popular secure messaging apps found that 11 leaked metadata — and four leaked actual message content — to the push notification service itself, none of it disclosed in the apps’ privacy policies. The fix is a content-free payload: “You have a new message from your care team,” with real content pulled only after the user authenticates in-app. Native push services sit outside your BAA coverage unless you’ve built around it, so the payload itself can never carry PHI, full stop.

Where Off-the-Shelf Messaging SDKs Fall Short

General-purpose chat SDKs are built to solve chat, not healthcare compliance, and the gaps show up in predictable places. Most won’t offer a BAA at all — PHI use is often explicitly excluded from the terms of service, because the vendor built for enterprise chat, not clinical data. The ones that do offer a BAA often don’t extend it to their own sub-processors, putting you right back at the gap above. Retention policies are usually built around “keep everything forever,” fine for a workplace archive and directly at odds with HIPAA’s minimum-necessary and disposal expectations. Audit logs, when they exist, are built for the vendor’s own debugging, not for a compliance officer to hand to an auditor.

HHS has already settled a case over exactly this pattern. A hospital’s workforce started using an internet-based document-sharing application to store patient records — without a business associate agreement, without a risk analysis, without anyone asking whether the tool was built to hold PHI at all. St. Elizabeth’s Medical Center paid $218,400 to settle it, and the corrective action plan that followed cost far more than proper vetting would have upfront. Swap “document-sharing application” for “chat SDK” and the pattern is identical: a tool genuinely good at what it was built for, bolted onto a healthcare workflow it was never designed to carry — which I’ve seen from the other side too, managing my wife’s chronic illness care across a half-dozen providers’ messaging portals, where a vanished thread or an over-revealing notification is never abstract to the person waiting on it.

Build vs. Buy: Choosing a Compliant Messaging Architecture

There’s no universally right answer, and anyone who gives you one hasn’t scoped your product. It comes down to two things: how deep messaging needs to integrate with the rest of your clinical workflow, and how much control you need over the six requirements above.

When an Embedded HIPAA-Ready SDK Makes Sense

If messaging is a genuinely secondary feature — a patient can message the front desk, a care team can leave notes for each other — and it doesn’t trigger downstream clinical actions, a HIPAA-ready SDK with real BAA coverage (vendor and sub-processors), configurable retention, and exportable audit logs is often the faster, cheaper path. You’re trading control for speed, and for a feature that isn’t core to your differentiation, that’s usually the right trade — though the diligence doesn’t disappear; you still have to verify the BAA covers what you think it does.

When Custom-Built Messaging Is the Right Call

Custom messaging earns its cost when the thread needs to do more than hold text: a message triggering a task inside the EHR, a care-team conversation needing routing specific to your clinical workflow, or a white-label patient app where messaging is part of what you’re selling. Deep EHR integration in particular pushes teams toward a custom build, because an off-the-shelf SDK has no visibility into your data model and no reason to be built around it. We build to spec either way — a vendor selling one fixed platform has an obvious incentive to steer you toward buying it, and we don’t carry that incentive, so the honest answer is the same one: match the architecture to the integration depth you need, not to whichever option is easier to sell.

A Practical Checklist: Auditing Your Current Messaging Feature

If you already have a messaging feature live, here’s what to actually check before assuming it’s covered — the same six requirements above, converted into something a non-technical practice owner can hand a technical lead as a starting worksheet.

  • Encryption in transit and at rest. Why: the transmission security standard, and the first thing an OCR investigator checks. Verify: confirm the TLS version enforced and that the database and attachment store are encrypted, not just the connection.
  • BAAs covering the vendor and every sub-processor. Why: closes the legal gap. Verify: request the sub-processor list and confirm each one holds a BAA or never touches PHI.
  • Role-based access control. Why: limits the blast radius if an account is compromised. Verify: confirm a support or admin role can’t read patient message content by default.
  • Automatic session timeout. Why: closes the unattended-device gap. Verify: time an idle session and confirm it actually locks.
  • Exportable audit logs. Why: this is what you hand an auditor. Verify: export a log for a real thread and confirm it’s timestamped and legible without engineering help.
  • PHI-free push notification payloads. Why: the leak most teams don’t know they have. Verify: send yourself a test message and read what shows up on a locked screen.

Two questions come up almost every time a practice runs this list. Does standard SMS count as HIPAA-compliant messaging? Only with a carrier-level BAA and controls the native texting app doesn’t have — in practice, no. Does encryption alone make a feature compliant? No; it satisfies one of the four Technical Safeguards standards above, not all four. For the picture beyond messaging, our HIPAA compliance audit checklist covers the rest of what a covered entity or business associate needs in place.

How This Applies Across Platforms — iOS, Android, and Web

The six requirements above hold regardless of platform, but where they get implemented differs enough to matter.

On iOS, push notifications route through Apple’s APNs, and a notification service extension can decrypt and format content on-device after delivery, keeping PHI off the lock screen until the user’s authenticated in-app. Our building a compliant iOS healthcare app work treats this as a first-class requirement, not something bolted on before launch.

Android’s equivalent is Firebase Cloud Messaging — the exact service the research above flagged — so the same content-free-payload discipline applies. Android healthcare app development carries its own quirks around background restrictions and notification channels that affect how reliably a compliant payload gets delivered.

Web messaging drops the native push problem and picks up a different one: browser storage. A session token sitting in localStorage survives a tab close in a way it shouldn’t for PHI-bearing content, so a web-based healthcare application needs its own session-timeout strategy — closer to short-lived, memory-only tokens than “remember me for 30 days.”

None of this makes messaging harder to build. It makes it something you design for from the start instead of retrofitting after a security review flags it. If messaging is one piece of a larger build, our full guide to HIPAA-compliant app development covers the decisions that come before and after this one.