Das Matrix-Protokoll ist ein offener Standard für dezentrale, Ende-zu-Ende-verschlüsselte Echtzeitkommunikation. Es beschreibt, wie unabhängig voneinander betriebene Server – sogenannte Homeserver – Nachrichten, Dateien, Anrufe und Statusinformationen über Organisationsgrenzen hinweg austauschen, ohne dass ein zentraler Anbieter dazwischensteht. Gepflegt wird die Spezifikation von der gemeinnützigen Matrix.org Foundation. Das Matrix-Protokoll ist damit kein Produkt, sondern die Grundlage zahlreicher Server- und Client-Implementierungen.

Was ist das Matrix-Protokoll?

Das Matrix-Protokoll ist eine offene Spezifikation für interoperable Kommunikation, deren Funktion sich am ehesten mit SMTP für E-Mail vergleichen lässt: Es legt fest, wie Clients mit Servern und Server untereinander kommunizieren, überlässt die konkrete Umsetzung aber jedem Anbieter. Entwickelt wurde Matrix ab 2014, seit 2018 verantwortet die gemeinnützige Matrix.org Foundation C.I.C. mit Sitz in Großbritannien die Weiterentwicklung. Die Spezifikation steht unter der Apache-Lizenz 2.0 und ist frei implementierbar.

Zwei Eigenschaften prägen das Matrix-Protokoll. Erstens die Dezentralität: Es existiert kein zentraler Dienst, über den die Kommunikation läuft. Jede Organisation kann einen eigenen Homeserver betreiben und behält damit die Hoheit über Konten, Daten und Betriebsort. Zweitens die Verschlüsselung: Ende-zu-Ende-Verschlüsselung ist im Matrix-Protokoll als Bestandteil der Spezifikation definiert und nicht als optionale Erweiterung nachgerüstet.

In der Praxis wird das Matrix-Protokoll häufig mit einzelnen Produkten gleichgesetzt, insbesondere mit dem Client Element. Diese Verwechslung führt zu unpassenden Vergleichen: Wer „Matrix gegen Signal“ oder „Matrix gegen Teams“ abwägt, stellt einen Standard neben ein Produkt. Sinnvoll ist die Trennung zwischen der Protokollebene, der Server-Implementierung, dem eingesetzten Client und dem Betriebsmodell – vier Entscheidungen, die unabhängig voneinander getroffen werden und jeweils eigene Sicherheits- und Compliance-Folgen haben.

Wie funktioniert das Matrix-Protokoll technisch?

Technisch arbeitet das Matrix-Protokoll mit HTTPS und JSON über eine Reihe klar abgegrenzter Schnittstellen. Jeder Nutzer besitzt ein Konto auf genau einem Homeserver, der seine Identität, seine Raummitgliedschaften und seinen Teil der Kommunikationshistorie vorhält. Die Adressierung folgt einem festen Schema: Nutzerkennungen haben die Form @vorname.nachname:organisation.de, Räume tragen intern eine unveränderliche ID und können zusätzlich über einen lesbaren Alias wie #lagezentrum:organisation.de angesprochen werden. Der Teil nach dem Doppelpunkt benennt immer den zuständigen Homeserver.

Die Spezifikation des Matrix-Protokolls unterteilt die Kommunikation in mehrere APIs mit unterschiedlichen Aufgaben:

API	Aufgabe
Client-Server-API	Anmeldung, Senden und Empfangen von Ereignissen, Raumverwaltung im Client
Server-Server-API (Föderations-API)	Austausch von Ereignissen und Raumzustand zwischen Homeservern
Application-Service-API	Anbindung von Bots, Bridges und Integrationen mit eigenem Namensraum
Identity-Service-API	optionale Zuordnung von E-Mail-Adressen und Telefonnummern zu Matrix-IDs
Push-Gateway-API	Zustellung von Push-Benachrichtigungen an mobile Clients

Der eigentliche Kern des Matrix-Protokolls liegt im Datenmodell der Räume. Jede Aktion – eine Nachricht, ein Beitritt, eine Rechteänderung, eine Reaktion – ist ein Ereignis, das auf vorangegangene Ereignisse verweist. Es entsteht ein gerichteter azyklischer Graph, den alle beteiligten Server replizieren. Weichen Zustände auseinander, etwa weil ein Server zeitweise nicht erreichbar war, führt ein festgelegter Auflösungsalgorithmus (State Resolution) die Historie wieder zusammen. Weil dieses Verfahren sicherheitsrelevant ist, kennt das Matrix-Protokoll versionierte Räume: Neue Regeln werden über neue Raumversionen eingeführt, die Server untereinander aushandeln. Diese Architektur erklärt zugleich den Ressourcenbedarf – ein Homeserver hält nicht nur die eigenen Nachrichten, sondern den gesamten Zustand aller Räume, an denen seine Nutzer teilnehmen.

