HIPAA 2026 and Kafka: Securing ePHI Streams

The 2026 update to the HIPAA Security Rule removes the "addressable" label off encryption. What does this mean?

Before, you could document a mitigation and skip the encryption process, "won't do". That option is gone. Anything that creates, receives, holds, or transmits ePHI has to encrypt it, at rest and in transit. Kafka is one of those things.

Quick note on status. As of May 2026, this is still the NPRM that OCR published in January 2025, not a final rule. OCR keeps May 2026 on its regulatory agenda. Once the final rule publishes, the compliance clock is 240 days: 180 days for substantive requirements plus 60 more for business associate agreements. Every healthcare CISO I talk to is already planning against that timeline, so this post talks about the rule as it stands in the NPRM. If the final rule narrows something, the gaps named here still exist; you just have a few more weeks.

What does a healthcare Kafka cluster look like today? TLS on the broker port, EBS or KMS encryption on the disks underneath, a note in the risk assessment saying "we evaluated and chose these controls". Under the proposed rule, an auditor reading literally will notice that the payload sitting in a topic partition is ePHI in storage. EBS encryption protects the volume if somebody walks out with the disk. It does not protect against a platform engineer running kafka-console-consumer and reading names, diagnoses and SSNs in clear text.

When we bring this up with platform teams, the answer comes back almost verbatim:

"So we're relying on data encryption at rest plus in transit, but we're not doing specifically encryption?" — Platform engineer at a US health-tech company

This is where we get asked: "wait, what is payload and field-level encryption, do we need it?" And that's where the fun begins.

This post walks through the changes that actually hit Kafka deployments, and what each one demands in practice.

What changed in the NPRM

The Notice of Proposed Rulemaking, published in the Federal Register on January 6, 2025, reclassifies several specifications from "addressable" to "required":

Requirement	Current rule	Proposed (NPRM 2025)
Encryption of ePHI at rest	Addressable	Required
Encryption of ePHI in transit	Addressable	Required
Multi-factor authentication for access to relevant electronic information systems	Not specified	Required (with limited exceptions)
Asset inventory + network map	Recommended	Required, reviewed at least every 12 months and after relevant changes
Written verification from business associates that §164.312 technical safeguards are deployed	Not required	Required annually
Workforce access termination	Not specified	Within 1 hour

Once the final rule publishes, covered entities have 240 days to comply: 180 days for substantive requirements plus 60 days for business associates to update agreements.

Technology like MFA and AES-256 encryption is now "low-cost and ubiquitous". Saying it was too hard to set up is no longer defensible.

Encryption in transit, and why TLS is not enough

TLS between producer and broker is necessary, not sufficient. The rule covers ePHI in transit wherever it moves:

• producer to broker
• broker to broker replication
• broker to consumer
• broker to Kafka Connect to downstream sink (database, S3, search index)
• Mirror Maker or Cluster Linking between regions

Audit-ready means TLS is enforced, not just available. Three things to check:

ssl.client.auth=required
listeners=SSL://:9093
inter.broker.listener.name=SSL

No PLAINTEXT listener, even for internal purposes. Any non-TLS connection on the cluster is a finding under the new rule. The places this still sneaks in are mid-migration clusters and on-prem setups where a debug listener gets left behind, not greenfield deployments.

OK — traffic is encrypted in transit now. Producer to broker, broker to broker, broker to consumer, TLS everywhere. A lot of teams stop here, assuming that covers encryption. It does not. TLS protects bytes in flight; the moment they land in a topic partition, TLS is done. The payload itself is still sitting in clear text on disk.

Encryption at rest, payload not just disk

Disk-level encryption (LUKS, EBS, KMS-managed volumes) defends against physical theft of the volume. It does not protect the payload from anyone who can reach the Kafka API or shell into a broker — the broker decrypts blocks to serve them, so every legitimate read returns plaintext.

"We have an encryption agent sitting on top of our brokers for disk-level encryption." — Platform lead at a Fortune-50 health insurer

The NPRM doesn't categorically rule out volume-level encryption, but its threat model (persons with access to relevant electronic information systems) is exactly the gap volume encryption doesn't close. If ePHI is sitting in a patient-admissions topic and an operator can run kafka-console-consumer --topic patient-admissions --from-beginning and see names, diagnoses and SSNs, you have ePHI in clear text accessible to anyone with broker-side access. The fix is field-level or message-level encryption applied before bytes hit the broker. Two patterns.

