Matrix security hardening guide

Why Matrix security hardening starts with federation and listeners

Hardening a Matrix homeserver starts by deciding which parts of it can be reached, by whom, and from where. For an organization with confidentiality requirements, the homeserver should accept connections only from the networks and identity systems it intends to trust, and the federation listener, client listener and admin endpoints should each be exposed on purpose rather than by default. Federation and listener exposure come first because every other control, from registration to key backup, sits behind them. Public Matrix communities are built to be open. Synapse, the most widely documented homeserver, federates on port 8448 by default, and its federation_domain_whitelist setting is a useful lever: an empty list disables federation, and the Synapse documentation recommends firewalling the federation listener as well. Defaults that let any server on the internet exchange events with yours suit a public network, but they are a poor fit for a private deployment where room metadata and membership are themselves sensitive. The reader should confirm, for each listener, which hosts can reach it and whether that matches the written data-handling policy. The wider attack surface includes the client listener, the admin API, open registration, trust placed in the identity provider, direct database and Redis access, and media storage. Each needs a decision. Admin endpoints should not be reachable from user networks. Registration should be closed or tied to the identity provider. Identity provider trust depends on whether Synapse's oidc_providers, saml2_config or CAS settings, or Matrix Authentication Service with an upstream OpenID Connect provider, is the single sign-in path. PostgreSQL and Redis should accept only the homeserver and worker hosts. Media storage needs the same access scrutiny as message data. A hardened homeserver is expected to expose only the listeners it needs, refuse federation with domains outside an approved list, require authentication for every account, keep admin functions off the public path, restrict database and cache connections, and be upgraded on a schedule the team can actually keep. Each of these is documented in Synapse's configuration manual and upgrade notes, and each should be verified against the running system. This work is harder than changing settings. The controls span Synapse, its reverse proxy, firewall rules, the identity provider, client configuration and the upgrade cadence, and a change in one place can break another, such as a proxy that forwards the wrong port or a client that cannot reach the identity provider. DeployOpen prepares and configures these controls and documents the evidence for an assessment. It does not issue audit reports or certifications; independent auditors and certification bodies do that work.

Which Synapse listeners, settings and dependencies need controls

Synapse exposes several listeners, settings and back-end services, and each one carries a separate security decision. The cards follow a request from the network edge to stored data, then cover sign-in and file storage. Confirm exact setting names and resource lists against the Synapse configuration manual for the version you run before you change production.

Federation listener and domain allowlist

The federation listener accepts server-to-server traffic, on port 8448 by default. Any server that can reach it can attempt to exchange events with your homeserver, so this is the first surface to decide. Use federation_domain_whitelist to limit federation to named domains, or set an empty list to disable federation entirely. The Synapse documentation also recommends firewalling the federation listener, so confirm that the setting and the network rule both match your federation policy.

Client traffic, delegation and reverse proxy

Clients reach Synapse over HTTPS on port 443, usually through a reverse proxy. The server_name setting fixes how user IDs such as @user:example.com and room identifiers are formed, and delegation lets that name be served from another host on port 443. Choose server_name before users exist. Check that the proxy forwards only the client and federation paths you intend to expose, and that its TLS settings meet your policy.

Registration and sign-in settings

Registration settings decide who can create an account without an administrator. Review whether open registration is enabled, whether registration requires a token, and whether accounts come only from your identity provider. If you use Matrix Authentication Service, sign-in runs through an upstream OpenID Connect provider such as Keycloak or Microsoft Entra ID, and MAS does not support SAML directly. Test that each disabled path stays disabled.

Admin API resources

The admin API lets privileged callers read and change users, rooms and server state. It should not be reachable from the public internet or from general client networks. Restrict admin resources at the reverse proxy and through network policy, limit administrative tokens to a small group of operators, and log their use. Review the resource list in the configuration manual against what your operators actually need before go-live.

PostgreSQL and Redis back ends