Was bedeutet Föderation im Matrix-Protokoll?

Föderation bedeutet im Matrix-Protokoll, dass Räume nicht auf einem Server liegen, sondern auf allen Homeservern repliziert werden, deren Nutzer beteiligt sind. Ein Raum gehört keinem Server allein. Fällt ein beteiligter Homeserver aus, kommunizieren die übrigen Teilnehmer weiter; nach der Rückkehr gleicht der Server die entgangenen Ereignisse ab. Für organisationsübergreifende Zusammenarbeit ist das der zentrale Vorteil des Matrix-Protokolls: Eine Behörde, ein Klinikum und ein Dienstleister können in einem gemeinsamen Raum arbeiten, ohne dass eine Seite die Infrastruktur der anderen nutzen muss.

Diese Replikation hat allerdings eine Kehrseite, die in Sicherheitskonzepten regelmäßig unterschätzt wird. Sobald ein externer Nutzer einem Raum beitritt, erhält dessen Homeserver eine Kopie der Raumereignisse – bei verschlüsselten Räumen zwar nur als Chiffrat, aber inklusive Mitgliedschaften, Zeitstempeln und Raumstruktur. Die Kontrolle über diese Kopie liegt beim fremden Betreiber. Wer das Matrix-Protokoll in regulierten Umgebungen einsetzt, arbeitet deshalb meist nicht mit offener Föderation, sondern mit einer Freigabeliste zulässiger Serverdomänen oder ganz ohne Föderation nach außen. Die Föderation ist eine Betriebsentscheidung, keine automatische Eigenschaft.

Wie funktioniert die Ende-zu-Ende-Verschlüsselung im Matrix-Protokoll?

Die Ende-zu-Ende-Verschlüsselung im Matrix-Protokoll beruht auf zwei aufeinander aufbauenden Verfahren. Olm setzt den Double-Ratchet-Algorithmus für Sitzungen zwischen zwei Geräten um und dient dem Austausch von Schlüsselmaterial. Megolm baut darauf auf und verschlüsselt Gruppenkommunikation effizient, indem eine Sitzung mit fortlaufender Schlüsselableitung an alle berechtigten Geräte verteilt wird. Die ursprüngliche Referenzbibliothek libolm gilt als veraltet und wird durch die in Rust geschriebene Implementierung vodozemac abgelöst. Für private Räume ist die Verschlüsselung in gängigen Implementierungen standardmäßig aktiv.

Weil Ende-zu-Ende-Verschlüsselung geräte- und nicht kontobezogen arbeitet, kennt das Matrix-Protokoll Verfahren zur Vertrauensbildung zwischen Geräten: Cross-Signing verknüpft alle Geräte eines Nutzers mit einer übergeordneten Identität, die Verifizierung erfolgt per Emoji-Abgleich oder QR-Code, und ein verschlüsseltes Schlüsselbackup mit Wiederherstellungsschlüssel verhindert, dass Nachrichten beim Gerätewechsel unlesbar werden. Genau an dieser Stelle entsteht in der Praxis der meiste Supportaufwand – verlorene Wiederherstellungsschlüssel und nicht verifizierte Geräte sind die häufigste Ursache für Fehlermeldungen im laufenden Betrieb.

Zwei Grenzen sind für die Bewertung wichtig. Erstens schützt die Ende-zu-Ende-Verschlüsselung die Inhalte, nicht die Metadaten: Wer wann mit wem in welchem Raum kommuniziert, bleibt für die beteiligten Homeserver sichtbar. Zweitens erschwert sie serverseitige Funktionen wie Volltextsuche, Virenprüfung von Anhängen und revisionssichere Archivierung, weil der Server die Inhalte nicht lesen kann. Diese Funktionen müssen clientseitig oder über gesondert berechtigte Komponenten gelöst werden.

Welche Software setzt das Matrix-Protokoll um?

Das Matrix-Protokoll wird von mehreren Server- und Client-Implementierungen umgesetzt. Auf Serverseite ist Synapse die verbreitetste und funktional vollständigste Umsetzung; daneben existieren Dendrite und Conduit als ressourcenschonendere Alternativen mit teilweise abweichendem Funktionsumfang. Zu beachten ist die Lizenzsituation: Synapse wurde Ende 2024 von der Apache-Lizenz auf die AGPLv3 umgestellt, was für Beschaffung und Eigenentwicklung relevant sein kann und im Einzelfall zu prüfen ist.