Application-side encryption, manual:

SecretKey dek = kms.getDek("patient-pii-v1");
String encryptedSsn = encrypt(dek, patient.getSsn());
String encryptedDob = encrypt(dek, patient.getDob());
producer.send(new ProducerRecord<>("patient-admissions", patientId,
    new Patient(patient.getName(), encryptedSsn, encryptedDob)));

This works on paper. In practice it pushes crypto into every producer codebase. Key rotation, algorithm migration, and consumer-side decryption all become application concerns. We've covered why this pattern doesn't survive at scale in Stop Building Kafka Encryption Libraries.

"The burden of ensuring the security of the data falls on the application teams." — Data platform lead at a US public-sector health agency

That is the default state in almost every healthcare org we have seen. The question is whether that default should hold, or whether the platform team owns the crypto so the application teams can ship features.

Proxy-side encryption, via a Conduktor Gateway interceptor:

apiVersion: gateway/v2
kind: Interceptor
metadata:
  name: phi-encryption
spec:
  pluginClass: io.conduktor.gateway.interceptor.EncryptPlugin
  priority: 100
  config:
    topic: "patient-.*"
    kmsConfig: ...
    fields:
      - fieldName: ssn
        keySecretId: gateway-kms://patient-{{record.value.patientId}}
      - fieldName: dob
        keySecretId: gateway-kms://patient-{{record.value.patientId}}
      - fieldName: diagnosis
        keySecretId: gateway-kms://patient-{{record.value.patientId}}

The proxy intercepts produce and fetch requests, encrypts the configured fields on the way in, decrypts them on the way out for authorized consumers. Vault stores a single master key (the KEK); per-patient data encryption keys (DEKs) are derived from patientId and stored encrypted (EDEKs) in a Gateway-managed Kafka topic. See Conduktor's encryption guide for the full configuration reference.

This setup also enables crypto-shredding for the HIPAA destruction-of-records workflow: if all records for that patient are encrypted under the same patient-derived key, and no plaintext copies exist downstream, deleting the EDEK from the Encryption Keys Store makes the ciphertext permanently undecryptable via Gateway.

MFA for every ePHI access path

The NPRM also states that persons accessing relevant electronic information systems must authenticate with at least two factors. The rule names three limited exceptions: unsupported legacy technology with a documented migration plan, emergency "break-glass" situations with compensating controls, and certain FDA-regulated devices. Kafka is not unsupported legacy, not an FDA-regulated device, and browsing a topic to debug a producer is not a break-glass emergency. None of the three carve-outs apply. For Kafka, every human access path is in scope:

• Console UI: engineers browsing topics or inspecting messages
• CLI tools: operators running kafka-* commands against the cluster
• Admin APIs: programmatic admin calls authenticated as a human
• AI coding agents and MCP servers: newer paths the rule never anticipated. Agents that browse topics on a developer's behalf must inherit the human's authenticated identity, not run on shared static credentials.
• Service accounts: not in scope for the MFA requirement (the rule targets humans), but they still need strong credentialing — mTLS, short-lived tokens, or OAuth. Gateway handles all three.

If your platform team uses a Kafka UI with an admin/admin login shared across the team and lets anyone with that password browse patient-admissions, that is a clear finding. Two controls together solve it:

1. SSO with MFA enforced at the IdP (Okta, Entra, Google Workspace with hardware key or TOTP)
2. RBAC at the UI layer that restricts which topics each role can see and consume

Conduktor Console maps OIDC/SAML/LDAP groups to its RBAC permissions. The model is granular per resource (TOPIC, CLUSTER, PLATFORM, ...) and supports prefix patterns:

apiVersion: iam/v2
kind: Group
metadata:
  name: phi-auditors
spec:
  displayName: "PHI Auditors"
  externalGroups:
    - "OKTA-GRP-PHI-AUDITORS"
  permissions:
    - resourceType: TOPIC
      cluster: prod-healthcare
      patternType: PREFIXED
      name: patient-
      permissions:
        - topicViewConfig
        # No topicConsume: auditors can see the topic exists, not its content
---
apiVersion: iam/v2
kind: Group
metadata:
  name: healthcare-engineers
spec:
  displayName: "Healthcare Engineers"
  externalGroups:
    - "OKTA-GRP-HEALTHCARE-ENG"
  permissions:
    - resourceType: TOPIC
      cluster: prod-healthcare
      patternType: PREFIXED
      name: non-phi-
      permissions:
        - topicViewConfig
        - topicConsume
        - topicProduce