PostgreSQL stores events, account data and key material, so its access controls, encryption and backups protect the most sensitive data in the deployment. Redis relays replication between the main process and workers, so it should sit on an internal network with no public listener and with authentication enabled. Check the PostgreSQL and Python minimums in the upgrade notes for your Synapse version before you choose database versions.

Media storage access and retention

Media storage holds files and images that users upload, and those files can be as sensitive as message content. Decide where media is written, who can download it, and how long it is kept. Confirm whether media downloads require authentication in your Synapse version, and whether the reverse proxy limits upload size. Test that deleted media is removed from storage as your retention policy requires.

Choosing a federation, registration and key policy for your risk profile

This table compares the main Matrix hardening decisions: federation, registration, end-to-end encryption key backup, and admin API exposure. Each option lists when it fits and what it costs to run, so you can match settings to your data classification rather than to a default. Read each row against your own classification and identity setup before choosing.

Decision	Option	When it fits	Operational cost
Federation	No federation (empty federation_domain_whitelist, listener firewalled)	Confidential data that must stay inside the organization and no external Matrix contacts are needed	No contact with external Matrix users or rooms; you must confirm no internal workflow depends on outside servers
Federation	Federation limited to named partner domains	Known partner organizations need shared rooms and you can name and review each domain	Ongoing allowlist maintenance as partners change; the listener still needs firewall rules for allowed peers
Federation	Open federation	Public-facing communities or collaboration where any Matrix server may join rooms	Broadest exposure of metadata and content to external servers; you need moderation and abuse handling
Registration	Closed registration, accounts provisioned through the identity provider	Workforce with a central identity provider and a documented joiner and leaver process	Account lifecycle work: provisioning, deprovisioning and reviewing deactivated accounts in the identity provider and Synapse or MAS
Registration	Open registration with administrator approval	Small or semi-external groups where invitations are reviewed by an owner	Approval queue staffing and a process to verify who is requesting an account
End-to-end encryption	Default encryption with users managing their own keys	Teams accept that a lost device can mean lost history and have a recovery procedure	Support requests for lost keys and device verification; a user education effort at rollout
End-to-end encryption	Required key backup managed by the organization	Regulated data where message history must be recoverable and an assessor expects key recovery controls	Key backup governance, recovery procedures and a decision on who can access recovered keys, which must be designed and tested
Admin API	Admin API reachable only from an internal network	Organizations that manage Synapse from controlled administrative hosts or a private network	Administrators must connect through VPN or internal hosts; scripted tasks must run inside the network
Admin API	Admin API reachable through a bastion	Remote administration is needed and the bastion provides audited, MFA-protected access	Bastion hardening, access reviews and logging to maintain; confirm the bastion meets your own control requirements

How to harden a Matrix homeserver step by step

This sequence takes a Synapse homeserver from a default install to a baseline that controls who can reach it, who can join it, and what is exposed to the network. Each step ends with a check the team runs and records, so the finished baseline can be repeated after upgrades and configuration changes.