Auf Clientseite ist Element die bekannteste Anwendung für Web, Desktop und Mobilgeräte, ergänzt durch Alternativen wie FluffyChat, SchildiChat oder Nheko. Rund um den Kern kommen weitere Komponenten hinzu, ohne die ein produktiver Betrieb selten auskommt: ein TURN-Server für Sprach- und Videoverbindungen über WebRTC, eine Anbindung an das Identitätsmanagement über OpenID Connect, SAML oder LDAP, ein Reverse Proxy sowie Bridges, die Räume mit anderen Systemen verbinden. Bridges sind funktional attraktiv, heben aber die Ende-zu-Ende-Verschlüsselung an der Übergabestelle faktisch auf und gehören deshalb in jede Risikobetrachtung.

Wie unterscheidet sich das Matrix-Protokoll von XMPP, dem Signal-Protokoll und proprietären Plattformen?

Das Matrix-Protokoll unterscheidet sich von benachbarten Ansätzen vor allem darin, was es überhaupt regelt: Es kombiniert ein Föderationsmodell mit einem replizierten Datenmodell und einer definierten Verschlüsselungsschicht. Andere Standards decken jeweils nur einen Teil davon ab.

Ansatz	Charakter	Verhältnis zum Matrix-Protokoll
XMPP	offener, föderierter IETF-Standard (RFC 6120 ff.), nachrichtenstromorientiert	Ältere Alternative; Historie wird nicht repliziert, Ende-zu-Ende-Verschlüsselung erfolgt über Erweiterungen wie OMEMO statt als Kernbestandteil
Signal-Protokoll	kryptografisches Verfahren für Ende-zu-Ende-Verschlüsselung, kein Föderationsmodell	Matrix setzt mit Olm den gleichen Double-Ratchet-Ansatz um; das Signal-Protokoll regelt Verschlüsselung, nicht den Serververbund
MLS (RFC 9420)	IETF-Standard für skalierbare Gruppenverschlüsselung	Möglicher künftiger Unterbau für die Verschlüsselungsschicht, ersetzt aber nicht das Matrix-Protokoll
Proprietäre Plattformen	geschlossene, anbieterbetriebene Dienste	Kein offener Serververbund; Betriebsort, Funktionsumfang und Schnittstellen bestimmt der Anbieter

Praktisch heißt das: Die Wahl zwischen Matrix und einer proprietären Plattform ist keine reine Sicherheitsfrage, sondern eine Frage des Betriebsmodells. Das Matrix-Protokoll verlagert Kontrolle – und damit auch Verantwortung und Aufwand – zur betreibenden Organisation.

Warum ist das Matrix-Protokoll für digitale Souveränität relevant?

Das Matrix-Protokoll ist für digitale Souveränität relevant, weil es die drei üblichen Abhängigkeiten gleichzeitig adressiert: Anbieterbindung, Betriebsort und Schnittstellenkontrolle. Die Spezifikation ist offen, mehrere Implementierungen konkurrieren, und der Betrieb ist im eigenen Rechenzentrum oder bei einem europäischen Dienstleister möglich. Ein Anbieterwechsel bedeutet damit nicht zwingend den Verlust der Kommunikationsstruktur – ein Argument, das bei Cloud-Diensten mit Bezug zum US CLOUD Act regelmäßig den Ausschlag gibt.

Die Einschränkung gehört zur ehrlichen Bewertung dazu: Ein offener Standard erzeugt keine Souveränität, er ermöglicht sie. Wer einen Matrix-Dienst als reines Software-as-a-Service-Angebot außerhalb der eigenen Kontrolle bezieht, gewinnt gegenüber anderen Cloud-Diensten wenig. Und der Eigenbetrieb setzt Kapazitäten voraus: Aktualisierungen, Zertifikate, Backups, Schlüsselverwaltung, Skalierung und Support für Nutzerinnen und Nutzer. Datensouveränität entsteht durch das Betriebskonzept, nicht durch die Protokollwahl allein.

Wo wird das Matrix-Protokoll im öffentlichen Sektor eingesetzt?

