diff --git a/docs/pages/community-management/index.mdx b/docs/pages/community-management/index.mdx
index 8cd9cbfba..46c12916d 100644
--- a/docs/pages/community-management/index.mdx
+++ b/docs/pages/community-management/index.mdx
@@ -15,3 +15,6 @@ title: "Community Management"
- [Discord Security](/community-management/discord)
- [Twitter/X Security](/community-management/twitter)
- [Telegram Security](/community-management/telegram)
+- [Matrix Security](/community-management/matrix)
+- [Session Security](/community-management/session)
+- [SimpleX Security](/community-management/simplex)
diff --git a/docs/pages/community-management/matrix.mdx b/docs/pages/community-management/matrix.mdx
new file mode 100644
index 000000000..06285d04a
--- /dev/null
+++ b/docs/pages/community-management/matrix.mdx
@@ -0,0 +1,105 @@
+---
+title: "Matrix Security | Security Alliance"
+description: "Run a Matrix community safely: federation and homeserver trust, room join rules, power levels, ban lists and server ACLs, and cross-signed operator devices."
+tags:
+ - Community & Marketing
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter } from '../../../components'
+
+# Matrix
+
+
+
+
+> 🔑 **Key Takeaway**: Federation makes room membership a data-distribution decision. Every homeserver with a member in
+> a room holds a copy of it, and every unverified operator device is an unaccounted-for reader.
+
+Matrix community security spans homeserver choice, device verification, room configuration, and federated
+moderation—each covered in depth in the [Matrix Security Guide](/guides/account-management/matrix). Use this page to
+find the right section.
+
+## The community manager's role in security
+
+Matrix is the decentralized option Web3 projects reach for when they want to run community infrastructure they control
+rather than rent. A project can host its own homeserver, keep its own metadata, and remain reachable from every other
+server in the federation. Element is the client most members will use.
+
+That control comes with operator responsibility that Discord and Telegram absorb on the project's behalf. Spam
+filtering, raid response, ban propagation, and abuse handling are the community team's job, executed through room
+configuration and moderation bots rather than a vendor's trust-and-safety pipeline.
+
+What differs most from centralized platforms is the trust boundary. A Matrix room is replicated to every homeserver
+that has a member in it, so admitting one member from a hostile server hands that server a copy of the room's history
+going forward. Encryption limits this to metadata, but many large community rooms are deliberately unencrypted so that
+moderation tooling works — which means content, too.
+
+### Why following this guide is not optional
+
+Matrix's per-device encryption model has an operational consequence community managers meet immediately: an unverified
+session is untrusted. Cross-signing exists so that a device added to an operator account — by an attacker with the
+password, or by a compromised homeserver administrator — is visibly unverified to everyone in the room. Ignoring those
+warnings discards the only signal the protocol provides.
+
+Room defaults are the other recurring failure. Encryption cannot be enabled retroactively and cannot be turned off once
+enabled, history visibility decides how much archive a raid inherits, and power level 100 cannot be revoked by an
+equal. These are decisions made at room creation that are painful to correct afterwards.
+
+### What is at stake
+
+| Risk | Consequence |
+| --- | --- |
+| **Unverified operator device** | Attacker-added session reads encrypted rooms and posts as the team |
+| **Lost recovery key** | Encrypted history becomes permanently unreadable on any new device |
+| **Hostile federated server** | A member from an abusive homeserver gives that server a copy of the room |
+| **Over-granted power levels** | A compromised administrator at level 100 cannot be demoted by another administrator |
+| **Permissive join rules** | Public, directory-listed rooms invite raids and archive scraping |
+| **Bridge exposure** | A bridge to another platform decrypts room content for the bridged side |
+| **Homeserver compromise** | Server operator visibility over metadata, and over content in unencrypted rooms |
+
+The guide addresses these with room-level configuration, moderation tooling, and homeserver operating practice.
+
+## What the guide covers
+
+The guide is structured by scope: personal account first, then room and server operations.
+
+| Scope | What it covers |
+| --- | --- |
+| **Personal account** | Recovery key setup, cross-signing every session, session review, discovery settings |
+| **Encryption limits** | Metadata exposure, unencrypted federated rooms, bridges, homeserver choice |
+| **Room and space operations** | Join rules, history visibility, power levels, moderation bots, ban lists, server ACLs |
+| **Homeserver operations** | Patching, registration policy, admin credentials, backups, federation monitoring |
+
+## Topic index
+
+| Topic | Summary | Guide section |
+| --- | --- | --- |
+| **Recovery key** | Secure Backup key that restores encrypted history and verifies new logins | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **Cross-signing** | Verify every session; unverified devices are the protocol's compromise signal | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **Session review** | Audit signed-in clients and sign out anything unrecognized | [Account security checklist](/guides/account-management/matrix#account-security-checklist) |
+| **What encryption covers** | Content is protected; membership, timestamps, and device lists are not | [Encryption limits](/guides/account-management/matrix#understanding-what-encryption-does-and-does-not-cover) |
+| **Join rules and history** | Invite-only, space-member, or knock rules; restrict pre-join history | [Room configuration](/guides/account-management/matrix#room-configuration-checklist) |
+| **Power levels** | Default 0, moderator 50, administrator 100; grant 100 rarely and audit it | [Room configuration](/guides/account-management/matrix#room-configuration-checklist) |
+| **Moderation bots and ban lists** | Draupnir enforcing bans and redactions across every protected room | [Moderation](/guides/account-management/matrix#moderation-and-abuse-response) |
+| **Server ACLs** | Ban an abusive homeserver from a room instead of chasing recreated accounts | [Moderation](/guides/account-management/matrix#moderation-and-abuse-response) |
+| **Homeserver hygiene** | Patching, restricted registration, admin MFA, tested backups | [Homeserver operations](/guides/account-management/matrix#homeserver-operations) |
+
+For step-by-step procedures, see the [Matrix Security Guide](/guides/account-management/matrix).
+
+## Further reading
+
+- [Matrix Security Guide](/guides/account-management/matrix)
+- [Community Management overview](/community-management/overview): how platform pages fit together
+- [Matrix.org moderation guide](https://matrix.org/docs/communities/moderation/): power levels, ban lists, server ACLs
+- [Element documentation](https://docs.element.io/): client settings and account security
+
+---
+
+
diff --git a/docs/pages/community-management/overview.mdx b/docs/pages/community-management/overview.mdx
index da90b54b1..7bc318045 100644
--- a/docs/pages/community-management/overview.mdx
+++ b/docs/pages/community-management/overview.mdx
@@ -1,6 +1,6 @@
---
title: "Community Management | Security Alliance"
-description: "Secure Web3 communities on Discord, X (Twitter), and Telegram: operator credentials, anti-impersonation, phishing resistance, and incident handoff when channels fail."
+description: "Secure Web3 communities on Discord, X, Telegram, Matrix, Session, and SimpleX: operator credentials, anti-impersonation, and phishing-resistant channel hygiene."
tags:
- Community & Marketing
contributors:
@@ -42,6 +42,12 @@ Deep, step-by-step controls live in the linked account-management guides.
official-channel practices.
3. [Telegram](/community-management/telegram): two-step verification, phone-number privacy, admin permissions, and
man-in-the-group style threats.
+4. [Matrix](/community-management/matrix): federation and homeserver trust, room join rules, power levels, and
+ federated moderation with ban lists and server ACLs.
+5. [Session](/community-management/session): recovery-password custody, Account ID impersonation, and unencrypted
+ Communities run on operator-hosted servers.
+6. [SimpleX](/community-management/simplex): invitation links as access control, local database custody, member roles,
+ and moderation without user identities.
## Related security domains
diff --git a/docs/pages/community-management/session.mdx b/docs/pages/community-management/session.mdx
new file mode 100644
index 000000000..85d815cc2
--- /dev/null
+++ b/docs/pages/community-management/session.mdx
@@ -0,0 +1,102 @@
+---
+title: "Session Security | Security Alliance"
+description: "Run a Session community safely: recovery-password custody, Account ID impersonation, unencrypted Communities, and moderation without a central account provider."
+tags:
+ - Community & Marketing
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter } from '../../../components'
+
+# Session
+
+
+
+
+> 🔑 **Key Takeaway**: Session removes phone numbers and central accounts, so recovery and revocation disappear with
+> them. The recovery password is the account, and Communities are not end-to-end encrypted.
+
+Session account and Community security spans recovery-password custody, Account ID verification, privacy settings, and
+Community server administration—each covered in depth in the
+[Session Security Guide](/guides/account-management/session). Use this page to find the right section.
+
+## The community manager's role in security
+
+Session appeals to Web3 teams for the reason it appeals to everyone else: no phone number, no email address, and no
+central account provider. For a community manager who has watched a colleague lose an account to a SIM swap, that is a
+meaningful improvement.
+
+The same design removes the safety net. There is no support desk that can freeze a stolen identity, no password reset,
+and no way to revoke a leaked credential. A community manager operating on Session holds a key pair, and the entire
+security posture of the role reduces to how that key pair is stored and how members verify which Account ID is real.
+
+What differs from Discord and Telegram is that recovery is a project responsibility rather than a platform feature.
+Losing the recovery password means the operator identity is gone; leaking it means an attacker becomes that identity to
+every contact, with no mechanism to take it back.
+
+### Why following this guide is not optional
+
+Session's two chat surfaces have different security properties, and mixing them up is the most common operational
+mistake. Groups are end-to-end encrypted and suited to team coordination. Communities run on a Session Open Group
+Server (SOGS) and are **not** end-to-end encrypted on that server: whoever operates the instance can read the traffic
+it stores. Treating a Community as a private channel misplaces trust in an operator who may not even be the project.
+
+Impersonation is also harder to counter than on platforms with usernames and verified badges. Account IDs are long
+hexadecimal strings, and members cannot reasonably eyeball the difference between a real one and a near-match. The only
+durable answer is a project-controlled page listing official Account IDs and invite links, plus a stated policy that
+moderators never send the first direct message.
+
+### What is at stake
+
+| Risk | Consequence |
+| --- | --- |
+| **Recovery password leak** | Attacker restores the account and becomes the operator to every contact, permanently |
+| **Recovery password loss** | Operator identity is unrecoverable; contacts must be re-established out of band |
+| **Account ID impersonation** | Lookalike IDs direct members to scam links with no verified-badge signal to contradict them |
+| **Community server exposure** | The SOGS operator can read Community messages, which are not end-to-end encrypted |
+| **Unsolicited message requests** | Posting in a Community exposes the operator Account ID to mass phishing |
+| **Over-granted moderator rights** | Compromised moderator can act on the server with no central authority to intervene |
+| **Community cloning** | Duplicate rooms and invite URLs redirect members into attacker-controlled spaces |
+
+The guide addresses these with controls that fit the platform's constraints, starting with treating the recovery
+password like a wallet seed phrase.
+
+## What the guide covers
+
+The guide is structured by scope: personal account first, then Community operations.
+
+| Scope | What it covers |
+| --- | --- |
+| **Personal account** | Recovery password custody, privacy toggles, screen lock, notification content, contact verification |
+| **Community operations** | Choosing groups over Communities, moderator permissions, SOGS hosting, official channel lists |
+
+## Topic index
+
+| Topic | Summary | Guide section |
+| --- | --- | --- |
+| **Recovery password** | The mnemonic that encodes the account key; store it offline like a seed phrase | [Account security checklist](/guides/account-management/session#account-security-checklist) |
+| **Privacy settings** | Screen lock, read receipts, link previews, and Community message requests | [Account security checklist](/guides/account-management/session#account-security-checklist) |
+| **Account ID verification** | Compare the full ID out of band; matching prefixes and suffixes prove nothing | [Verifying who is on the other end](/guides/account-management/session#verifying-who-is-on-the-other-end) |
+| **Communities are not E2EE** | Community traffic is readable by the server operator; keep sensitive threads in groups | [Best practices](/guides/account-management/session#best-practices-for-safe-use) |
+| **Groups versus Communities** | Pick the surface by confidentiality requirement, not by member count | [Choosing groups or Communities](/guides/account-management/session#choosing-groups-or-communities) |
+| **Moderator permissions** | SOGS read, write, upload, and access rights granted at the minimum level | [Community and server checklist](/guides/account-management/session#community-and-server-checklist) |
+| **Compromise response** | Removing server permissions and re-establishing the operator under a new Account ID | [Community and server checklist](/guides/account-management/session#community-and-server-checklist) |
+
+For step-by-step procedures, see the [Session Security Guide](/guides/account-management/session).
+
+## Further reading
+
+- [Session Security Guide](/guides/account-management/session)
+- [Community Management overview](/community-management/overview): how platform pages fit together
+- [Session documentation](https://docs.getsession.org/): vendor documentation
+- [How to stay safe on Session](https://getsession.org/blog/how-to-stay-safe-on-session): vendor security guidance
+
+---
+
+
diff --git a/docs/pages/community-management/simplex.mdx b/docs/pages/community-management/simplex.mdx
new file mode 100644
index 000000000..635b0a986
--- /dev/null
+++ b/docs/pages/community-management/simplex.mdx
@@ -0,0 +1,105 @@
+---
+title: "SimpleX Security | Security Alliance"
+description: "Run a SimpleX community safely: invitation links as access control, member roles, database custody, group scale limits, and moderation without user identities."
+tags:
+ - Community & Marketing
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter } from '../../../components'
+
+# SimpleX
+
+
+
+
+> 🔑 **Key Takeaway**: With no user identities, the invitation link is the access control and the local database is the
+> identity. Rotate links after a leak, and back up the database or lose the community.
+
+SimpleX community security spans database custody, invitation-link discipline, contact verification, and group role
+management—each covered in depth in the [SimpleX Chat Security Guide](/guides/account-management/simplex). Use this
+page to find the right section.
+
+## The community manager's role in security
+
+SimpleX goes further than Session or Matrix: it has no user identifiers at all. There is no account, no username, and
+no directory. Contacts connect through invitation links, and each connection uses its own message queues on relays that
+never hold a persistent identity.
+
+For a project whose threat model includes correlation of who talks to whom, that is a strong property. For a community
+manager, it also means the familiar moderation primitives do not exist. There is no account to report, no platform-wide
+ban, and no profile page members can check to confirm they are talking to the real team.
+
+Two consequences follow. Access control becomes link management: anyone holding a group link can join, and a leaked
+link is corrected by rotating it, not by banning the people who used it. Continuity becomes backup management: the
+local database holds every contact, group, and key, so a lost device without an exported backup ends the operator's
+relationships permanently.
+
+### Why following this guide is not optional
+
+The most common failure is treating SimpleX like an app with an account behind it. Operators install it, connect to
+their team, and never set an explicit database passphrase or export a backup — then lose a phone and discover there is
+nothing to restore from. The platform is explicit that no server holds recoverable state.
+
+The second failure is scale. Every message is delivered separately to each group member, so SimpleX groups are designed
+for teams and small communities rather than mass announcement channels. Projects that push a large public community
+onto SimpleX get degraded delivery and no better moderation than they had, while giving up the tooling their
+centralized channels provided.
+
+### What is at stake
+
+| Risk | Consequence |
+| --- | --- |
+| **Lost database passphrase or device** | Every contact, group, and message is unrecoverable; no server-side state exists |
+| **Leaked group invitation link** | Anyone holding it can join; removal is per group and reversible by rejoining |
+| **Man-in-the-middle at connection time** | An intercepted invitation link connects the member to an impostor |
+| **Impersonation of the project** | No verified accounts exist, so only an out-of-band canonical link proves authenticity |
+| **Over-granted group roles** | An admin or owner can remove members and alter group preferences |
+| **Device compromise** | The database is the identity; unlocked device access is full account access |
+| **Scale misuse** | Per-member fan-out degrades large groups and hides moderation problems |
+
+The guide addresses these with device-side controls, connection hygiene, and group role management.
+
+## What the guide covers
+
+The guide is structured by scope: personal installation first, then group operations.
+
+| Scope | What it covers |
+| --- | --- |
+| **Personal installation** | Database passphrase, SimpleX Lock and self-destruct passcode, screen protection, backups, retention |
+| **Connections** | Security-code verification, one-time links, incognito mode, separate chat profiles |
+| **Network** | Relay server choice, private message routing, Tor routing, residual metadata |
+| **Group operations** | Member roles, link joiner defaults, link rotation, group preferences, scale limits |
+
+## Topic index
+
+| Topic | Summary | Guide section |
+| --- | --- | --- |
+| **Database passphrase** | Set an explicit passphrase; it is what makes an exported backup usable | [Account security checklist](/guides/account-management/simplex#account-security-checklist) |
+| **SimpleX Lock** | App-level authentication, with an optional self-destruct passcode under coercion | [Account security checklist](/guides/account-management/simplex#account-security-checklist) |
+| **Encrypted backups** | Export the database, store it with other high-value backups, and test restoring | [Account security checklist](/guides/account-management/simplex#account-security-checklist) |
+| **Security code verification** | Per-contact verification against a man-in-the-middle at introduction | [Verifying contacts](/guides/account-management/simplex#verifying-contacts-and-controlling-connections) |
+| **One-time invitation links** | Single-use links over a publicly posted contact address | [Verifying contacts](/guides/account-management/simplex#verifying-contacts-and-controlling-connections) |
+| **Incognito and profiles** | Random per-contact profiles, and separate public and team profiles | [Verifying contacts](/guides/account-management/simplex#verifying-contacts-and-controlling-connections) |
+| **Relay servers and routing** | Preset or self-hosted SMP and XFTP relays, private message routing, Tor | [Network settings](/guides/account-management/simplex#network-and-metadata-settings) |
+| **Group roles** | Observer, member, admin, and owner capabilities; keep owners few | [Group configuration](/guides/account-management/simplex#group-configuration-checklist) |
+| **Link rotation** | The real access control after a leak or a staff departure | [Group configuration](/guides/account-management/simplex#group-configuration-checklist) |
+
+For step-by-step procedures, see the [SimpleX Chat Security Guide](/guides/account-management/simplex).
+
+## Further reading
+
+- [SimpleX Chat Security Guide](/guides/account-management/simplex)
+- [Community Management overview](/community-management/overview): how platform pages fit together
+- [SimpleX guide: privacy and security](https://simplex.chat/docs/guide/privacy-security.html): vendor documentation
+- [SimpleX guide: groups](https://simplex.chat/docs/guide/secret-groups.html): roles, links, and group preferences
+
+---
+
+
diff --git a/docs/pages/guides/account-management/index.mdx b/docs/pages/guides/account-management/index.mdx
index fc24b196a..bbb57b411 100644
--- a/docs/pages/guides/account-management/index.mdx
+++ b/docs/pages/guides/account-management/index.mdx
@@ -16,11 +16,14 @@ title: "Account Management"
- [GitHub Security](/guides/account-management/github)
- [GoDaddy Security](/guides/account-management/godaddy)
- [Linear Security](/guides/account-management/linear)
+- [Matrix Security](/guides/account-management/matrix)
- [Mercury Security](/guides/account-management/mercury)
- [Notion Security](/guides/account-management/notion)
- [Render Security](/guides/account-management/render)
- [Sentry Security](/guides/account-management/sentry)
+- [Session Security](/guides/account-management/session)
- [Signal Security](/guides/account-management/signal)
+- [SimpleX Chat Security](/guides/account-management/simplex)
- [Slack Security](/guides/account-management/slack)
- [Telegram Security](/guides/account-management/telegram)
- [Trello Security](/guides/account-management/trello)
diff --git a/docs/pages/guides/account-management/matrix.mdx b/docs/pages/guides/account-management/matrix.mdx
new file mode 100644
index 000000000..432e94f7b
--- /dev/null
+++ b/docs/pages/guides/account-management/matrix.mdx
@@ -0,0 +1,177 @@
+---
+title: "Matrix Security | Security Alliance"
+description: "Secure Matrix and Element accounts: create recovery keys, verify every session with cross-signing, choose a homeserver deliberately, and moderate federated rooms."
+tags:
+ - Communication Platforms
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
+
+# Matrix Security
+
+
+
+
+## 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](https://docs.element.io/) 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.
+
+
+## Further reading
+
+- [Community Management: Matrix](/community-management/matrix): running a Matrix community safely
+- [Account Management overview](/guides/account-management/overview): how these product guides fit together
+- [Communication Encryption](/encryption/communication-encryption): the mechanics behind end-to-end encryption
+- [Secure Authentication](/iam/secure-authentication): the account controls behind recovery keys and session management
+- [Element documentation: securing a Matrix account](https://docs.element.io/latest/element-support/matrix-account-management/securing-a-matrix-account/):
+ vendor documentation for current settings paths
+- [Matrix.org moderation guide](https://matrix.org/docs/communities/moderation/): power levels, ban lists, and server
+ ACLs
+
+---
+
+
diff --git a/docs/pages/guides/account-management/overview.mdx b/docs/pages/guides/account-management/overview.mdx
index d8bf45d7e..c0fc62ae6 100644
--- a/docs/pages/guides/account-management/overview.mdx
+++ b/docs/pages/guides/account-management/overview.mdx
@@ -28,13 +28,17 @@ Practical, step-by-step guide hub for securing accounts across communication pla
applications. Most child guides include checklists for individuals, team members, and administrators.
## What this framework covers
+
### Communication platforms
1. [Discord Security](/guides/account-management/discord): server roles, raid protection, bot least privilege.
-2. [Signal Security](/guides/account-management/signal): registration lock and privacy settings.
-3. [Slack Security](/guides/account-management/slack): workspace admin and MFA posture.
-4. [Telegram Security](/guides/account-management/telegram): two-step verification, phone privacy, group admin rights.
-5. [Twitter/X Security](/guides/account-management/twitter): SIM-swap resistant MFA and OAuth hygiene.
+2. [Matrix Security](/guides/account-management/matrix): recovery keys, cross-signing, room and homeserver hardening.
+3. [Session Security](/guides/account-management/session): recovery password custody and Community server limits.
+4. [Signal Security](/guides/account-management/signal): registration lock and privacy settings.
+5. [SimpleX Chat Security](/guides/account-management/simplex): database passphrase, app lock, and group links.
+6. [Slack Security](/guides/account-management/slack): workspace admin and MFA posture.
+7. [Telegram Security](/guides/account-management/telegram): two-step verification, phone privacy, group admin rights.
+8. [Twitter/X Security](/guides/account-management/twitter): SIM-swap resistant MFA and OAuth hygiene.
### DevOps and infrastructure
diff --git a/docs/pages/guides/account-management/session.mdx b/docs/pages/guides/account-management/session.mdx
new file mode 100644
index 000000000..041955556
--- /dev/null
+++ b/docs/pages/guides/account-management/session.mdx
@@ -0,0 +1,172 @@
+---
+title: "Session Security | Security Alliance"
+description: "Secure Session accounts: protect the recovery password like a seed phrase, harden privacy settings, verify Account IDs, and moderate unencrypted Communities."
+tags:
+ - Communication Platforms
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
+
+# Session Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway**: The Session recovery password is the account. Store it like a wallet seed phrase, verify Account
+> IDs out of band, and never treat Communities as confidential: they are not end-to-end encrypted on the server.
+
+Session is a messenger built on the Session Network, an onion-routing network of community-operated service nodes. It
+requires no phone number and no email address. Identity is a randomly generated Account ID (also called a Session ID),
+and the account exists only as a key pair the app holds.
+
+That design removes the SIM-swap exposure that dominates Telegram and Signal threat models, but it moves the entire risk
+onto one secret: the recovery password. There is no support desk, no password reset, and no identity provider that can
+restore an account or lock an attacker out. The controls below reflect that trade-off.
+
+## For individuals
+
+These settings apply to a personal Session account. Every team member and moderator should configure them on their own
+account. Menu labels differ slightly between the desktop, Android, and iOS clients; the
+[official documentation](https://docs.getsession.org/) holds current paths.
+
+### Account security checklist
+
+
+- [ ] **Recovery password** > Record it offline and store it in a password manager or on paper
+ - The recovery password is a mnemonic seed that encodes the account's long-term private key. Anyone holding it can
+ restore the account and impersonate the operator to every contact.
+ - Treat it exactly like a wallet seed phrase: never type it into a website, never paste it into a chat, never
+ screenshot it, and never store it in cloud notes.
+ - Session support cannot recover a lost recovery password and cannot revoke a leaked one. A leaked recovery password
+ requires abandoning the Account ID and telling contacts about the new one through a separately verified channel.
+ - Restoring an account recovers the Account ID and contacts, but message history older than roughly two weeks is not
+ retained by the network. Do not treat Session as an archive of record.
+- [ ] Settings > Privacy > Screen Lock > **Enabled**
+ - Requires device biometrics or passcode to open the app.
+- [ ] Settings > Privacy > Read Receipts > **Disabled**
+- [ ] Settings > Privacy > Typing Indicators > **Disabled**
+- [ ] Settings > Privacy > Link Previews > **Disabled**
+ - Generating a preview fetches the target URL. Leaving previews off avoids touching attacker-controlled links.
+- [ ] Settings > Privacy > Community Message Requests > **Disabled**
+ - Blocks unsolicited direct messages from people who saw the Account ID in a Community. This is the main spam and
+ phishing vector against operators who post publicly.
+- [ ] Settings > Privacy > Voice and Video Calls > **Disabled** unless needed
+ - Calls can expose IP address information to the other party. Enable per contact only when required.
+- [ ] Settings > Notifications > Notification Content > **No Name or Content**
+ - Keeps message contents off the lock screen of a device that may be seized, shoulder-surfed, or shared.
+- [ ] Settings > Privacy > Blocked Contacts > Review the list periodically
+- [ ] Install only from [getsession.org](https://getsession.org/download) or an official app store listing, and keep
+ automatic updates enabled
+
+
+### Verifying who is on the other end
+
+Session has no usernames tied to a directory and no verified-account badge. An Account ID is a long hexadecimal string,
+which makes lookalike IDs easy to produce and hard for members to spot.
+
+
+- [ ] **Exchange Account IDs out of band**
+ - Scan a QR code in person, or confirm the full Account ID over a channel already authenticated by other means (a
+ verified Signal thread, a signed message, a video call).
+- [ ] **Compare the entire string, not the ends**
+ - Vanity generation makes matching prefixes and suffixes cheap. Checking only the first and last characters is not a
+ verification.
+- [ ] **Re-verify after any device change**
+ - A contact who reinstalled and restored keeps the same Account ID; a contact who created a new account does not.
+ Treat an unexplained new Account ID as an impersonation attempt until proven otherwise.
+- [ ] **Enable disappearing messages for sensitive threads**
+ - Set per conversation. This limits what a later device compromise can expose.
+
+
+### Best practices for safe use
+
+
+- [ ] **Keep the operator Account ID out of public Communities**
+ - Posting in a Community exposes the Account ID to every member. Use a separate account for public moderation and a
+ private one for team communication where the threat model warrants it.
+- [ ] **Never act on inbound message requests alone**
+ - Requests from unknown Account IDs claiming to be team members, support, or partners are the standard phishing
+ pattern. Confirm through an established channel before responding.
+- [ ] **Do not use Communities for confidential coordination**
+ - Community messages are not end-to-end encrypted while stored on the Community server. Use groups or one-to-one
+ conversations for anything sensitive.
+- [ ] **Back up the recovery password before it is needed**
+ - Account restoration is impossible after device loss without it. Store a copy in the same place the organization
+ keeps other high-value secrets.
+- [ ] **Verify links before opening them**
+ - Session does not scan or reputation-check URLs. Assume any link from an unverified contact is hostile.
+
+
+## For team members
+
+Team members who help moderate but do not administer Community servers should:
+
+- Configure every setting in the checklists above on their own account.
+- Store their recovery password in the organization's password manager, not in personal cloud storage.
+- Publish their Account ID through one canonical, project-controlled location so members can verify it, and state
+ publicly that moderators never initiate direct messages.
+- Report impersonating Account IDs to admins rather than engaging with them.
+
+## For admins
+
+These practices apply to operators who run Session groups and Communities.
+
+### Choosing groups or Communities
+
+| Feature | Groups | Communities |
+| --- | --- | --- |
+| **Encryption** | End-to-end encrypted through the Session protocol | Not end-to-end encrypted on the Community server |
+| **Hosting** | No dedicated server; carried by the Session Network | Requires a Session Open Group Server (SOGS) run by an operator |
+| **Scale** | Small teams, roughly 100 members | Hundreds to thousands of members |
+| **Correct use** | Team coordination, incident response, anything confidential | Public announcements and open community discussion |
+
+The decision is a security decision, not a capacity one. Move any thread that would damage the project if published
+into a group or a one-to-one conversation.
+
+### Community and server checklist
+
+
+
+## Further reading
+
+- [Community Management: Session](/community-management/session): running a Session community safely
+- [Account Management overview](/guides/account-management/overview): how these product guides fit together
+- [Encrypted Communication Tools](/privacy/encrypted-communication-tools): how Session compares to other messengers
+- [Communication Encryption](/encryption/communication-encryption): the mechanics behind end-to-end encryption
+- [Session documentation](https://docs.getsession.org/): vendor documentation for current settings paths
+- [How to stay safe on Session](https://getsession.org/blog/how-to-stay-safe-on-session): vendor security guidance
+
+---
+
+
diff --git a/docs/pages/guides/account-management/simplex.mdx b/docs/pages/guides/account-management/simplex.mdx
new file mode 100644
index 000000000..9af79094d
--- /dev/null
+++ b/docs/pages/guides/account-management/simplex.mdx
@@ -0,0 +1,155 @@
+---
+title: "SimpleX Chat Security | Security Alliance"
+description: "Secure SimpleX Chat: set a database passphrase, enable SimpleX Lock, verify security codes, control invitation links, and run groups without user identities."
+tags:
+ - Communication Platforms
+contributors:
+ - role: wrote
+ users: [AllyPry]
+ - role: reviewed
+ users: []
+ - role: fact-checked
+ users: []
+---
+
+import { TagList, AttributionList, ContributeFooter, Checklist } from '../../../../components'
+
+# SimpleX Chat Security
+
+
+
+
+## Summary
+
+> 🔑 **Key Takeaway**: SimpleX has no accounts, so the local database is the identity. Set a passphrase, enable SimpleX
+> Lock, export encrypted backups, and verify security codes — nothing is recoverable from a server.
+
+SimpleX Chat has no user identifiers. There is no account, no username, and no directory entry. Contacts connect
+through single-use invitation links or a long-term contact address, and each connection uses its own pair of message
+queues on relay servers that never see a persistent identity.
+
+That removes the enumeration and impersonation surface most platforms carry, and it moves the entire risk to the
+device. Everything — contacts, groups, history, keys — lives in the local database. Losing the device without an
+exported backup loses every connection permanently, and there is no operator who can restore it or lock an attacker
+out. Settings labels below follow the mobile app; the desktop client is close but not identical.
+
+## For individuals
+
+These settings apply to a personal SimpleX installation. Every team member and moderator should configure them.
+
+### Account security checklist
+
+
+- [ ] **Set a database passphrase and store it in a password manager**
+ - Settings > Database passphrase & export > set your own passphrase.
+ - The app generates a random passphrase at install and keeps it in the device keystore. Setting an explicit
+ passphrase is what makes an exported backup usable on a new device.
+ - A lost passphrase is unrecoverable. There is no reset, no escrow, and no support path.
+- [ ] Settings > Privacy & security > SimpleX Lock > **Enabled**
+ - Requires authentication when the app resumes from the background.
+ - Lock mode **Passcode** additionally allows a self-destruct passcode, which wipes the database and opens a new empty
+ profile when entered. Configure it only where coercion is a real risk, and understand that it destroys data with no
+ recovery.
+- [ ] Settings > Privacy & security > Protect app screen > **Enabled**
+ - Blocks screenshots and hides content in the app switcher.
+- [ ] Settings > Privacy & security > Send link previews > **Disabled**
+- [ ] Settings > Privacy & security > Auto-accept images > **Disabled**
+ - Prevents unsolicited media from being fetched and written to the device automatically.
+- [ ] **Export an encrypted database backup and test restoring it**
+ - Settings > Database passphrase & export > Export database, then store the file where the organization keeps other
+ high-value backups. The export is encrypted with the passphrase above.
+ - An untested backup is not a backup. Restore it on a second device before relying on it.
+- [ ] **Set a message retention period**
+ - Database passphrase & export > delete messages after a chosen interval. This limits what a device compromise
+ exposes.
+- [ ] **Keep the app updated and install it from an official source**
+ - [simplex.chat](https://simplex.chat/downloads/) or an official app store listing.
+
+
+### Verifying contacts and controlling connections
+
+SimpleX cannot be phished for an account, but a connection link can still be intercepted or relayed by an attacker
+sitting between the two parties at the moment of introduction.
+
+
+- [ ] **Verify the security code with every contact that matters**
+ - Open the contact > verify the security code by scanning it in person or reading it aloud on a video call. This is
+ the defense against a man-in-the-middle at connection time.
+- [ ] **Prefer one-time invitation links over a shared contact address**
+ - A one-time link works for a single connection. A long-term contact address posted publicly invites unsolicited
+ contact from anyone who finds it.
+- [ ] **Deliver invitation links over an already-authenticated channel**
+ - A link sent through a compromised channel connects the recipient to whoever intercepted it.
+- [ ] **Use incognito mode for connections that should not see the main profile**
+ - Settings > Incognito. A random profile name is generated per new contact or group.
+- [ ] **Separate roles with distinct chat profiles**
+ - A public-facing moderation profile and a private team profile can coexist in one installation; hidden profiles add
+ a password gate on top.
+
+
+### Network and metadata settings
+
+
+- [ ] **Review which relay servers are in use**
+ - Settings > Network & servers. Preset operator servers are the default; a project with a strict metadata policy can
+ add or self-host SMP (messaging) and XFTP (file) servers.
+ - Self-hosting relays changes who observes traffic patterns. It does not grant access to message content, which is
+ end-to-end encrypted regardless of the relay.
+- [ ] **Keep private message routing enabled**
+ - It separates the server that receives a message from the server that delivers it, so neither sees both ends.
+- [ ] **Route over Tor when the network path itself is sensitive**
+ - Android supports a SOCKS proxy with Orbot and `.onion` host addresses; iOS routes through a VPN.
+- [ ] **Understand the residual metadata**
+ - Relay operators see connection and traffic timing for the queues they host. SimpleX minimizes correlation between
+ queues; it does not eliminate network observation.
+
+
+## For team members
+
+Team members who help moderate but do not own groups should:
+
+- Complete every item in the checklists above, in particular the database passphrase and an exported backup.
+- Verify security codes with each teammate before treating a conversation as authenticated.
+- Never republish a group invitation link outside the channel it was intended for; the link is the access control.
+- Report suspected impersonation to group owners, who hold the moderation capabilities.
+
+## For admins
+
+These practices apply to operators who run SimpleX groups for a team or community.
+
+### Group configuration checklist
+
+
+- [ ] **Assign the lowest workable role to each member**
+ - Roles are observer (read-only), member, admin (can remove members and delete others' messages), and owner (can
+ change group preferences). Keep the owner count small and deliberate.
+- [ ] **Choose the default role for link joiners consciously**
+ - A group link can admit new members as observers, which is the safe default for announcement-style groups.
+- [ ] **Rotate the group link after any leak, and after staff departures**
+ - Anyone holding the link can join. There is no membership approval queue to fall back on.
+- [ ] **Set group preferences to match the group's purpose**
+ - Disappearing messages, direct messages between members, delete-for-everyone, and voice messages are all owner-
+ controlled. Disabling direct messages between members reduces internal phishing in a public group.
+- [ ] **Keep groups small enough to work**
+ - Every message is delivered separately to every member, so large groups degrade. Use SimpleX for team and
+ small-community use, not for a mass announcement channel.
+- [ ] **Plan moderation without a global identity**
+ - There is no platform-wide ban and no account to report. Removal is per group, and a removed member can return
+ through any link they still hold — which is why link rotation is the real control.
+- [ ] **Publish the canonical way to reach the project**
+ - Because there are no verified accounts, members have no way to distinguish a real operator from an impostor except
+ a project-controlled page listing the official link and the support policy.
+
+
+## Further reading
+
+- [Community Management: SimpleX](/community-management/simplex): running a SimpleX community safely
+- [Account Management overview](/guides/account-management/overview): how these product guides fit together
+- [Encrypted Communication Tools](/privacy/encrypted-communication-tools): how SimpleX compares to other messengers
+- [Communication Encryption](/encryption/communication-encryption): the mechanics behind end-to-end encryption
+- [SimpleX guide: privacy and security](https://simplex.chat/docs/guide/privacy-security.html): vendor documentation
+- [SimpleX guide: app settings](https://simplex.chat/docs/guide/app-settings.html): current settings paths
+
+---
+
+
diff --git a/vocs.config.ts b/vocs.config.ts
index 580203ada..a7006306e 100644
--- a/vocs.config.ts
+++ b/vocs.config.ts
@@ -112,6 +112,9 @@ const config = {
{ text: 'Discord', link: '/community-management/discord' },
{ text: 'Twitter', link: '/community-management/twitter' },
{ text: 'Telegram', link: '/community-management/telegram' },
+ { text: 'Matrix', link: '/community-management/matrix' },
+ { text: 'Session', link: '/community-management/session' },
+ { text: 'SimpleX', link: '/community-management/simplex' },
]
},
{
@@ -636,11 +639,14 @@ const config = {
{ text: 'GitHub Security', link: '/guides/account-management/github' },
{ text: 'GoDaddy Security', link: '/guides/account-management/godaddy' },
{ text: 'Linear Security', link: '/guides/account-management/linear' },
+ { text: 'Matrix Security', link: '/guides/account-management/matrix' },
{ text: 'Mercury Security', link: '/guides/account-management/mercury' },
{ text: 'Notion Security', link: '/guides/account-management/notion' },
{ text: 'Render Security', link: '/guides/account-management/render' },
{ text: 'Sentry Security', link: '/guides/account-management/sentry' },
+ { text: 'Session Security', link: '/guides/account-management/session' },
{ text: 'Signal Security', link: '/guides/account-management/signal' },
+ { text: 'SimpleX Security', link: '/guides/account-management/simplex' },
{ text: 'Slack Security', link: '/guides/account-management/slack' },
{ text: 'Telegram Security', link: '/guides/account-management/telegram' },
{ text: 'Trello Security', link: '/guides/account-management/trello' },
diff --git a/wordlist.txt b/wordlist.txt
index 1fa27eb67..9cae33ebd 100644
--- a/wordlist.txt
+++ b/wordlist.txt
@@ -93,6 +93,7 @@ DNSSEC
DocuSign
doxxing
DPRK
+Draupnir
Dreww
DTEX
Dyno
@@ -207,6 +208,7 @@ mev
mgmt
mimick
mitre
+Mjolnir
MNGO
Monero
Morena
@@ -237,6 +239,7 @@ ofac
OpenSCAP
OPSEC
Opsek
+Orbot
ossf
pagetoc
Palo
@@ -318,6 +321,7 @@ SMS
smt
smtpdane
SOE
+SOGS
Solana
Solcurity
SonarQube
@@ -393,6 +397,7 @@ WIDS
WPA
WPAD
xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+XFTP
xkcd
xngmi
XSS