RabbitMQ offers PLAIN, AMQPLAIN and ANONYMOUS authentication by default. In production, remove ANONYMOUS, keep PLAIN only over TLS, and consider certificate based EXTERNAL authentication for clients you can issue certificates to. The auth_mechanisms setting controls the list.
What the default list contains
The RabbitMQ access control documentation lists the mechanisms. PLAIN is SASL PLAIN and is on by default. AMQPLAIN is a non-standard variant kept for compatibility, also on by default. ANONYMOUS is on by default as well: clients that do not authenticate connect as the configured anonymous login user, which is guest unless changed.
The server offers mechanisms in the order of the auth_mechanisms list, which defaults to PLAIN, AMQPLAIN and ANONYMOUS.
Why ANONYMOUS is the one to remove
The documentation says to remove it in production. The production checklist gives the concrete shape: set auth_mechanisms to PLAIN and AMQPLAIN only, and set the anonymous login user to none. Together with deleting guest, that closes the path where a client connects with no credentials at all.
Check it from the outside. Try connecting without credentials from a test host and confirm the refusal. A setting you have not tested is a hope.
PLAIN and passwords on the wire
PLAIN sends the password to the broker as part of the handshake, so it needs TLS. The production checklist recommends TLS for client connections with peer verification, and notes that self-signed certificates are acceptable only on trusted or isolated networks. It also recommends securing inter-node communication with TLS.
When to use certificates
The EXTERNAL mechanism comes from the rabbitmq_auth_mechanism_ssl plugin and authenticates with the client's x.509 certificate. Any password the client supplies is ignored. This suits fleets where you already run a certificate authority, since the certificate is the credential and rotation follows your certificate lifecycle. The checklist specifically mentions x509 or source address ranges for IoT clients with fixed addresses.
A rough decision guide:
- Few services, strong secrets manager: PLAIN over TLS with one user per service.
- Many clients, an internal CA already in place: EXTERNAL.
- Anything reachable from the internet: TLS, per client users, firewall rules, and connection limits.
A note on the demo mechanism
The documentation also describes RABBIT-CR-DEMO, a challenge-response mechanism it says has security equivalent to PLAIN and is not enabled by default. There is no reason to turn it on in production.
Pair it with the rest
Authentication tells the broker who connected. It does not say what they can do. Follow with permission patterns per vhost, and replace the default account as described in the guest user post.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Will removing ANONYMOUS break my clients?
Only clients that connect without credentials. Those are the ones you want to find, so test in staging first.
Is EXTERNAL always better than passwords?
Not always. It needs certificate issuance and rotation to work well. If you have no CA process, per service passwords over TLS are a fair start.
Sources
Last reviewed: 19 October 2026.