Das Matrix-Protokoll ist im europäischen öffentlichen Sektor breit vertreten. In Deutschland setzen der von der BWI betriebene BwMessenger der Bundeswehr und der BundesMessenger für die öffentliche Verwaltung auf Matrix. Im Gesundheitswesen hat die gematik den TI-Messenger für die Telematikinfrastruktur auf Basis von Matrix spezifiziert, um Kommunikation zwischen Leistungserbringern herstellerübergreifend zu ermöglichen. In der französischen Verwaltung ist Tchap seit Jahren im Einsatz, und in souveränen Arbeitsplatzlösungen für Behörden ist eine Matrix-basierte Chatkomponente inzwischen Standardbestandteil. Hinzu kommen Hochschulen und Forschungseinrichtungen, für die die Föderation zwischen Einrichtungen den ausschlaggebenden Vorteil darstellt.

Der gemeinsame Nenner dieser Projekte ist weniger die Verschlüsselung als die Interoperabilität: Organisationen, die aus rechtlichen Gründen keinen gemeinsamen Anbieter nutzen können oder wollen, benötigen ein Verfahren, das Zusammenarbeit über Organisationsgrenzen hinweg ohne gemeinsame Plattform erlaubt.

Welche Datenschutz- und Compliance-Anforderungen stellt das Matrix-Protokoll?

Das Matrix-Protokoll stellt vor allem drei Anforderungen, die über den Betrieb eines gewöhnlichen Messengers hinausgehen. Erstens die Löschung: Werden Ereignisse in einen föderierten Raum geschrieben, liegen Kopien auf allen beteiligten Homeservern. Eine Löschanforderung nach Art. 17 DSGVO erreicht technisch zunächst nur den eigenen Server; die Umsetzung auf fremden Servern hängt vom dortigen Betreiber ab. Für Löschkonzepte und die DSGVO-Konformität heißt das: Föderationsbeziehungen brauchen vertragliche Grundlagen, nicht nur technische Freigaben.

Zweitens die Metadaten. Mitgliedschaften, Zeitstempel, Raumstrukturen und Anwesenheitsinformationen sind in der Regel personenbezogene Daten und liegen unverschlüsselt auf den beteiligten Servern. Sie gehören in das Verarbeitungsverzeichnis und in die Bewertung der Föderationsentscheidung. Drittens die Nachweisführung: Wo Aufbewahrungs- oder Dokumentationspflichten gelten, muss die Archivierung trotz Ende-zu-Ende-Verschlüsselung gelöst werden, was in der Regel eine bewusst berechtigte Komponente und ein dokumentiertes Berechtigungskonzept erfordert.

Wichtig für die Beschaffung ist außerdem eine Abgrenzung, die häufig durcheinandergerät: Zulassungen und Zertifizierungen – etwa für die Verarbeitung von Verschlusssachen der Einstufung VS-NfD – gelten immer für ein konkretes Produkt in einer konkreten Konfiguration, niemals für ein Protokoll. Aus der Aussage „setzt auf Matrix“ folgt keinerlei Zulassungsstatus.

Ist das Matrix-Protokoll für Notfall- und Krisenkommunikation geeignet?

Das Matrix-Protokoll bringt für die Krisenkommunikation günstige Eigenschaften mit, deckt aber nicht alle Anforderungen ab. Günstig sind die Unabhängigkeit von einem einzelnen Anbieter, der mögliche Betrieb in der eigenen Infrastruktur und die organisationsübergreifende Zusammenarbeit ohne gemeinsame Plattform – gerade bei Lagen, an denen Behörden, Betreiber und Dienstleister gleichzeitig beteiligt sind.

Nicht abgedeckt sind Funktionen, die für Alarmierung und Stabsarbeit entscheidend sind: priorisierte Alarme, die den Stummschaltmodus durchbrechen, Empfangs- und Lesenachweise für einsatzkritische Meldungen, Push-to-Talk, Lagekarten oder eine zentrale Rechteverwaltung mit Rollen und Gruppen. Solche Merkmale entstehen erst in der Anwendungsschicht darüber und unterscheiden sich je nach Produkt erheblich. Hinzu kommt der Betriebsaspekt: Eine Kommunikationslösung für den Notfall muss auch dann verfügbar sein, wenn die eigene IT betroffen ist – ein selbst betriebener Homeserver im ausgefallenen Rechenzentrum hilft nicht weiter.

Organisationen lösen diese Anforderung in der Regel über vorab freigegebene, von der Regelinfrastruktur unabhängige Kommunikationslösungen mit definierten Alarmierungswegen, deren Verfügbarkeit regelmäßig geübt wird – unabhängig davon, ob das darunterliegende Protokoll offen oder proprietär ist.