Pin the Synapse release and dependencies
The platform team chooses one Synapse release, records it in the deployment configuration, and checks it against the upgrade notes for the PostgreSQL and Python versions it requires. The notes state that Synapse 1.143.0 and later need PostgreSQL 14 or newer, and that 1.142.0 and later need Python 3.10 or newer, so confirm both before installing. Read the notes for every release between your current version and the target, because rolling back can be difficult after database schema changes. Closing check: the running Synapse, PostgreSQL and Python versions are written into the baseline and match the notes for the pinned release.
Set server name and federation delegation
Set server_name before any users or rooms exist, because it fixes how user IDs such as @user:example.com and room identifiers are formed. Changing it after accounts exist is a migration project, not a configuration edit. If the homeserver runs on a different host from the domain in user IDs, publish delegation so clients and other servers find it on port 443. The administrator with DNS access does this work. Closing check: the delegation endpoint for the domain returns the expected host, and a test account shows the intended domain in its user ID.
Set the federation allowlist and firewall port 8448
Decide the federation policy first: open federation, a list of partner domains, or no federation. In Synapse, federation_domain_whitelist restricts federation to the listed domains, and an empty list disables federation. Then block inbound traffic to the federation listener, which uses port 8448 by default, and allow it only from peers you have agreed to. The network engineer applies the firewall rules and the platform team confirms the policy. Closing check: a connection to the federation port from an unlisted host is refused, and a request from a listed domain succeeds as the policy states.
Restrict client and admin paths behind TLS
Place the client listener behind a reverse proxy that terminates TLS, and publish only the client API paths that users need. Do not route admin API paths through the public proxy. Serve them on an internal listener or path reachable only from administration networks, and keep administrator credentials separate from ordinary user accounts. The network engineer builds the proxy rules, and the administrator confirms access. Closing check: an admin path requested from outside the admin network is refused, a client login over HTTPS succeeds, and the proxy configuration is saved in version control.
Close open registration and connect identity provider
Disable open registration in the homeserver configuration so accounts are created only by administrators or through the identity flow. Then connect sign-in to your identity provider. Synapse supports OpenID Connect through oidc_providers, SAML2 through saml2_config and CAS. Matrix Authentication Service works with upstream OpenID Connect providers such as Keycloak, Microsoft Entra ID, Google and Authentik, and does not support SAML, so a bridge such as Dex is needed for SAML or LDAP. Closing check: an unauthenticated account creation request is refused, a test user signs in through the provider, and the team records which login methods remain enabled.
Isolate database, Redis and media storage
Place PostgreSQL, Redis and media storage on private network segments that only the homeserver and its workers can reach. Synapse documentation recommends PostgreSQL for production, and Redis relays replication between the main process and workers, so neither should be reachable from client networks or the internet. Move database and service credentials out of configuration files and into a secrets store or environment injection managed by the platform, and restrict file permissions on anything that remains. Closing check: a connection to the database or Redis port from a client network fails, the homeserver starts using secrets from the store, and a search of the configuration files finds no passwords.
Set end-to-end encryption defaults and key backup
Decide the encryption defaults for new private rooms and direct messages, and record them for the client team. Write user guidance on key backup and recovery so people know how message keys are restored on a new device, then test that recovery path with a pilot group before rollout. Confirm the exact settings in the Element client version you deploy, because menu names and defaults change between releases. Closing check: a newly created private room shows encryption enabled in the client, a pilot user restores keys from backup on a second device, and the guidance is stored with the baseline.
Document the baseline and repeat checks
Write a baseline record that lists the pinned Synapse and dependency versions, the federation policy, listener and firewall rules, identity setup, secret locations and encryption defaults, with an owner and a last-reviewed date for each setting. Store it with the configuration in version control and attach the results of the checks from the earlier steps. Repeat the relevant checks after every upgrade, configuration change or new worker. Closing check: an engineer who did not build the system can rerun the checks from the document alone and reach the same results.

What drives hardening effort for a confidential Matrix deployment

This table lists the factors that move hardening effort for a confidential Matrix deployment and how to contain each one. Read each row as a scoping question: the middle column explains why the factor adds work, and the last column names the design choice that keeps it manageable. Federation policy, identity design and environment count usually set most of the effort, so decide them before any build starts. Internal staff time and partner fees both follow these drivers.

