Your Kafka is encrypted but a stolen password still reads everything.

If one of your Kafka credential leaked today (a single producer or consumer password) what would the person holding it actually be able to read?

We ask this in discovery calls. Almost always the same answer of “we’re fine, we have TLS, and the volumes are encrypted at rest.” Sometimes they do it with a bring-your-own-key, so the at-rest keys are wrapped by a key in the customer’s own KMS.

That’s good, but these layers are passive and miss the path that really matters.

Think how generally supply attacks go: an attacker only needs to have a bootstrap address, network access, and a credential lifted from a public GitHub commit, a CI log, or a Slack message. They connect to the Kafka API like any authorized client would. And the broker, doing exactly what it was built to do, serves them readable data.

TLS and encryption-at-rest are passive

Each encryption layer is designed against a different adversary and manage a different risk. TLS and encryption-at-rest are not about leaked credentials.

• TLS defends against someone on the wire : a man-in-the-middle, a sniffer between client and broker.
• At-rest encryption defends against someone who walks off with the storage : a copied snapshot, a decommissioned volume, a physical disk.
• BYOK adds custody and a kill switch: the storage keys are wrapped by a key you control (not the provider). Removing that key makes the whole cluster unreadable. That’s good against a provider you’re offboarding.

Now think about it: with the 3 layers, the Kafka API read path still has no encryption layer on it. The attacker with your credential simply is an authorized client.

What a single leaked credential actually buys

The blast radius can be massive.

• Consuming starts from the earliest available offset, so the attacker gets whatever your retention holds : a week, a month, and with tiered storage enabled, potentially years of traffic.
• On a compacted topic they get the current value of every key, which is to say the whole customer table or order table this happens quite a lot when using Kafka Streams, KTables etc.).

Also, if they’re smart, they won’t join a consumer group that shows up in your Kafka UI. They’ll assign partitions directly: no consumer group, no committed offsets, you won’t see them. An invisible reader.

The only thing scoping the damage is ACLs, that can easily cover dozens of topics cross-team (because you read other teams data).

This is also why the usual advice to adopt short-lived credentials, while correct, doesn’t close the hole. OAuth tokens that expire in minutes, IAM auth, auto-rotating mTLS : they shrink how long a leaked secret works. They do nothing about what it can read while it works, and draining a topic takes seconds.

Let’s put some perspective here: GitGuardian counted over 28 million new hardcoded secrets in public GitHub commits in a single year, and most credentials confirmed valid years ago were still valid much later.

The reader you can’t see

There’s another authorized reader you don’t see: the managed provider’s own operators.

Every managed service keeps a break-glass path: privileged access for recovery, support, and emergencies.

It means a superuser exists inside the provider’s boundary: at-rest encryption doesn’t touch them, BYOK doesn’t either (the decryption still happens in the provider’s infra). You are trusting the most privileged account in someone else’s cloud not to be compromised or misused.

The only way to close that loophole permanently is to make the data unreadable before it ever reaches Kafka, with a key the provider never holds. Then even break-glass access returns ciphertext. You stop having to extend trust you can’t verify.

The five levels of “we encrypt Kafka”

If you say “we already encrypt Kafka”, ask yourself: at what level?

1. TLS only?
2. TLS + at-rest encryption?
3. TLS + at-rest + BYOK?
4. Payload encrypted before Kafka?
5. Record signing?

Most sit at level 2 or 3. Rarely 4. Almost never 5. The important jump is from 3 to 4. 5 is for heavily regulated industries (banks, FedRAMP)

Levels 1 through 3 protect the infrastructure around the data while level 4 protects the *data itself, *the protection travels with the record.

At level 4, decryption gets its own list of authorized identities, separate from the ACLs stored in the infra. It means that two consumers with identical ACLs can see different things: one reads a card number in the clear, the other gets it encrypted or masked.

If an encryption key leaks, the blast radius is bounded by design: a key maps to a defined set of topics or fields, so it opens that scope and nothing more. Compare that to a leaked storage or BYOK key, whose scope is the entire cluster.

Where the encryption should actually live

Encrypting before Kafka can happen in three places. You can do it in every application: producers encrypt, consumers decrypt which works at small scale but fails once it grows: more programming languages, open access to KMS, Connect workers, Flink jobs, partner apps you don’t control, etc.

You can push it into custom serializers, which is the same usage and maintenance problem. Or you can do it at a Kafka-protocol proxy, where clients connect unchanged, no SDK and no broker modification, and the proxy encrypts on produce and decrypts on fetch only for the service accounts you authorize, with keys in your own KMS, Vault, or HSM.

Note that this same layer can sign records and write an audit log to a topic you own (the level 5 above).

The proxy becomes your trust boundary, which means it deserves the same operational care as your KMS. The architectural win is significant, and it reframes the whole managed-versus-self-hosted debate.

You don’t have to abandon managed Kafka to keep data inside your boundary. You apply payload encryption inside your boundary first, then ship ciphertext to the managed provider.

This way, they do what’s they’re good at: running the brokers and own the availability SLA. What they store is ciphertext under keys they never see.

For regulated workloads (HIPAA’s encryption safe harbor, FedRAMP High), this change the auditor question from “what did the attacker read?” to “who holds the key?” as this is only what matters now.

This is an adapted version of a piece originally published on the Conduktor blog. The original post goes deeper on the threat model and links to the companion writeups on FedRAMP without replatforming and why building your own encryption libraries tends to end badly.