No. If you do not define the inter-broker listener, Kafka determines it from security.inter.broker.protocol, which defaults to PLAINTEXT. Each listener has its own security protocol, so you must set encryption and authentication per listener: SSL, SASL_PLAINTEXT or SASL_SSL, never PLAINTEXT for traffic that matters.
How Kafka listeners work
The Kafka documentation (4.1) explains that each server defines the set of listeners that receive requests from clients and from other servers. The listeners property takes a comma-separated list in the form name, host and port. The security protocol of each listener lives in a separate setting, listener.security.protocol.map, which maps each listener name to a protocol.
The four protocol options are PLAINTEXT, SSL, SASL_PLAINTEXT and SASL_SSL. The documentation says PLAINTEXT provides no security and needs no extra configuration.
| Protocol | Encrypted | Authenticates clients with SASL |
|---|---|---|
| PLAINTEXT | No | No |
| SSL | Yes | Through client certificates if you require them |
| SASL_PLAINTEXT | No | Yes |
| SASL_SSL | Yes | Yes |
The SSL row reflects how TLS client authentication works, which is covered in Kafka TLS client auth required vs requested.
The inter-broker listener
The primary job of the inter-broker listener is partition replication. You pick it by setting inter.broker.listener.name. The documentation says that if you do not, the listener is determined by the security protocol in security.inter.broker.protocol, whose default is PLAINTEXT. That is the quiet default to check. A cluster can have an SSL listener for clients and still replicate data between brokers in plaintext, because the second path was never configured.
The documentation's own example maps a CLIENT listener to SSL and a BROKER listener to PLAINTEXT, to show the syntax. Do not copy that mapping into production.
Steps to review
- Print the effective values of listeners, listener.security.protocol.map, inter.broker.listener.name and security.inter.broker.protocol on every broker.
- Write the intended protocol for every listener, including the inter-broker one and, for KRaft, the controller listener.
- Replace PLAINTEXT with SASL_SSL or SSL. Choose SASL mechanisms using Kafka SASL mechanisms compared.
- Give listeners explicit names. The documentation recommends this because it makes the intended use clearer than naming a listener after its protocol.
- Roll the change through the cluster carefully. Add the new listener, move clients and brokers over, then remove the old one. Plan for a rolling restart.
- Verify from a client host that a PLAINTEXT connection to the broker is refused.
- Pair transport security with authorization. A TLS connection with no ACLs is still wide open, see Kafka allow.everyone.if.no.acl.found risk.
Separate listeners for separate jobs
The documentation says it is conventional to use a separate listener for clients, which lets you isolate inter-cluster listeners at the network level. In practice that means the replication port is reachable only from other brokers, while the client port is reachable from application networks. Two listeners also let you use different security settings if you have a legacy client that cannot yet use the new protocol, so you can limit the weaker path to a specific network rather than weakening everything.
Why this matters
Replication carries every message in every topic. If a network segment between brokers is shared or monitored, plaintext replication exposes the contents of topics even when client traffic is encrypted. Treat the broker network as hostile enough to need encryption, particularly in multi-tenant clouds and across availability zones.
Safeguard's policies and gates can check broker configuration in pull requests, and its asset discovery helps you find clusters nobody inventoried. The free scan covers your code and dependencies.
Quick check
If clients connect over TLS, is my cluster encrypted?
Only the client path. Check the inter-broker listener and the controller listener separately, since they are configured on their own.
Do I have to name my listeners after protocols?
No. You can name them by purpose, such as CLIENT and BROKER, and map each name to a protocol. The documentation recommends explicit names.
Sources
Last reviewed: 19 October 2026.
