Looking for technical depth? See the companion piece: HIPAA 2026 and Kafka: Securing ePHI Streams. This one is a high-level take on what HIPAA 2026 means for a Kafka shop.
Healthcare regulation has a recurring problem with streaming data, which is that it doesn't know streaming data exists. HIPAA was enacted in 1996. The Security Rule was finalized in 2003 and revised by the Omnibus Rule in 2013. The NPRM that OCR published in January 2025, which the industry is calling "the 2026 update" because OCR is targeting May 2026 to finalize it, would be the first version to make encryption of ePHI broadly required rather than addressable. None of those documents mention Kafka, or message brokers in general, because the people writing them were thinking about EHR databases and clinician laptops, not about the actual movement of patient data through a modern hospital's data infrastructure.
Regulation is not supposed to specify implementations. The trouble is that the two abstractions HIPAA uses, "data at rest" and "data in transit", are exactly the abstractions that streaming systems blur.
A Kafka topic is not really either one. It is data sitting on disk — or in S3, with tiered storage or diskless setups — but it is sitting there because data is moving through. The storage is incidental to the transit. A producer write and a consumer read can be separated by milliseconds or by months, depending on retention. So when an auditor asks "is this ePHI encrypted at rest" and the answer is "the disk underneath the broker is encrypted with EBS keys", everyone is technically correct and nobody has answered the question of whether someone with shell access to the cluster can read patient names in clear text.
The 2026 update will force that conversation, partly on purpose, partly by accident.
What the NPRM actually proposes
The headline is that "addressable" is gone. Before, HIPAA's encryption specifications were marked addressable, meaning you could document a mitigation and skip the encryption itself if you had a reason. The NPRM removes that distinction. Encryption of ePHI at rest and in transit becomes required. MFA becomes required for persons accessing relevant electronic information systems, with limited exceptions for unsupported legacy technology, emergencies, and certain FDA-regulated devices. The inventory of every system that creates, receives, holds, or transmits ePHI, along with a network map, becomes required. And business associates have to give annual written verification that their §164.312 technical safeguards are actually deployed.
Why this is harder than it looks
The encryption-at-rest requirement is the one I think people will get wrong.
If you ask ten platform engineers whether their Kafka cluster encrypts data at rest, nine of them will say yes. They will mean their EBS volumes have KMS encryption enabled, or something close to it.
"We have an encryption agent sitting on top of our brokers for disk-level encryption." — Platform lead at a Fortune-50 health insurer
That setup protects you against an attacker who walks into AWS's data center, pulls a drive, and tries to read it on another machine. It is a real threat, and disk encryption is the right answer to it. It is not the threat HIPAA is worried about. HIPAA is worried about whether someone with a credential, working through normal access paths, can see patient data in clear text. Disk encryption does not stop that. The disk is decrypted as soon as it is mounted. A consumer reading from a topic gets clear-text bytes back.
Encrypting payload at the Kafka protocol layer is the solution. You encrypt fields before they hit the broker, and you decrypt them on read for clients that are authorized. The data on disk is encrypted in a way that mounting the volume does not undo.
There are two ways to do this:
- In the application. Every producer team ships crypto code and stays aligned on key versions, algorithms, and KMS policy. It works on paper. In practice, it's the sprawl pattern I wrote about in Stop Building Kafka Encryption Libraries.
- In a proxy in front of the brokers. The proxy intercepts produce and fetch requests and applies the encryption transparently, decoupling the security model from the application teams' release cycles.
The proxy approach is what Conduktor Gateway does. A field-level encryption interceptor lives at the proxy, not in the producer. You declare which topics carry sensitive fields and which KMS holds the keys, and that is the whole configuration. The producer publishes a normal record; the proxy encrypts ssn, dob, diagnosis before the bytes reach the broker; an authorized consumer reads back plaintext, an unauthorized one reads ciphertext. The producer code never knows.
The same proxy handles the destruction-of-records workflow with the same primitive. Throw away a patient's key and their data across every topic becomes unreadable in the same moment, without rewriting any of Kafka's append-only log. This is crypto-shredding — the same mechanism that handles GDPR Article 17.
MFA, network segmentation, and 1-hour access revocation
Three other NPRM beats fail in the same shape as encryption: each is easy to think you've met until you look at the architecture.
- MFA. Only counts when the IdP enforces it and the UI consumes that identity through RBAC. A Kafka UI that claims to "do MFA" itself is suspicious.
- Network segmentation. Kafka clusters sharing a flat network with non-PHI workloads fail. The pattern that works: brokers on dedicated subnets, Gateway as the only ingress, partner zones for any cross-network sharing.
- 1-hour workforce access revocation. Works if SSO deprovisioning is wired into your RBAC. Painful if your ACLs are tied to long-lived static credentials.
For the requirement-by-requirement walkthrough with config snippets and the Conduktor controls that satisfy each, see HIPAA 2026 and Kafka: Securing ePHI Streams.
What this is really about
HIPAA 2026 is interesting less for its specific requirements than for what it reveals: streaming systems don't fit the "data at rest" abstraction the rule was written around. The fix is real architecture — field-level encryption, IdP-enforced access, a topic catalog that knows what it has. Book a demo to see the proxy and catalog in action.