Driver	Why it changes effort	How to keep effort down
Number of environments	Each environment needs its own hardened configuration, secrets, certificates and test evidence, so work multiplies with each one.	Keep one reviewed configuration baseline and render production, staging and test from templates, changing only server name and secret references.
Federation and partner domains	Open federation is the widest exposure. Each allowed partner domain adds trust decisions, listener firewalling and testing.	Decide policy first. Use a short, reviewed federation_domain_whitelist, or disable federation if no partner needs it.
Identity provider complexity	Synapse accepts OIDC, SAML2 and CAS directly, but Matrix Authentication Service needs OIDC upstreams and a bridge such as Dex for SAML or LDAP.	Standardize on one upstream OIDC provider where possible and confirm SAML or LDAP bridge needs before the design is signed off.
Workers and load balancer layers	Each worker type, the Redis link and every proxy layer adds listeners and routes that must be exposed and locked down.	Use standard reverse proxy patterns with a written route table, and expose only the listeners each worker type needs.
Network segmentation maturity	Hardening is easier where admin, client, federation and database zones already exist. Missing zones add design and approval work.	Reuse existing zones and documented flow rules. Confirm admin API paths sit on a management network before the build starts.
Existing firewall and secrets tooling	Rules must follow the client's firewall format, and signing keys and database credentials must fit its vault and rotation process.	Reuse the current firewall change process and secrets store instead of adding parallel tooling that needs separate reviews.
Client platforms in use	Each client platform affects registration, key backup, device verification and end-to-end encryption defaults, and needs its own test pass.	Limit supported clients to a short list and test each one against the same reference configuration.
Internal review cycle for each change	Configuration changes, patches and firewall rules may need approval and dated evidence, which adds elapsed time to every update.	Batch changes into scheduled windows, pre-approve standard patch baselines, and keep evidence generated by the deployment pipeline.

How hardening changes on single node, worker-based and Kubernetes deployments

On a single host, Synapse, the reverse proxy, the firewall and the database usually share one machine, so hardening is mostly about boundaries on that host. The Synapse documentation recommends PostgreSQL for production, with SQLite also supported, so a team with confidentiality requirements should treat SQLite as a development or very small pilot choice and confirm the database decision early. Because one host carries every listener, a single misconfigured bind address can expose an admin or replication port.

Controls that change:

Bind Synapse's client listener to localhost and let only the reverse proxy reach it, instead of exposing the application port directly.
Restrict port 8448 at the host firewall if federation is disabled or limited to a domain allowlist, and confirm the federation_domain_whitelist setting matches that choice.
Keep PostgreSQL on a private interface or the same host with local-only access, and restrict the database user to the Synapse database.
Apply operating system patching and Synapse upgrades on the same maintenance window, since one reboot or failed upgrade takes every service down.

New failure points:

A single disk filling up stops the database, media storage and logs together.
A host compromise exposes the signing keys, database and media store at once.

What to verify: confirm from outside the host that only the intended ports answer, that the admin API is not reachable from the public internet, and that a restore from backup works on a second machine.

Access control, secrets and logging controls for Matrix security hardening

These controls decide who can reach a Matrix homeserver, its administrative surfaces, its database and cache, and the secrets that unlock them. Each card names the threat it addresses and the setting or infrastructure element that enforces it. Exact configuration keys change between Synapse and Matrix Authentication Service releases, so confirm each key in the version you run before relying on it.

TLS termination at the reverse proxy

Decide where TLS ends: at a reverse proxy in front of Synapse or inside the homeserver listeners. Terminating at a proxy centralizes certificate renewal and cipher policy, but the hop between proxy and homeserver must still be protected or confined to a private network. Check that the federation and client listeners both present valid certificates, that plaintext listeners are not exposed, and that forwarded headers are trusted only from the proxy address.

Restricting admin and metrics endpoints

Administrative APIs and the metrics listener expose user data, room metadata and internal state, so they should never be reachable from the public internet. Enforce this with listener configuration that binds these resources to internal interfaces, plus firewall or proxy rules that allow access only from management networks. Confirm which resource names are served on which listener in your version and test the restriction from outside your network.

Secret storage for database credentials

The PostgreSQL password in the homeserver configuration file is readable by anyone with access to that file and often ends up in backups and configuration management repositories. Move the credential into a secrets manager or a root-readable file supplied at runtime, restrict file permissions to the service account, and rotate it on a defined schedule. Confirm whether your version reads database passwords from a separate file or environment source.

Registration shared secret and OIDC client secrets

The registration shared secret lets a holder create accounts through the admin registration path, and OIDC client secrets let an identity provider trust your homeserver or authentication service. Both grant significant access if leaked. Store each in a secrets manager, scope them to a single component, limit who can read them, and rotate them after staff changes. Confirm which values are needed in your chosen deployment model, since Matrix Authentication Service handles authentication differently from Synapse's built-in SSO.

