Zammad security hardening

Every hardening control in a self-hosted Zammad deployment should be checked by someone other than the person who configured it, and each check should have an expected result written down before it runs. Start at the edge. Test the TLS configuration on the Nginx or Apache reverse proxy from outside your network, confirm that the certificate chain is complete and trusted by the clients your agents and customers use, and confirm that plain HTTP either redirects to HTTPS or is refused. Then confirm that the application itself is only reachable through the proxy, not on its application port from the public side. Use an external scanner or a second network vantage point for this, since a check run from inside the same subnet will tell you little about what an attacker sees.

Next, confirm that the backing services are unreachable from anywhere they should not be. PostgreSQL, Redis and Elasticsearch should accept connections only from the Zammad application nodes on the application network. Run a port scan from the internet-facing segment, from a user workstation network and from a host in the application tier that is not a Zammad node. Also check the Redis configuration for authentication and bind addresses, because Redis is used for realtime websocket communication and an exposed instance is a common finding. Confirm the Elasticsearch cluster does not answer on its HTTP port outside the private network. Record the exact scan results, not a summary.

Test the policies by trying to break them. Attempt to set passwords that violate the configured minimum length, complexity or reuse rules, and confirm each attempt is rejected with a clear message and that the attempt is logged. Enable two-factor authentication for a test agent, then attempt login with a wrong code, an expired code and a replayed code. Confirm that repeated failures lock or slow the account according to your policy, and that recovery codes and reset flows cannot bypass the second factor. Repeat the role tests for each group: sign in as an agent who belongs to one group and try to open, search for, merge or reply to tickets owned by another group, both directly by URL and through the API. A permission test that only uses the web interface misses API access, so include both.

Fail-safe tests show what happens when a control or dependency breaks. Stop Redis on the staging copy and observe whether Zammad degrades in a way that stops users from acting on stale data, or whether it returns errors that leak internal hostnames. Stop Elasticsearch and confirm that core ticket creation and viewing still work, that search fails with a controlled message, and that no ticket data is written to an unexpected location while the index is unavailable. Check whether sessions expire after the inactivity period you configured and after logout, and whether a session token remains valid after a password change. Trigger error pages deliberately, using malformed requests and missing records, and confirm that responses do not display software versions, stack traces, file paths or database errors.

Run this full set on a staging copy that matches production configuration, after each security release and before any change to the proxy, database or role model. Zammad has published security releases in parallel on more than one line, so a release for the version you run may arrive while you are busy with another line; check the Zammad releases page for each one and treat its arrival as a trigger for the test cycle. Keep the test scripts, scanner configuration, timestamps, tester names and results in a dated record. This record is the evidence an auditor or internal reviewer will ask for, and it is also how you show that hardening held after an upgrade. Ask your implementation partner to confirm in writing which of these tests they will run, which they expect you to run, and how failures are reported and retested.

The hardening work does not end at go-live. Someone must own the release watch, and that owner needs to know which release line each Zammad instance runs. Zammad published security releases for two lines in parallel: 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026 for the 7.2 line, and 6.5.5 on 15 October 2026 for the 6.5 line. An instance on 6.5 cannot wait for a 7.2 patch, and a 7.2 instance does not receive 6.5 fixes. Subscribe to the Zammad releases page, record the line and version of every instance, and assign a named person to read each advisory the day it appears. Every security release should pass through a staging copy before production. Rebuild staging from current production configuration, including the reverse proxy settings, the Redis and PostgreSQL connection details and the Elasticsearch and Memcached settings where they apply. Then retest the paths that a patch can break: agent and customer login, any SAML or OpenID Connect sign-in, inbound email and outbound notifications, attachment upload and download, and a search that depends on Elasticsearch. Time the rebuild on your own hardware and record it, because that figure becomes your planning input for the next emergency. Two routine checks catch problems that patches do not fix. First, monitor TLS certificate expiry on the reverse proxy, whether it runs Nginx or Apache, and alert well before the expiry date so renewal is never an emergency. Second, review admin accounts and failed logins on a fixed schedule. Confirm that every administrator still needs the role, that departed staff are disabled, and that repeated failed sign-ins are investigated against the password and two-factor policy you set. Keep the review date and the reviewer's name in the same record as the patch log. Backups need a restore test, not just a successful backup job. Restore the PostgreSQL database and the attachment store into a separate environment at least on a regular cycle, then open tickets with attachments and confirm they render. Confirm with your team whether the Elasticsearch index is restored from backup or rebuilt after restore, because that choice affects recovery time. Record the last successful restore test, its result and any gaps. The documentation set should contain four items: the hardening baseline, a version and release date log for each instance, a register of exceptions with an owner and review date for each one, and a written emergency patching procedure stating who approves an out-of-cycle change, what staging shortcut is acceptable, how to roll back, and who informs agents. If you buy a self-hosted support subscription, the pricing page lists annual fees of 2,999 EUR (Business), 5,999 EUR (Enterprise) and 9,999 EUR (Corporation) and response targets of 6, 4 and 2 hours. Before relying on a tier, confirm in writing whether it covers security releases, emergency assistance, and components outside Zammad such as PostgreSQL, Redis and Elasticsearch.