Console RBAC governs in-Console access only. Service accounts hitting Kafka directly are a separate concern (mTLS or OAuth, plus Kafka ACLs or Gateway Security policies — ACLs, encryption, masking, audit), and the rule's MFA requirement targets humans, not service accounts. Combined with the field-level encryption from the previous section, an auditor who somehow does consume a message still gets ciphertext for the sensitive fields. Defense in depth, which is also the narrative an auditor wants to see in the risk assessment.

Live asset inventory and network map

The proposed rule asks for a current inventory of every system that handles ePHI plus a network map, reviewed "at least every 12 months and after relevant changes". Read between the lines: live inventory. You have to know what you own.

For Kafka, that turns into a question with a deceptively hard answer: which topics carry ePHI? In a cluster with eight hundred topics, three of which were added last week by a team that didn't tell the platform group, the answer to the auditor is often:

🚫 "The data is temporary, Kafka is just a buffer after all."

Then you explain to them that Kafka has compacted topics, and that stream processing keeps changelogs and other long-term materializations and contexts of their data, all in Kafka, forever.

Three solutions:

• Data classification at the topic level. Tag topics with metadata (data-class: ephi, data-class: phi, data-class: internal). Conduktor Console surfaces this in the catalog. The tag is the artifact the auditor wants.
• Lineage. Where does the data in patient-admissions come from, and where does it land? Kafka Connect sink into Snowflake? An Elasticsearch index? Each downstream is a separate ePHI-handling system the inventory has to list.
• Content detection at the proxy. Topic tags are declarative — they tell you what should be there, not what is. The Conduktor Gateway data quality interceptor runs CEL expressions on every record at produce time and can mark, DLQ, or block records that match. Point it at the topics you have classified as non-PHI, and have it flag records that look like ePHI:

pluginClass: io.conduktor.gateway.interceptor.dataquality.DataQualityPlugin
config:
  policyName: phi-leak-detection
  topicsRegex:
    - "^(public|internal|non-phi)-.*$"   # topics that should NOT carry ePHI
  block: false
  mark: true
  report: true
  rules:
    no-phi-field-names:
      type: CEL
      expression: '!has(value.ssn) && !has(value.mrn) && !has(value.dob) && !has(value.diagnosis)'
    no-ssn-in-free-text:
      type: CEL
      expression: '!has(value.notes) || !value.notes.matches(r"\b\d{3}-\d{2}-\d{4}\b")'

This is the safety net that catches a team producing ePHI into a topic nobody told the platform group about. Records get marked and reported — the platform team gets a signal, the auditor gets evidence the control exists.

Network segmentation and 1-hour access revocation

Two more NPRM requirements hit Kafka deployments directly:

• Mandatory network segmentation. Kafka clusters sharing a flat network with non-PHI workloads will get flagged. Common pattern under the proposed rule: brokers on dedicated private subnets, Gateway as the only ingress, microsegmentation between the cluster, Connect, and downstream sinks. Gateway is also where secure cross-network data sharing happens. Partner zones let you share topics in or out across network boundaries (cloud-to-cloud, on-prem-to-cloud, vendor or contractor access) without replicating data, and field-level encryption stays enforced at the boundary so external partners only see the fields you authorized in clear text. See Sharing Kafka Data with Partners for the DMZ pattern.

• 1-hour workforce access termination. When an engineer leaves, their access to PHI topics has to be revoked within the hour. SSO deprovisioning tied to Console RBAC handles this cleanly. Kafka ACLs tied to long-lived static credentials make it painful.

What this doesn't solve

The proposed rule is broader than Kafka. Encryption in the data warehouse, application databases, S3 buckets, physician laptops, all in scope. This post covers the streaming layer because that is where the disk-encryption-is-enough assumption tends to hide. Cover streaming first, then walk the lineage outward.

If a breach involves ePHI flowing through a Kafka topic, audit logs that can answer "who consumed this topic between Tuesday and Friday" need to exist before the breach, not be assembled after. See Kafka Audit Logging for Compliance and Forensics for the logging stack that supports that question.

Book a demo to see how Conduktor Gateway handles field-level encryption on the data path, and how Conduktor Console adds SSO-driven RBAC and a live topic-level catalog on the human-access path: the controls the proposed HIPAA rule wants you to demonstrate, not just document.