Least-privilege database and Redis roles

A homeserver usually needs to read and write its own schema, not create databases, change roles or access other applications' data. Create a dedicated PostgreSQL role with only the grants Synapse needs for its schema, and keep migration privileges separate from runtime privileges. For Redis, which relays replication between workers, enable authentication, bind it to the private network, and disable dangerous commands if your Redis distribution supports that. Confirm the exact grants required for the version you run.

Media retention and access controls

Uploaded media can contain the most sensitive content in a deployment and is often retained longer than messages. Define how long remote and local media is kept, who can reach media endpoints, and whether media is served only to authenticated users in your version. Check the media store's own access policy, backup coverage and deletion behavior, because removing a message does not always remove its attachments.

Audit logging of administrative actions

Administrative actions such as account creation, deactivation, room administration and configuration changes need a record that is kept outside the homeserver and protected from its administrators. Forward homeserver and proxy logs to a central store, record who used the admin API and from which address, and set retention to meet your policy. Confirm which admin actions Synapse logs natively and which require a proxy or an external audit tool.

Removal of default and test accounts

Test accounts, sample users and default administrative accounts created during evaluation are a common route into a homeserver that was meant to be production-only. Inventory every account and disable or delete those created during setup, change any default passwords, and confirm that guest access and open registration are off unless deliberately enabled. Repeat the inventory after each migration or upgrade, since restored databases can bring old accounts back.

How to test that Matrix security hardening holds and fails safely

The hardening controls for a Synapse deployment are only worth what you can show they still do. Test each control from outside the trust boundary, using a network position that matches the party you are trying to keep out. A check run from inside the homeserver subnet proves little about what an unauthorized user on the corporate LAN or the internet can reach. Start with a written list of controls, the expected result for each, and the network segment the test runs from. Use the same test host, or hosts in the same segments, every time so results stay comparable across runs.

For the federation listener, confirm that the port used for federation, 8448 by default, does not answer from untrusted networks. Then confirm that a server not on federation_domain_whitelist is refused when it tries to federate. If your policy is to disable federation, the whitelist should be empty and the listener should not accept connections at all. Check both the firewall result and the application result. A closed port and a refusing application are different failures, and you want evidence for each. For admin endpoints, confirm they are unreachable from user networks and from the internet, and that a request from an allowed management network is answered as designed. For registration, send an anonymous registration request and confirm it is refused. For client paths, confirm that plain HTTP is not served and that the redirect or refusal behavior matches your design.

The fail-safe tests matter most. Stop the identity provider that Synapse or Matrix Authentication Service depends on, then attempt a login. The expected result is a refusal, not a fallback to local passwords or an anonymous session. Stop the PostgreSQL database and confirm that Synapse returns errors rather than accepting writes it cannot store or serving data without authentication. Record what each service does during the outage and when it recovers. Ask your vendor or implementation team to confirm the exact behavior of your Synapse version, because it depends on configuration. Run these tests in a non-production environment first, and only run outage tests in production under an approved change window with a rollback plan.

Repeat the full test set after every Synapse upgrade, and after any change to listeners, reverse proxies, firewall rules, identity settings or worker layout. Upgrades can change defaults, add listeners or alter how configuration keys are read, so a control that held on the previous release may not hold on the next one. The upgrade notes for Synapse describe schema changes that can make rollback difficult, so treat the re-test as a gate before the upgrade is declared complete, and keep a tested backup to restore from if it fails. Store each run with its date, the Synapse version, the configuration hash or change reference, the tester and the raw output.

Record each result as evidence in a form that a reviewer can follow without asking you questions. For each control, keep the test description, the source network, the command or request used, the expected result, the observed result, and the decision on any deviation. Internal reviewers use this to confirm that controls operate as designed. External auditors then decide how much reliance to place on it, through their own sampling and testing. DeployOpen prepares systems, controls and this kind of evidence for those assessments, but it does not issue audit reports, attestations or certifications, and that decision belongs to the independent auditor or certification body your framework requires. Confirm with that auditor which evidence format and retention period they expect before you start.