Welche typischen Fehler treten beim Einsatz des Matrix-Protokolls auf?

Der häufigste Fehler beim Einsatz des Matrix-Protokolls ist die Gleichsetzung von offenem Standard und fertiger Lösung: Die Protokollwahl beantwortet weder die Frage nach dem Betrieb noch die nach Support, Schulung und Rollenkonzept. Weitere Schwachstellen aus der Praxis:

offene Föderation im Standardbetrieb belassen, ohne Freigabeliste zulässiger Serverdomänen
Ressourcenbedarf großer föderierter Räume unterschätzt, dadurch Verzögerungen und Ausfälle unter Last
Schlüsselverwaltung nicht organisiert, sodass Nutzer nach Gerätewechseln nicht mehr auf ihre Historie zugreifen
Bridges zu Consumer-Messengern eingeführt, ohne die dadurch entstehende Lücke in der Ende-zu-Ende-Verschlüsselung zu bewerten
Löschkonzept nur für den eigenen Homeserver gedacht, ohne Regelung für föderierte Gegenstellen
Archivierungs- und Nachweispflichten erst nach der Einführung betrachtet, wenn die Verschlüsselung bereits aktiv ist

Wie entwickelt sich das Matrix-Protokoll weiter?

Das Matrix-Protokoll wird über einen offenen Änderungsprozess weiterentwickelt: Vorschläge werden als Matrix Spec Change (MSC) eingereicht, öffentlich diskutiert und nach Freigabe durch das zuständige Gremium in die Spezifikation übernommen. Aktuelle Arbeitsschwerpunkte liegen bei der Leistungsfähigkeit mobiler Clients, bei der Umstellung der Authentifizierung auf OpenID Connect, bei Gruppenanrufen über eine Medienserver-Architektur sowie bei der Prüfung von MLS als künftiger Verschlüsselungsschicht.

Regulatorisch erhält das Matrix-Protokoll zusätzliche Aufmerksamkeit durch die Interoperabilitätspflichten des Digital Markets Act (Verordnung (EU) 2022/1925), die große Kommunikationsplattformen zur Öffnung gegenüber Drittanbietern verpflichten. In der zugehörigen Standardisierungsarbeit der IETF ist Matrix als bestehendes föderiertes Protokoll ein wesentlicher Referenzpunkt. Wie weit diese Öffnung praktisch trägt, ist derzeit offen und sollte bei Aussagen zur Interoperabilität zurückhaltend formuliert werden.

Zusammenfassung: Wichtige Punkte zum Matrix-Protokoll

Das Matrix-Protokoll ist ein offener Standard für dezentrale, Ende-zu-Ende-verschlüsselte Echtzeitkommunikation, gepflegt von der gemeinnützigen Matrix.org Foundation.
Matrix ist kein Produkt, sondern eine Spezifikation: Serverimplementierung, Client und Betriebsmodell sind davon unabhängige Entscheidungen mit eigenen Sicherheitsfolgen.
Jede Organisation betreibt einen eigenen Homeserver; Adressen folgen dem Schema @nutzer:organisation.de und benennen den zuständigen Server.
Föderation bedeutet, dass Räume auf allen beteiligten Homeservern repliziert werden – ein Vorteil für organisationsübergreifende Zusammenarbeit und zugleich der Grund, warum Föderationsbeziehungen freigegeben und vertraglich geregelt werden müssen.
Die Ende-zu-Ende-Verschlüsselung beruht auf Olm und Megolm und schützt Inhalte, nicht Metadaten wie Mitgliedschaften, Zeitstempel und Raumstrukturen.
Verbreitete Implementierungen sind Synapse, Dendrite und Conduit auf Serverseite sowie Element und weitere Clients auf Anwenderseite.
Im öffentlichen Sektor setzen unter anderem BwMessenger, BundesMessenger, der TI-Messenger der gematik und Tchap auf das Matrix-Protokoll.
Zulassungen wie VS-NfD gelten für Produkte, nicht für Protokolle – aus „basiert auf Matrix“ folgt kein Zulassungsstatus.
Für Notfall- und Krisenkommunikation deckt das Matrix-Protokoll die Transport- und Föderationsebene ab, nicht jedoch Alarmierung, Lesenachweise, Push-to-Talk oder zentrale Rollenverwaltung.
Die Weiterentwicklung erfolgt über Matrix Spec Changes (MSC); zusätzliche Aufmerksamkeit erhält das Protokoll durch die Interoperabilitätspflichten des Digital Markets Act (EU) 2022/1925.