Matrix Security

Communication Platforms

Authored by:

Jonathan Riss

CertiK

Summary

🔑 Key Takeaway: In Matrix, an unverified session is an untrusted session. Set up a recovery key, cross-sign every device, and remember that the homeserver operator sees room metadata and all unencrypted content.

Matrix is an open federated protocol; Element is its most widely deployed client. Accounts live on a homeserver — the public matrix.org instance, a managed service, or one the project runs itself — and rooms are replicated to every homeserver that has a member in them.

Two properties drive the threat model. First, encryption is per room and per device: a device that has not been cross-signed cannot be trusted, and history is unreadable on a new device without a recovery key. Second, federation means room membership determines data distribution — one member on a hostile homeserver gives that server a copy of the room's events. The controls below address both.

Element renames settings between major releases. Recent Element Web and Desktop builds group these controls under Settings > Encryption; older builds and Element Classic use Settings > Security & Privacy. Check the Element documentation for the current path.

For individuals

These settings apply to a personal Matrix account. Every team member and moderator should configure them.

Account security checklist

Set up recovery (Secure Backup) and store the key offline
- Settings > Encryption > Set up recovery, then save the generated recovery key.
- The recovery key restores encrypted message history and verifies new logins when no other device is available. Without it, losing every signed-in device means permanently losing readable history.
- Store it in a password manager. A recovery key in a chat message or a screenshot is a compromise of every encrypted room the account belongs to.
Verify every session
- Settings > Encryption > Verify this device, or verify from an already-verified device.
- Cross-signing is the control that detects an attacker — including a malicious or compromised homeserver administrator — adding a device to the account. Never dismiss an unexpected verification request; investigate it.
Review signed-in sessions and sign out anything unrecognized
- Settings > Sessions. Remove old clients and any session that cannot be accounted for.
- Sign out sessions on devices that are sold, returned, or lost, not just wiped.
Use a unique, password-manager-generated password
- The homeserver password is the credential that gates every device addition. Reuse of it undoes cross-signing.
Add an email address for account recovery; do not add a phone number
- Email enables password reset. A published phone number allows discovery through the identity server and reintroduces the phone-number exposure Matrix otherwise avoids.
Review discovery settings
- Settings > General (or Discovery) — remove third-party identifiers that do not need to be discoverable.
Disable URL previews and automatic media loading where sensitivity warrants it
- Previews are generated by the homeserver, not the client, but they still reveal that a link was received. Disable per room in Room settings, and globally in Settings > Preferences.
Keep the client updated and install it from an official source
- Encryption bugs are fixed in client releases. Third-party Matrix clients vary widely in their handling of cross-signing and key backup.

Understanding what encryption does and does not cover

Assume the homeserver operator sees metadata
- Room membership, timestamps, device lists, and profile data are visible to server administrators even in encrypted rooms. End-to-end encryption protects message content, not the social graph.
Assume unencrypted rooms are public to every member server
- In a federated room, each participating homeserver stores a full copy of events. An unencrypted room is readable by every one of those server operators.
Treat bridges as additional readers
- A bridge to Telegram, Discord, IRC, or Slack joins the room and decrypts for the far side. Bridging an encrypted room extends its trust boundary to the bridge operator and the bridged platform.
Choose the homeserver deliberately
- A public homeserver is convenient and outsources the trust. A self-hosted homeserver keeps metadata in-house and adds an internet-facing service to defend, patch, and back up. Both are defensible; the default is not.

For team members

Team members who moderate rooms but do not administer the homeserver should:

Complete every item in the checklists above on their own account.
Verify teammates' devices in person or over video, so that green cross-signing status means something.
Publish their full Matrix ID (@name:server) through one project-controlled location. Local display names are trivial to copy; the server part of the ID is the durable identifier.
Report room-level abuse to admins rather than acting alone when a ban would need to apply across several rooms.

For admins

These settings apply to operators who run Matrix rooms and spaces for a community.

Room configuration checklist

Enable encryption at room creation for private rooms
- Encryption cannot be disabled once enabled, and it is not retroactive. Deciding at creation is the only clean option. Leave large public rooms unencrypted deliberately, knowing moderation tooling works better there.
Set join rules to match the room's purpose
- Room settings > Security & Privacy: public, invite only, space members, or ask to join. Private team rooms should never be publicly joinable, and should not be published to the room directory.
Restrict history visibility for new joiners
- Set who can read history to members-only from the point they joined or were invited, so a raid does not hand attackers the full archive.
Disable guest access on rooms that do not need it
Keep power levels minimal and grant 100 rarely
- Default users sit at 0, moderators at 50, administrators at 100. A user cannot demote another user at the same level, so granting 100 is effectively irreversible from an equal position — a compromised administrator account cannot be cleaned up by another administrator.
Record which accounts hold elevated power in which rooms
- Federation makes this easy to lose track of across a space. Audit periodically and demote on departure.

Moderation and abuse response

Deploy a moderation bot for anything larger than a single room
- Draupnir (the maintained successor to Mjolnir) enforces bans, redactions, and policies across every protected room from one control room. Manual per-room moderation does not survive a coordinated raid.
Grant the bot administrator power and keep its control room private
- The bot needs power level 100 in protected rooms. Its control room is a high-value target: restrict membership to the moderation team.
Maintain ban lists and subscribe to shared ones
- Policy lists are themselves Matrix rooms, so lists can be shared between communities. Subscribing to a trusted external list imports that community's judgment — review before subscribing.
Use server ACLs against coordinated abuse
- When abuse comes from a homeserver that tolerates it, banning the server from the room is more effective than banning accounts it can recreate at will. Server ACLs are difficult to reverse cleanly, so document the reason.
Vet widgets, bots, and integrations before adding them
- Widgets run third-party content inside the client, and bots hold room permissions. Apply least privilege and remove anything unused.
Publish the canonical room and space addresses
- Cloned rooms with matching names and avatars are the standard impersonation play. Members need one authoritative page listing real addresses.

Homeserver operations

Running a homeserver makes the project responsible for the data of everyone on it.

Patch the homeserver promptly — Synapse and its alternatives ship security fixes regularly.
Restrict registration — open registration on a project homeserver invites abuse originating from the project's own domain, which damages federation reputation.
Protect server administrator credentials with phishing-resistant MFA — a homeserver admin can add devices to accounts, which is why user-side cross-signing verification matters.
Back up and encrypt server state — and test restoration.
Monitor federation traffic and resource use — for raid and abuse patterns.