Patching, backups and documentation after Matrix security hardening

Hardening holds only while the homeserver keeps receiving upstream fixes, its data can be restored, and the people running it can explain every change. The cards below cover the recurring work after go-live, who owns each task, and what to check before a change reaches production.

Track Synapse releases and upgrade notes

Watch the Synapse releases page on GitHub, which listed v1.163.0, published October 14, 2026, as the latest release at the time of writing. Read the upgrade notes for every version between your current release and the target before any change, because they flag configuration renames, removed options and required database steps. Assign one named owner to review each release and record the decision to accept, defer or schedule it.

Plan for difficult rollbacks

Synapse upgrade notes warn that rolling back can be hard because database schema changes can be one-way. Before each upgrade, take a verified PostgreSQL backup and a copy of the configuration files, and write down the exact point after which reverting means restoring from backup instead of downgrading. Test this path on a staging copy of the database so the team knows how long a restore takes.

Keep Python and PostgreSQL supported

Synapse drops support for Python and PostgreSQL versions once they reach upstream end of life, and recent releases set minimums such as PostgreSQL 14 or newer for 1.143.0 and later and Python 3.10 or newer for 1.142.0 and later. Track the end-of-life dates of both runtimes against your Synapse upgrade plan so a platform update never forces an unplanned Synapse change. Confirm the minimums for your target release in its upgrade notes.

Back up PostgreSQL and media with restore tests

Back up the PostgreSQL database and the media store together, because message history references uploaded files that must match the same point in time. Schedule restore tests into a separate environment and record the time taken and any manual steps. A backup that has never been restored is not evidence that the homeserver can recover.

Monitor listeners, federation and registration

Alert on listener availability for client and federation endpoints, and review logs for failed federation attempts and registration requests. Once federation is restricted, a spike in rejected remote servers can indicate misconfiguration or an attempt to reach outside the allowed list. Set thresholds with the operations team and document who receives each alert.

Rotate secrets on a fixed schedule

Rotate the registration shared secret if it is used, signing keys, database credentials, OIDC client secrets, and any admin API tokens. Store each secret in a managed vault and log every rotation with its date and owner. Rotating a secret used by an identity provider or bridge also requires a coordinated change on that side.

Review federation whitelist and accounts

Review the federation_domain_whitelist and the list of local accounts and admins on a set cadence agreed with the data owner. Remove partner domains that are no longer active and deactivate accounts for leavers, including accounts created for bridges or bots. Each review should be recorded so that auditors can see who approved the current state.

Keep a change log tied to the baseline

Maintain a change log that references the hardening baseline document and records each configuration change, upgrade, firewall rule and access decision with its approver. When a later change conflicts with the baseline, the log shows whether the baseline or the change should be updated. Keep the log in version control next to the configuration so that it matches what is deployed.

Questions buyers ask before hardening a Matrix deployment

Can our own team harden a Matrix deployment without an outside partner?

Often yes, if the team has the right coverage. Hardening is mostly configuration, firewalling, identity integration and testing, so the team needs people who run Linux services, PostgreSQL, reverse proxies and SSO, and who can read Synapse upgrade notes closely. The bigger question is continuity: who owns the homeserver after the changes, who reviews each upgrade, and who repeats the verification checks. Teams that lack one of these areas usually find the gap during the change window. Ask your engineers to walk through the scope document and mark which parts they can own, then decide where a partner adds the most value.

What drives the cost of hardening a Matrix server?

The written scope sets the cost. The main drivers are the number of listeners and network zones to protect, the federation policy (closed, a partner domain list or open), the number of identity sources to connect, the number of clients and bridges in use, the condition of the existing deployment, and how much evidence your assurance teams need. One-time work covers assessment, configuration, testing and handover. Recurring work covers re-verification after upgrades and patching, which may be sold as a retainer. When you request a quote, ask for each driver as a separate line and for one-time and recurring items to be split. DeployOpen does not publish a price list.

How long does Matrix security hardening take to complete?

Duration depends on the same drivers as cost, plus the current state of the server. A deployment already on supported Python and PostgreSQL versions with a clean configuration takes less time to harden than one that needs upgrades first. Other factors include whether workers and Redis are in use, how many identity providers must be integrated, and how quickly your firewall, identity and change approval teams respond. No duration applies to every deployment, so the timeline comes from the written scope. Ask which tasks sit on the critical path, such as firewall approvals, identity application registration and the maintenance window for restarts.

What does a hardening engagement need from our team?

Access, decisions and a sign-off owner. Expect to provide network access for the work, such as a jump host, firewall rule changes and DNS records. Your identity provider administrators must register applications and confirm claim mapping if SSO is in scope. You will need a change window with a rollback plan, because some Synapse changes require restarts and database work. Your data owners must decide which rooms and media need which protection, what may be federated, and how long logs and media are kept. Name one person who can approve changes and accept the handover.

Can end-to-end encryption be enforced for every Matrix user?

Not by the homeserver alone. Server settings can make encryption the default for certain new rooms and can restrict who registers or federates, but the client still handles encryption, device verification and key backup. Enforcement therefore depends on which clients you allow, their versions, how users are onboarded, and whether key backup is handled under your policy. Ask the partner to show which settings apply to your chosen homeserver and clients, and test with real user accounts on each client. Confirm the exact behavior of each client version with its vendor before you promise users or auditors that encryption is enforced.

Does hardening a Matrix deployment make it compliant?

No. Hardening is one part of compliance. It reduces exposure and produces configuration evidence, but a compliance assessment covers the whole control set: access reviews, log retention, incident response, vendor management, risk assessment and operating records over time. DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Start by choosing the framework that applies to you, then map each control to an owner, a configuration and a test, so the assessor can trace the evidence.

Which Matrix hardening changes break clients, bridges or bots on a live server?

Changes to federation, listeners and the admin API are the most likely to cause disruption. Restricting federation can cut off rooms shared with other servers, changing listener ports can break clients that use hard-coded endpoints, and removing admin API access can stop bots and automation. Bridges and integrations often depend on these paths, so inventory them before any change. Test each change on a staging copy with the same database version. Upgrades can change the database schema in ways that make rollback difficult, so take and verify a PostgreSQL backup before each one and keep the change plan written and reviewed.

How DeployOpen works on Matrix security hardening

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Matrix. For security hardening, we start from a written, fixed scope that names the federation, listener, registration, encryption, admin API and patching decisions, then build and verify each control in your environment before handover.

How we scope

Record the homeserver implementation, version and database in use, and whether Synapse, Dendrite or another server is the target.
Decide the federation policy in writing: disabled, limited to a domain allowlist, or open, with the data control consequences for each.
List which listeners, registration paths, admin API routes and network zones are in scope, and who approves each exception.

How we build

Apply federation restrictions such as the federation domain allowlist setting and firewall the federation listener on port 8448 where it is used.
Configure registration controls, single sign-on paths, end-to-end encryption defaults and key backup behavior, then test them with real user accounts.
Restrict admin API exposure to internal networks, review worker and Redis reachability, and confirm patch steps for Synapse and its Python and PostgreSQL dependencies.

How we hand over

Deliver a configuration record and firewall rule set that map each hardening decision to the setting or network control that enforces it.
Provide verification evidence from test runs, including federation blocking, registration denial and admin API reachability from outside approved networks.
Walk your operations and security staff through change control for federation settings, upgrades and key backup procedures before closing the engagement.

How we support

Engagements are fixed-scope, and the written scope sets deliverables, timelines and what is excluded before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which can cover re-verification after Synapse releases.
Confirm with us during scoping which findings, rollback limits and approval steps your auditors or internal assurance team will need to see.