Across Europe, sovereign communications systems are already being deployed, and crucially, they don’t have to exist in isolation. An overlooked part of achieving genuine digital sovereignty is ensuring that an organisation has the ability to switch easily between vendors to guard against vendor lock-in. 

It’s a sentiment that was perhaps best expressed by Karsten Wildberger, Germany’s Federal Minister for Digital, at the Summit on European Digital Sovereignty in November 2025: “Digital sovereignty means having choices, so no single technology and provider becomes a dependency that can be used against our interests. It is always good to have choices in order to avoid dependencies.”

Without the ability to easily switch between vendors, an end-user organisation remains beholden to a specific vendor. It gives a vendor too much power over the end user organisation. For example, it’s preferable to swallow a doubling in price than to ‘rip and replace’ an incumbent solution.

At the more alarming end of the spectrum, it creates major vulnerabilities. A recent example is Ukraine suffering the loss of satellite imagery supplied by Maxar Technologies, as the US vendor implemented a decision made by the US government. In a similar incident, email services to Karim Khan, chief prosecutor at International Criminal Court (ICC), were suspended as a result of a US government sanction. The ICC has since gone through the rip and replace pain of moving from Microsoft Office to openDesk, a sovereign alternative.

Interoperability delivers digital sovereignty

Governments’ adoption of digitally sovereign solutions, to avoid a dependency on a single vendor, is the right strategy to take in an increasingly sharp geopolitical climate. Even a vendor that is currently trusted cannot be trusted into an unseeable future. A vendor can be acquired, possibly by a company that’s headquartered in a non-trusted country. A vendor could be completely compromised as a result of a cyber attack, or nation-state sponsored malicious insider. A vendor could grow into a monopolistic position - especially if a government standardises on that vendor - and then abuse its dominant market position.

While a solution could be from a European vendor, enable self-hosting, and might even be open source, it’s still not offering sovereignty if it’s proprietary style ‘vendor-locked’ software. This is especially true for chat-based solutions.

Chat should never be a proprietary-style vendor-locked solution

Chat apps have developed during a quite centralised era of computing. That those using WhatsApp can only communicate with others using WhatsApp has, somehow, never been seriously questioned. Likewise, it’s only Signal to Signal, Slack to Slack, Teams to Teams, Threema to Threema, WebEx to WebEx, Wire to Wire, Zoom to Zoom. They are all walled gardens - siloed systems - that don’t interoperate.

Chat has never suited a proprietary model, because it often involves people who use different technology. The original open internet is a huge success because it enables communication through common standards. People can upload information stored and managed on their own system, and make it available to others via the Web.

Email is similar; it doesn’t matter what email system you use, you can send an email to anyone because it’s based on a standard on which all vendors operate. No one ever asks if you use Microsoft Outlook, Gmail or Apple Mail as - thanks to interoperability - it doesn't matter.

As a result (despite email being arcane and insecure) there’s still a healthy competitive ecosystem of email providers and switching between them isn’t a massive headache. Decades of emails can be seamlessly managed during an email migration, unlike years of chat history moving from Slack or Teams to some other proprietary system. As for WhatsApp or Signal, well, as consumer messaging apps they shouldn’t even be used within the workplace.

The role of Matrix for sovereign communications

Matrix is an open standard for decentralised communications. The protocol enables self-hosting, resilient communications, interoperability and end-to-end encryption. 

There’s well in excess of 200M people already using Matrix, and more than 150K Matrix deployments. More than 25 governments around the world have already deployed Matrix-based systems. There are more than 40 software vendors in the Matrix ecosystem, and at least 30 major primes, systems integrators, services firms and hosters offering Matrix-based solutions. 

The German healthcare system has developed its own standard, TI-Messenger, built on top of Matrix, that’s already implemented by public healthcare insurers. It’s currently being rolled out to local healthcare providers and will eventually support the vast majority of Germany’s 83M citizens. 

The Matrix ecosystem provides the ‘digital commons’ that ensures genuine digital sovereignty. Governments and public sector organisations have complete ownership and control of their communications solutions, with the ability to easily choose and switch between vendors, and federate with each other through their own sovereign systems.

Sovereignty without isolation - Matrix-based federation

Choosing a communications solution based on an open standard to ensure digital sovereignty brings another significant benefit. The Matrix open standard not only ensures a competitive ecosystem - it enables each independent Matrix stack to connect with any other (assuming both parties want to connect, of course). 

It’s the very opposite of a standard proprietary-approach, where all parties have to use the same vendor. The Matrix open standard enables solutions from different vendors, and those developed in-house, to federate. This means sovereignty does not come at the cost of interoperability, which is a balance that ‘walled garden’ proprietary systems cannot deliver.

In other words, all 27 EU members, and the EU itself, could all have their own sovereign Matrix-based solution for communications. And they could all remain in their specific solution (which is perhaps tailored to meet their own country-level requirements), while all being able to federate with each other.

We’re already seeing this play out. Germany’s public sector has multiple Matrix-based systems including the openDesk office suite, BundesMessenger and BwMessenger. Meanwhile, The City of Cologne runs Rocket.Chat enabling it to benefit from Matrix-based federation if it wishes. The French government is standardised on Tchap, which also sits within LaSuite; France’s sovereign office suite. 

Sweden has SAFOS Chatt, its own Matrix-based chat. Elsäkerhetsverke, the Swedish Electrical Safety Authority, uses Rocket.Chat and could therefore use Matrix-based federation to connect with other organisations. The European Commission and the UNICC use Element, NATO ACT uses its Matrix-based NI2CE Messenger. EU-Lisa and NATO Cooperative Cyber Defence Centre of Excellence (CCDCOE) both operate on Rocket.Chat so, again, can also federate using the Matrix open standard.

If they so desire, all of these country-specific communications platforms can federate - ensuring digital sovereignty and enabling cross-border federation. All without a dominant vendor, and all completely without any level of vendor lock-in.

Taken together, these deployments form a growing, federated network of sovereign communications across Europe - not a patchwork of silos, but an interconnected ‘network of networks’ ecosystem. Digital sovereignty, when built on open standards, enables communications without vendor dependency.

Since we launched the Element Server Suite (ESS) Community edition, we’ve been thrilled by the momentum. We are seeing a whole wave of new deployments and steadily growing engagement within the community. It’s clear that more people than ever want a robust, manageable way to host their own Matrix stack.

However, we’ve also heard a consistent question from those of you running older, "pre-ESS era" deployments: “How do I get my existing data into ESS without starting from scratch?”

Today, we are excited to answer that question. Available starting today, we are officially releasing an initial version of the ESS Migration Tool.

Why migrate to ESS?

For many long-time Matrix admins using Synapse, maintenance can be a manual burden including handling complex configuration, managing dependencies and keeping up with security updates.

By migrating to ESS, you leave that heavy lifting to Element’s ESS distribution. ESS is designed to make your life easier; once migrated, you can keep your system up-to-date, secure and packed with the latest Element features just by running a simple command. Furthermore you get all the components needed for a basic Element/Matrix stack out-of-the-box, curated and coordinated between each other, easy to deploy and maintain.

Introducing the ESS migration tool

The ESS migration tool is a dedicated tool designed to bridge the gap between your current Matrix environment and a modern ESS deployment. The tool automates the most tedious parts of moving to a Kubernetes-based ESS architecture:

• Configuration parsing: It takes your existing Synapse and Matrix Authentication Service (MAS) configuration files and parses them to discover secrets and linked files.
• Transformation: It converts those configurations into values files compatible with the ESS Helm chart.
• Kubernetes integration: It automatically generates the necessary Kubernetes Secrets and ConfigMaps.

The goal is minimal disruption. You can set up your new ESS environment and continue providing service to your users while immediately gaining access to powerful integrated features like Element Admin and Element Call.

A "breeze" for MAS migrations, too

Matrix Authentication Service (MAS) is the next generation of authentication and user management in Matrix. If you haven't moved your deployment to the MAS yet, ESS is your secret weapon. By migrating your environment to ESS Community first, you can utilise our built-in MAS migration tooling which automates the majority of the transition - check out the MAS migration guide. If you already have a MAS-enabled environment, no problem, you can still use the migration to get into ESS!

Getting started

The migration tool is available as a Python package and is licensed under AGPLv3. You can find basic instructions in the ESS Community repository. To help you through the process, we’ve prepared a comprehensive step-by-step migration guide as part of the tooling itself.

The roadmap: What’s next?

This first release is just the beginning. Our priority was to get this tooling into your hands as early as possible to gather feedback from the community. Over the coming months, we will be adding more functionality, including:

• Automated imports: Direct database and media file imports.
• Environment discovery: Automatic imports from existing Docker or Kubernetes contexts.
• System health: Integrated prerequisite checks to ensure a smooth transition.
• Expanded stack support: Migration support for Element Web, Matrix RTC/Livekit, and reverse-proxy configurations.

A note for commercial customers

While today’s announcement is a major milestone for our Community version, we haven't forgotten our Enterprise and Sovereign users. A top priority for our engineering team is facilitating a seamless "lift" from the ESS Classic stack to the modern ESS Pro environment.

The development to support customer migration paths is just around the corner and we are currently in the final stages of internal validation and will have more detailed news to share very soon. If you are an ESS Classic customer, you will be notified as soon as the Pro migration path is ready - and if you'd like to discuss your specific needs - please reach out to our support team.

Join the conversation

We want to hear about your migration experience. Your feedback directly shapes the future of this tool. If you run into any issues, let us know.

• Talk to us: Join the ESS Community Room.
• Report issues: Create a ticket in the ESS Community repository.

Start your migration today and experience the next generation of Matrix hosting!

First previewed during the Matrix Conference and detailed in the Glimpse into the Future blog post, the vision for a faster, more intuitive way to organise conversations is now a reality as Spaces are now officially available on Element X! 

This update brings a sophisticated digital architecture to the experience, replacing long room lists with structured, context-driven communication.

What are Spaces?

Think of Spaces as the digital architecture of your communication. Instead of an overwhelming list of individual rooms, Element uses Spaces to group related conversations into navigable, virtual containers. This structure delivers two primary benefits for organisational scaling:

• Effortless room discovery: Spaces provide an immediate overview of a specific team or project. Users can instantly see all relevant channels - for example, every room belonging to "Team X" or "Project Y" - ensuring that the right people always find the right conversations.
• Simplified access management: Element allows rooms to be configured so any member of a Space can join them without needing an invitation. This streamlines onboarding while still offering the flexibility to keep specific rooms within that Space "invite-only" for sensitive topics.

By organising by department, project, or interest, Spaces allow for seamless context switching. Users can move from a focused "Product Team" environment to a "Company News" world with a single tap - ensuring mission-critical focus and general updates stay perfectly separated.

Automated organisation for admins 

Spaces isn’t just about better organisation for users; it’s a powerful tool for administrators. If you are using Element Server Suite Pro (ESS Pro), you can now mirror your organisation’s actual structure directly within the app.

With automated memberships and permissions, admins can automatically assign users to the correct Spaces and rooms. For example, all members of your “IT Department” can be automatically added to the “IT” Space with the appropriate access rights the moment they join. This gives admins granular control over who can access, read and participate in conversations, ensuring your workspace remains secure and organised.

What’s new?

Spaces on Element X isn't just a port of the old system; it’s a complete redesign built for speed, reliability and clarity. As we modernise Element across Web, Desktop and Mobile, we are ensuring that Spaces feel like a native, seamless part of your workflow.

1. A smarter, cleaner chat list 

To keep the chat list clean and actionable, Element X utilises a high-level filtering system. Instead of clunky folders, a quick filter at the top of the chat list allows users to instantly narrow their view to a specific Space. This ensures that only the rooms relevant to a chosen context are visible, removing the noise of unrelated conversations.

2. Discovery at your fingertips 

The dedicated Spaces tab serves as a central hub for joined and created Spaces, enabling users to actively manage their environment and expand their reach. This interface allows for the immediate discovery of rooms within existing Spaces that a user has not yet joined, while providing admins with direct controls to manage memberships, adjust settings, or link new rooms to the structure. It also facilitates the creation of entirely new Spaces, offering a unified location to build and govern organisational architecture from a single, intuitive interface.

3. Flexible room creation 

Organisation starts the moment you create a room. You can now choose exactly where a room belongs during the setup process. Attach it to a specific Space so your teammates can find it instantly, or keep it "spaceless" for your own private or general chats.

4. Context before you join

No more guessing what’s inside an invite. With Space previews, you can see a description, the member count, and who invited you before you hit accept. This transparency ensures users understand the scope of a community before entering. 

Ready to dive in?

The wait is over. Spaces is one of the final pieces of the puzzle in making Element X the ultimate replacement for the "Element Classic legacy apps." It’s faster, it’s prettier, and it’s ready for you to use.

To get started, simply update your app to the latest version and look for the new Spaces icon!

Meedio will use Element Server Suite Pro (ESS Pro) as the server-side solution for its new communications platform. Launching in Q2, the Meedio solution will include its own front-end client including a Matrix-based video conferencing solution. Meedio will be available both on-premise and as a hosted service.

The Danish headquartered company will offer sovereign communications across Europe, with a particular focus on the Healthcare, Education and Public Sector. Meedio recently won a framework tender to supply Germany’s 1,100 universities with communications solutions, and holds TÜV and KBV certification for the German healthcare industry. Its hosted solution will initially be based out of Germany, with hosting available from other European countries as the service expands. 

Meedio’s communications solution brings another competitor into the Matrix-based communications ecosystem, giving public sector organisations and businesses yet more options when it comes to choosing between Matrix vendors. Meedio joined the Matrix.org Foundation as a Silver member in January 2026, and participated in The Matrix Conference 2025.

Infrastructure to enable customer focus

Using ESS Pro as the server-side solution for its Matrix-based service gives Meedio the ability to focus on its customer propositions. Rather than creating and maintaining backend functionality - such as scalable performance, identity and access management and record keeping - Meedio is free to dedicate all its development resources to its front-end products and services.

“So much of our success comes from listening to our customers, and giving them solutions to match their exact requirements,” says Runi Hammer, the founder and CEO of Meedio. “We’ll compete in the Matrix ecosystem by differentiating on the frontend client, such as our video conferencing and medical case boards. By using ESS Pro we have the best server-side solution available, so we can just focus on what we do best; delivering solutions to our customers.”

Runi Hammer

CEO Meedio

ESS Pro also provides a highly cost-efficient way of delivering a powerful hosted solution to small and medium size businesses across Europe. By using ESS Pro, Meedio can provide dedicated hosting to large customers, and multi-tenant hosting for smaller customers.

Matrix co-opetition

Meedio already has a strong installed customer base as a result of its enterprise-grade Matrix-based video conferencing solutions in healthcare, education and contact centres. Meedio will be expanding its Matrix-based frontend clients with domain-specific messaging, collaboration and integrations. It will both compete with, and complement, Element and other Matrix-based vendors.

"We're really excited to partner with Meedio - enabling them to provide excellent domain-specific Matrix clients by leveraging the best possible Matrix distribution from the team who created Matrix - Element Server Suite Pro.

“By joining the Matrix.org Foundation C.I.C. they show their commitment to the underlying Matrix project and we look forward to collaborating with them further."

Matthew Hodgson

Co-founder, CEO/CTO Element

Meedio delivers on-premise and hosted solutions for organisations with as few as five end-users, through to large public sector organisations and enterprises.

It’s great to see another European government, this time Belgium, using the Matrix open standard as the foundation for digitally sovereign communications. Matrix enables digital sovereignty through decentralisation, self-hosting and interoperability. As a result, it gives governments full control over their data and operations. 

By choosing Matrix, Belgium ensures it can work with any Matrix-based provider, switch vendors if needed, and avoid the long-term lock-in that plagues traditional communication platforms. Even European communications vendors, such as Wire or Threema, are built around vendor dependency. And yet vendor lock-in is the very opposite of digital sovereignty.

Whereas with Matrix, a government can create its Matrix-based communications solution solely in-house by building on FOSS components. Belgium is doing exactly that, which is testimony to just how much independence a government has over its Matrix-based communications.

With great sovereignty comes great responsibility

When a government standardises on Matrix, it is building critical communications infrastructure on open source software. It’s therefore imperative that the same government does its part to ensure the open source project on which it relies is healthy and sustainable. The open source project doesn’t sustain itself automatically. It relies on funding, active participation and collaboration. 

A government that spends millions on in-house development forking an open source project is far from an open source champion. Nor is it favourable for tax-payers or the local industry, as much of that development is reinventing what already exists in the commercialised product. Three or four years down the line, a government is left with a bespoke stack that’s hugely expensive to maintain and several steps removed from the ‘digital commons’ that was so appealing in the first place.

Working with the commercial upstream vendor is far more cost effective than building from FOSS components, particularly over the medium and long term.

Mindful procurement

With European governments scrambling to free themselves from vendor-locked systems, the exuberant embrace of open source software can see some parts of government struggle to maintain pace. Senior officials from a non-technical background, and public sector procurement processes, are often fairly unfamiliar with open source software. Fuelled by the strategic imperative of technological independence, procurement teams and others can adopt a seemingly independent ‘vendorless’ approach without fully understanding the implications - that they are sawing off the very branch they are sitting on by not ensuring the health of the underlying open source project, and thus the code they rely on.

It’s quite an irony that some governments who want to free themselves from proprietary platforms are simultaneously starving the upstream vendors that develop and maintain the open source alternative on which they intend to rely - incentivising it to become more and more closed source to survive - and preventing it from keeping up with the proprietary competition.

Organisations like the Open Source Business Alliance have already published guidance to help governments appreciate the complexity of responsibly procuring open source software - ensuring that upstream vendors who maintain the overall project are suitably financed to ensure the underlying software is developed and maintained.

Learning from others

In Germany ZenDiS - which is building the digitally sovereign openDesk office productivity suite - ensures that upstream projects are directly involved and properly funded via subscriptions to the vendors’ commercial offerings; paying for what they use, to keep the overall open source healthy. Projects like BwMessenger and BundesMessenger, both developed by BWI GmbH, also demonstrate strong collaboration with the Matrix ecosystem.

Sweden’s SAFOS initiative, the European Commission’s Element deployment, the Dutch Ministry of Defence and many others all show a similar pattern; governments embracing open source while actively supporting the vendors and communities behind it.

Working with upstream vendors doesn’t just support the overall open source project. Vendors provide more experience of the technology, enterprise-grade scalability and high availability, Long Term Support distributions, well-maintained integrations, and crucial features such as identity management, group-synchronised access control and audit capability. There is a significant difference between free-of-charge software for community use and software that’s designed for a nationwide government deployment. That’s precisely where an upstream vendor adds demonstrable value, and lower total cost of ownership. And it’s that revenue that helps, in turn, fund the overall open source project.

The hybrid ideal

As one of our European government customers said to us recently: “It’s not about FOSS vs paying for subscriptions. It’s not buy vs build. It should be a hybrid approach that works for all parties.”

Sovereignty is about choice, and by adopting open standards like Matrix governments will preserve sovereignty and interoperability. Open standards give governments an ecosystem of vendors to choose from. And that is far more sovereign than locking an organisation into a multi-million a year team to maintain an in-house fork. Besides, working with commercial vendors provides the support, stability and assurance that the upstream project needs to improve and compete with proprietary incumbents.

Through ready-to-use products, operational expertise and accountability, a vendor relieves a government of considerable complexity, cost and risk. With the combination of open source and professional software, a government ensures complete digital sovereignty, and can yet still customise its solution to suit its exact requirements; a level of bespoke customisation that a software vendor typically wouldn't deliver.

Solutions like Element’s enterprise offerings provide exactly that balance; cost-effective, secure and professionally maintained - and yet ensuring the openness and flexibility that guards against vendor lock-in.

The strategic importance of digital sovereignty and the interoperability provided by an open standard revolves around a government having complete control of its data and visibility on the technology stack used. Requirements of that magnitude deserve investment, for both the solution itself and the wider open source project that is there to benefit everyone.

The Cyber Resilience Act (CRA) is a major new piece of EU legislation that aims to bring security-by-design into how digital products are developed and brought to market across Europe. Adopted at the end of 2024 and applying from late 2027 (with some requirements coming into effect towards the end of this year), the CRA introduces baseline cybersecurity requirements for any product with digital elements placed on the EU market. This ranges from connected consumer devices to infrastructure software and secure communications systems.

The regulation aims to address long-standing security failures driven by misaligned incentives. Until now, software and hardware producers have often faced limited consequences for shipping flawed products, particularly in complex supply chains. The CRA seeks to change this by embedding security obligations directly into the lifecycle of digital products, shifting responsibility towards those who place them on the market. For open source projects and the organisations that steward and commercialise them, this represents a significant shift; while the CRA promises improved security and clearer accountability, it also raises important questions about scope, responsibility, and sustainability.

These challenges were explored in detail by Denise R. S. Almeida, Head of Policy & Compliance at Element and Data Protection Officer for the Matrix.org Foundation, in a presentation delivered at the Matrix Conference 2025. Drawing on Element’s experience developing and stewarding Matrix-based products, Denise highlighted how the CRA applies to open source software in practice and shared how organisations can begin preparing during the current implementation phase.

Watch the presentation about CRA from the Matrix Conference 2025

Understanding the Cyber Resilience Act

The CRA is a regulation, meaning it applies uniformly across all EU member states. Unlike other frameworks such as the GDPR, which are primarily assessed at an organisational level, the CRA operates at a product-by-product level. This reflects a deliberate shift in regulatory thinking; risk is no longer determined by company size, but by the nature of the product itself - particularly its ability to connect to networks, process data remotely, or form part of a wider digital supply chain.

The regulation was originally motivated by security concerns in areas such as the Internet of Things, but its scope is intentionally broad. Any product with digital components placed on the EU market must now be designed and developed with security in mind from the outset - supported by documentation, incident reporting processes and ongoing vulnerability handling.

Commercial intent and open source

One of the most significant and complex aspects of the CRA for open source communities is how it treats commercialisation.

In principle, non-commercial open source software is out of scope. However, many open source projects are published under permissive licences that explicitly allow commercial use. This has led to understandable concern about where responsibility lies if open source code is later incorporated into a commercial product.

Under the CRA, obligations attach to the entity that first places a product on the market with commercial intent. Publishing open source code alone does not trigger manufacturer responsibilities. If a third party forks a project and commercialises it, responsibility for CRA compliance rests with that party - not with the original developer or maintainer. This distinction is critical in ensuring that individual contributors and hobby projects are not inadvertently burdened by regulatory obligations.

Roles and responsibilities across the supply chain

The CRA introduces a clearer delineation of roles within the digital supply chain, including manufacturers, importers, distributors and open source stewards. Importantly, the role of an open source steward can only be held by a legal person, such as a company or foundation. Natural persons - individual developers - cannot be stewards under the regulation, a safeguard designed to protect volunteers and independent contributors.

Because the CRA applies at a product level, a single organisation may hold multiple roles across different products. This is particularly relevant for organisations like Element, which develops both commercial offerings and community-facing open source projects within the Matrix ecosystem.

For products first placed on the market by Element and offered commercially, such as Element Server Suite Pro, Element assumes the role of original manufacturer. This brings with it full responsibility for CRA compliance, including security requirements, incident handling and conformity assessments. These products will also carry a CE mark, which can be self-certified and signals compliance with the regulation.

By contrast, for community projects made available without commercial intent, Element acts as an open source steward rather than a manufacturer. While strong security practices remain essential, these projects do not require CE marking or the full set of manufacturer obligations. This distinction helps preserve openness while maintaining clarity around accountability.

Security requirements and operational impact

For manufacturers, the CRA introduces a number of concrete obligations. Products must be supported by appropriate cybersecurity measures, technical documentation and clear information for users. Manufacturers are also responsible for collecting and reporting security incidents and vulnerabilities to relevant EU authorities.

For organisations that already invest in security frameworks and structured vulnerability handling, these requirements will often build on existing practices. However, the CRA formalises these expectations and introduces additional coordination across engineering, security, legal and communications teams. Compliance is not a one-off exercise, but an ongoing responsibility throughout a product’s lifecycle.

Freeriding, incentives and sustainability

The CRA may also have an indirect but important effect on long-standing challenges within open source ecosystems, including freeriding. Organisations that currently package open source software into commercial products without taking responsibility for security may now be required to develop their own compliance processes from scratch.

By contrast, products backed by a clearly identified original manufacturer and a valid CE mark may become more attractive and trustworthy. While licensing remains a key mechanism for shaping behaviour, the CRA introduces structural incentives that could encourage more responsible engagement with open source supply chains.

Risks and unresolved questions

Despite its aims, the CRA introduces real risks for open source projects. Compliance requires time, legal and commercial expertise, and funding - resources that are often scarce in open source environments. There is also concern about how enforcement will be balanced across manufacturers, importers, and distributors - and whether obligations will be applied fairly in practice.

Another open question is whether the CRA could unintentionally push organisations towards proprietary solutions in order to simplify supply chain management. Ensuring that open source remains a viable and attractive option will require careful implementation, clear guidance, and sustained dialogue between policymakers and the open source community.

Why early engagement matters

The CRA is intentionally high-level, with detailed guidance still under development - just as we were working on this blog post new draft guidance has been published and is open for consultation until the end of the month. This makes early engagement essential. Organisations and communities need time to map products, understand roles, assess gaps and adapt internal processes. Just as importantly, they need to share experiences and concerns to ensure that implementation supports security without undermining sustainability.

Handled thoughtfully, the Cyber Resilience Act has the potential to strengthen trust in digital products and align closely with open source values such as transparency, collaboration, and secure-by-design development. But achieving that outcome will depend on continued engagement, shared learning, and a clear recognition of the realities faced by open source projects.

What this means in practice at Element

At Element, this work is already underway. Whilst this is not an exhaustive list, it is already very clear to us that for a product such as Element Server Suite Pro, which was first placed on the market by Element, we are the original manufacturer under the Cyber Resilience Act. On the other hand, Element Server Suite Community is not intended for commercial use, so falls outside the scope of the CRA. 

This means that for our commercial products we are responsible for meeting the CRA’s requirements across the full product lifecycle, including secure development practices, vulnerability handling, incident reporting and regulatory compliance. As part of this, we will be providing Software Bills of Materials (SBOMs) and applying a CE mark to these products. 

Being the original manufacturer also means being the organisation to which security disclosures are directed and the entity accountable for the product’s security posture. This aligns with a principle that already underpins how we operate; if we develop and commercialise a product, we take responsibility for it.

The CRA also brings important clarity for open source more broadly. If a third party forks an open source project and commercialises their version, responsibility for CRA compliance rests with that party, not with the original developer or maintainer. In practice, this means that organisations choosing to deploy and purchase products such as Element Server Suite Pro or Synapse Pro can rely on Element to demonstrate how the regulatory and security responsibilities associated with the CRA are being met. This clarity benefits both users and the wider open source ecosystem by making accountability explicit.

On Monday the General Dutch ⁠Intelligence Agency (AIVD) and Dutch Military Intelligence and Security Service (MIVD) announced a sustained Russian-backed campaign targeting Signal and WhatsApp users. 

It follows a similar warning in February, from Germany’s Domestic Intelligence Agency (BfV) and Federal Cybersecurity Office (BSI).

The attacks are based on relatively straightforward social engineering. Signal or WhatsApp users are targeted by fake Support Chatbots and then duped into divulging PIN codes or adding the attacker to conversations through ‘link device’ functions. Much like email phishing, it’s straightforward but effective; the Dutch agencies have acknowledged that the attackers are likely to have gained access to sensitive information.

The attacks are yet another example of why consumer messaging apps are not appropriate for use within governments. Intelligence agencies and other cyber experts have continuously warned that the likes of Signal and WhatsApp are frequently targeted because their end-to-end encryption gives government users a false sense of security. Yet end-to-end encryption is pointless when you can’t trust who is in the conversation.

Signal and WhatsApp are designed for consumer use only. They do not offer organisation-level administration or management, leaving government officials vulnerable to anyone who is able to contact them. Consumer messaging apps are - from an IT department point of view - “insecure by design” and therefore the very opposite of what governments should be using. 

Secure by design

Element Server Suite Pro protects against the type of social engineering attacks targeted at Signal and WhatsApp because it provides an enterprise-grade messenger. 

Most government deployments of Element are either ‘internal-only’ or for use within a ‘closed federation’ of trusted partners. As a result, it’s extremely difficult for an external attacker to even target government employees. 

End-users are managed through an organisation’s existing directory service - the systems that are trusted to identify and control access to all the organisation’s applications, as well as supporting single sign-on. In addition to protecting against external threats, end-user management also guards against accidental invites, such as the Signalgate incident.

Element's identity and access management stops Signalgate incidents

As a further line of defence, within Element Server Suite Pro, room administrators are able to insist that end-users verify their devices to ensure that devices are trusted. 

Adopting the correct security posture

Governments and other organisations that have to prioritise security are generally good at assessing risk, and adjusting their security posture accordingly. Many of our customers, for example, use Element for communications within their air-gapped environments. Some are even introducing cross domain gateways to connect high and low side communications.

Yet other parts of those same organisations can still have a blind spot when it comes to messaging apps. While budgets exist for air-gapped networks, or to replace a collaboration suite, many find it difficult to win a new budget to provide a sovereign messenger as an alternative to the unsanctioned use of (free of charge) consumer messaging apps.

Yet governments typically require dedicated, hardened communication systems that incorporate strict access controls, monitoring, and security policies rather than relying on consumer messaging services. 

Sovereign and secure

Talking of the latest attacks, Vice-Admiral Peter Reesink, director, Dutch Military Intelligence and Security Service, says: "Despite their end-to-end encryption option, messaging apps ​such as Signal and WhatsApp should not be used as channels for classified, confidential or sensitive information." 

Signal is a centralised vendor-controlled service, from a US headquartered organisation and runs its entire service on AWS. WhatsApp is owned by US headquartered Meta, one of the world’s largest data mining companies. Neither Signal or WhatsApp offer any level of sovereignty, and both are designed purely for consumer use - creating a raft of vulnerabilities for workplace use. And as Australia’s government concluded in March 2025, they also erode the democratic process through a lack of record keeping.

As European governments embrace digitally sovereign IT strategies to improve national security, they should also move decisively to ban government officials from using Signal and WhatsApp for government-related conversations. 

Simultaneously, they need to give officials a sovereign and secure alternative.

At FOSDEM 2026, the world’s largest open source conference, Neil Johnson (Element’s Chief Engineering Officer) explored the critical role of sustainability in open source software - with a focus on decentralised networks like Matrix.

Before we begin, most people can see why the sustainability of an open source software project is important. Open source software underpins almost all pieces of critical infrastructure, and we need to find ways to safeguard these projects. 

However, why is it especially important in a decentralised network? The whole promise of a decentralised network is the absence of a single point of failure, leading to a network that is both resilient at the technical and governance levels.

However Decentralisation without sustainability is just deferred centralisation. Without long-term, structured support, power inevitably consolidates in a few central nodes. This does not just apply to Matrix, we see it in the internet at large, where we have increasing centralisation due to a failure in finding sustainable ways to support our infrastructure - we also see it in political systems. 

So what does sustainability mean for Matrix? Matrix is a very ambitious project and Matrix sustainability means building a project capable of having the same transformative impact over the next 50 years that email has had over the last 50.

Watch the whole presentation

A brief history

Matrix began in 2014, when the founding team first came together within a larger organisation. Early successes led to the creation of Element to help fund ongoing development. From there, the Matrix Foundation was established as an independent, nonprofit entity, while Element continued as a for-profit company to sustain growth and feature development.

As the project grew, it became clear that funding features was only part of the story. The true cost of development includes maintenance, support, and long-term infrastructure - all of which are cumulative and increasingly complex as the system scales.

The challenge of sustaining open source

Maintaining open source software is critical, yet traditional funding models often struggle to capture the ongoing value required. While professional services can indirectly support maintenance, this approach does not cover all the essential work. Much of what ensures Matrix’s long-term health - including core protocol development, SDK maintenance, and infrastructure operations - falls outside the scope of paid services, making dedicated support and sustainable investment vital for the ecosystem’s future.

Element contributes significantly to the ecosystem, including:

• Significant sponsorship of the Matrix spec core team and heavy investment in spec authorship.
• Maintaining Element clients, matrix.org home servers, the Rust SDK, the JS SDK, Synapse, MAS, and the admin console.
• Conducting protocol research, building long-term features, and supporting trust, safety, and compliance.
• Advising on public policy and providing legal, financial, and operational support for the Matrix Foundation.

While more and more ecosystem participants are starting to support these efforts, especially via the Governing Board, the need remains vast. Moreover, the success of Matrix paradoxically introduces new challenges: large organisations may deploy Matrix without contributing upstream, which can create gaps in sustainability.

Funding the ecosystem: open source vs. paid features

So if feature sponsorship and support contracts are not enough, what did we do instead? We need some way to hold back value without limiting growth of the eco-system at large.

Element’s approach balances open source freedom with practical sustainability:

• FOSS (Free and Open Source Software): Core features that empower end-users, including standard client functionality, cryptography, spaces, and threads.
• Paid features: Specialised enterprise functionality such as clustering, high availability, or regulatory compliance.

Licensing also plays a role. Moving from Apache 2 to AGPL ensures companies that fork the code contribute improvements back to the community. Element’s CLA guarantees that contributions remain available to the project, even under changes of leadership.

This strategy has allowed support from organisations including NATO, the European Commission, and other public institutions, demonstrating that sustainable funding is achievable in decentralised networks.

Investing in the long-term horison

Sustainability enables Element and the broader Matrix ecosystem to plan for the future. Some key initiatives currently underway include:

• Matrix 2.0: A collection of 28 MSCs (Matrix Spec Change) authored largely by Element, designed to improve client and server capabilities and allow Matrix to compete with centralised alternatives.
• Element X migration: Transitioning users to the next-generation mobile client for a smoother, more modern experience.
• ESS Community: A distribution of the Matrix stack that simplifies deployment and reduces friction for new users and organisations.
• Accessibility improvements: Ensuring Matrix can be used by everyone.
• Matrix RTC and VoIP: Building secure, real time communication with the same cryptographic guarantees as messaging.
• Rust SDK: Providing a performant, reliable foundation for all Matrix clients.
• Protocol research: Including federation security, MLS, and peer-to-peer initiatives, ensuring Matrix can evolve over time.

ESS Community: making Matrix easy to deploy

Deploying a complete Matrix 2.0 stack - including Synapse, MAS, a LiveKit backend, and the Sliding Sync proxy (while it existed) - was complex, particularly for smaller organisations or casual users. To simplify this, Element provides Element Server Suite Community (ESS Community), our official open source distribution for non-commercial Matrix deployments.

ESS Community is designed for easy setup and experimentation, making it ideal for evaluations, small to mid-sized deployments (1–100 users), or casual use. It offers a fully packaged stack aligned with Element’s robust enterprise practices, while allowing installations to complete quickly - even in live demonstrations. 

By lowering the barrier to entry, ESS Community enables new organisations to adopt Matrix easily, contribute back to the ecosystem, and explore the full capabilities of Matrix without the overhead of enterprise-grade deployments.

It’s important to note that ESS Community is a community-focused distribution. It is distributed under AGPLv3, emphasising its open source, community-driven nature while making clear that users are responsible for their own deployments. ESS Pro is designed for organisations, offering company directory integrations, audit logs, compliance tools, Mobile Device Management, Cyber Resilience Act compliance, and other enterprise-focused capabilities.

The Element X experience

If you haven’t made the move from the Element Classic app to Element X yet, now’s the time! Element X represents the next‑generation Matrix client - a complete rethink of the Element experience from the ground up. Rather than being a simple update to the existing app, Element X was rebuilt with performance, reliability, and usability at its core, drawing on modern architecture and the new Matrix 2.0 stack.

At the heart of Element X is the goal of delivering a fast, familiar, and dependable user experience across platforms. This means prioritising the things that matter most to people every day:

• Smooth migration from legacy apps — keeping continuity so users can transition seamlessly from classic Element clients to Element X without losing context or functionality.
• Full support for core Matrix features — including Spaces and Threads, with ongoing improvements to make these experiences feel intuitive and complete.
• Incremental delivery of smaller features — tackling gaps in functionality one at a time, with the aim of completing all major remaining work by April 2026. This phased approach lets users benefit from improvements now while long‑term work continues behind the scenes.
• Consistent ecosystem adoption — encouraging users and organisations across the Matrix ecosystem to standardise on Element X as the default experience, helping unify workflows and expectations

Takeaways

Thanks for following along! Over the course of my talk at FOSDEM (and this post), we’ve explored why sustainability is essential for decentralised communication, how Element X is shaping the future of Matrix clients, and how ESS Community makes it easier than ever to deploy and experiment with Matrix. We’ve also highlighted the challenges of maintaining open source software and the importance of supporting upstream development to keep the ecosystem healthy and growing.

With that in mind, here are some key takeaways:

Decentralisation without sustainability is just deferred centralisation. Supporting the Matrix ecosystem in a structured, long-term way is essential to ensure it remains truly decentralised and resilient.

Use Element X. If you haven’t already, it offers the best experience and represents the future of Matrix clients - fast, reliable, and fully featured.

Try ESS Community. It’s simple to install, robust, and enterprise-ready, making it easier than ever for new organisations to adopt and explore Matrix.

Support upstream development. Choose vendors who actively contribute to the ecosystem — sustainable funding is what drives ongoing innovation, reliability, and the long-term success of decentralised communication.

By investing in these areas, we ensure that Matrix continues to grow as a truly decentralised, user-controlled communication platform capable of serving both individuals and organisations for decades to come.

At FOSDEM 2026, members of Element’s VoIP team - Robin Townsend, Timo Kandra and Valère Fédronic - presented a deep dive into the future of real time communication on Matrix. 

Their talk gave an update on MatrixRTC, Matrix’s framework for bringing voice, video, and other live, interactive experiences directly into rooms. Their contributions to Matrix enable everything from large-scale calls and collaborative tools to multiplayer games, virtual worlds, and entirely new ways for people to interact in real time.

Watch the whole presentation

Advancing real time communication on Matrix

We’ve been working on MatrixRTC as part of our work at Element, to build the foundations for large-scale, secure VoIP solution into matrix. This work is done by the same team that is behind Element Call. Element Call, the VoIP part of Element, sits on top of MatrixRTC.

Matrix has traditionally focused on persistent, asynchronous messaging. Real time communication (sub 100ms), however, introduces a very different set of requirements. It demands low latency, flexible participation, and should be ephemeral. At the same time, it must preserve Matrix’s core principles of decentralisation, federation, and security.

Historically, Matrix clients only supported 1:1 peer-to-peer WebRTC calls, using Matrix rooms primarily for call-oriented signalling and persisting what was effectively ephemeral state into room history. As calls grew larger and use cases expanded beyond simple voice and video, it became clear that real time communication needed first-class support in the Matrix protocol itself, with the flexibility to support multiple use cases beyond 1:1 calls.

MatrixRTC is our attempt to make real time applications native to Matrix, striking a balance between decentralisation and the practical demands of scalable, low-latency, end-to-end encrypted media and data exchange. Through concrete demos and implementation details, we showed how this approach enables entirely new classes of applications, including calls, games, virtual worlds and collaborative tools.

Introducing slots for interactive rooms

MatrixRTC introduces the concept of slots, which allow room administrators to add real time communication features to their rooms. These slots can be anything from voice or video calls to 3D virtual worlds or multiplayer games. Each slot combines an application - which specifies the type of data participants exchange - and an identifier, allowing multiple parallel sessions in the same room.

The first application we’re adding to the specification is m.call, which covers basic voice and video calls. But third-party apps are fully supported, enabling developers to create custom experiences like virtual simulations or collaborative games.

Slots are managed via state events, ensuring that they are persistent, authorised, and can be moderated by room admins. When participants want to join a slot, they connect by sending membership events and publish their media over a chosen transport. A transport in this context is a WebRTC SFU (Selective Forwarding Unit). Currently supported is the LiveKit SFU. FullMesh WebRTC or a websocket solution are also considered while designing with MatrixRTC.

Other features, like delayed events, notifications, and encryption, are also part of the specification. For deeper technical details, past Matrix Conference talks and the Matrix Spec Proposals repository are excellent resources.

Sticky events: reliable, ephemeral data delivery

It is essential to provide a good experience before joining a session. A client should be informed immediately via sync about any ongoing MatrixRTC session. To avoid polluting room state with this information, sticky events are introduced. These events are ephemeral, low-privilege, and can be encrypted. During a limited lifetime (for example around an hour), their delivery is guaranteed over sync. They are stored in the room timeline rather than in the authoritative room state that is subject to state resolution. Sticky events are ideal for real time session participation, letting clients join ongoing calls or sessions and immediately receive the necessary data, even if they missed some events earlier due to gappy-syncs (more on sticky events here).

Transports: keeping real time communication decentralised

Each participant chooses their transport, which can be a home-server resource or a peer-to-peer connection. For Element Call, we currently use LiveKit media servers, which handle the heavy lifting of fan-out for media streams. This approach allows large calls to scale gracefully while keeping the system federated, decentralised and efficient. For example, in a typical office environment, many users converge on the same homeserver, minimising connections needed to participate in a large call.

A MatrixRTC SDK for developers

With these protocol improvements, we also refactored our codebase, creating a MatrixRTC SDK that simplifies building real time applications. The SDK handles the complexities of connecting to multiple SFUs, authenticating with Matrix, managing sticky and delayed events, and exchanging media. Developers can now use this SDK to build applications, such as games or collaborative tools, without having to handle the underlying real time infrastructure directly.

For instance, we demonstrated a simple HTML template application using the Godot game engine, leveraging the MatrixRTC SDK. Through this setup, developers can access observable real time data to integrate it into games. The MatrixRTC SDK is used as an abstraction for core capabilities such as user identity and account setup, device verification, encryption (not shown in the demo), media connectivity via an SFU, and the existing Matrix backend infrastructure.

Building on MatrixRTC: live demos

To showcase what’s possible, we built two multiplayer games using MatrixRTC. Players communicate over federated servers, exchange real time events, and interact seamlessly despite network variability. Although live demos sometimes face latency challenges, the system handles rollbacks and syncing to ensure a smooth experience.

We showed Godot-MatrixRTC-FlappyRoyal, a game similar to FlappyBird, and Godot-MatrixRTC-Keyboard-Kart, a racer-like multiplayer game.

Games and other applications can be run as widgets, providing an added layer of security. The trusted Client handles encryption and key management, so users never expose their full Matrix account or keys to external real time apps running inside the Widget.

Looking ahead

Currently, the MatrixRTC SDK is available in JavaScript, but the widget architecture allows the low level Matrix responsibilities to be done in other SDK’s. The Matrix Rust SDK, for instance, supports the widget postmessage api. Widgets are based on iFrames. With Wasm becoming more mainstream, this opens the door for real time applications beyond the web stack, from Godot-based games to custom simulations.

MatrixRTC represents a significant step forward for Matrix, enabling decentralised, real time, and interactive experiences in rooms while maintaining the federated, secure principles of the ecosystem.

At FOSDEM 2026, Denise R. S. Almeida (Head of Policy & Compliance at Element and Data Protection Officer for the Matrix.org Foundation) presented a practitioner perspective on the recently proposed Digital Omnibus. This ambitious legislative package proposed by the European Commission seeks to harmonise key concepts and simplify requirements across a range of digital regulations, including the General Data Protection Regulation (GDPR), the Data Act, and the ePrivacy Directive, with the goal of reducing administrative burdens and boosting innovation. However, as many have pointed out, simplification cannot be used as a justification for deregulation - especially when it comes to core definitions associated with our human rights.

She shared her perspective on what the proposal could mean for open source projects and communities using Matrix as a case study, highlighting both the opportunities and the risks it introduces.

Watch the whole presentation

Understanding the Digital Omnibus

The Digital Omnibus is a complex effort to harmonise overlapping European regulations. Its explicit goal, as defined by the European Commission, is to make compliance simpler, reduce bureaucracy, and ultimately free organisations to focus more on innovation. For open source projects, which often operate on limited budgets and volunteer-driven resources, these changes could be particularly meaningful.

Key proposals include simplified cookie rules to address consent fatigue, improved access to data, alignment of terminology across different regulations, and the creation of a unified reporting system for incidents and breaches. While nearly 200 pages in length, these proposals collectively aim to reduce friction in the regulatory environment and provide a clearer path forward for developers, organisations, and communities alike.

Opportunities for open source communities

There are a few ways the Omnibus could benefit open source projects. One of the most significant is streamlined reporting of breaches and incidents. Today, organisations must navigate multiple frameworks and timelines across different authorities. A single reporting system would allow teams to dedicate more time to understanding root causes and preventing incidents, rather than juggling administrative obligations. This poses to be the most impactful operational shift introduced by the Omnibus.

Another key opportunity is standardisation of Data Protection Impact Assessments (DPIAs). Many open source projects face the same privacy and security challenges but often tackle them independently, reinventing the wheel each time. Standardised DPIAs could provide templates and shared best practices, giving projects a head start on compliance while maintaining user trust.

Overall, reducing legal complexity and creating clearer guidance could allow open source teams to focus on development, community engagement, and innovation, rather than legal paperwork. For a sector where every contributor hour counts, these changes could have a tangible impact on productivity and creativity.

Risks and concerns

While the Omnibus focuses on the idea of “simplification”, there are also key risks, particularly around changes to the definition of personal data under the GDPR. This is effectively a risk of deregulation, the consequences of which must not be taken lightly. Currently, personal data is defined as any information that can directly or indirectly identify an individual. The Omnibus adds new nuance, expanding on the definition which could introduce ambiguity:

Ambiguity in such a foundational definition carries serious implications and would essentially amount to a form of deregulation and, as many others argue, could represent a constitutional shift to the European approach to personal data protection. It could increase complexity, confuse compliance efforts, and even create loopholes for excessive processing of personal data without any protection obligations. For open source projects, clarity and transparency are essential: contributors need confidence that sharing data and collaborating openly won’t expose them to legal uncertainty. Any dilution of core protections risks undermining the trust and transparency that open source communities rely on.

While harmonisation and simplification are welcome, they must not come disguised as deregulation or be pushed forward at the expense of personal data protections or the principles underpinning European digital sovereignty. Open source relies on predictability and clarity in law; introducing complexity into a core definition threatens both.

Why participation matters

The Omnibus is still open for consultation until March 11, 2026, in the form of the Digital Fitness Check call for evidence. This provides a critical window for the open source community to contribute. Everyone is  encouraged to review the proposals, identify potential risks, and provide feedback. This is an opportunity to ensure that regulatory harmonisation  supports innovation without compromising fundamental human rights, such as privacy.

Open source communities bring a unique perspective, balancing practical development constraints with strong commitments to user rights. By engaging with the consultation, developers, project maintainers, and contributors can help shape a framework that protects users, reduces administrative overhead, and allows open source projects to thrive.

Striking a balance

The Digital Omnibus represents a dual challenge: it promises simplification, clarity, and reduced bureaucracy, but it also introduces a serious risk of deregulation as well as complexity in areas that benefit from clarity, such as the core concept of personal data in the GDPR. Open source projects could benefit from the Omnibus if these proposals are implemented thoughtfully, but only if the foundational protections for personal data remain strong and unambiguous.

Therefore communities must actively participate, share insights, and highlight overlooked risks. Only by engaging can open source projects ensure that Europe’s regulatory framework remains strong whilst supporting innovation, safeguarding users, and strengthening trust across digital ecosystems.

Note: since her talk the European Data Protection Board (EDPB) and the European Data Protection Supervisor (EDPS) have adopted a joint opinion which highlights similar concerns to those raised at FOSDEM:

“The EDPB and the EDPS strongly urge the co-legislators not to adopt the proposed changes to the definition of personal data as they go far beyond a targeted or technical amendment of the GDPR. In addition, they do not accurately reflect and clearly go beyond the CJEU jurisprudence, and they would result in significantly narrowing the concept of personal data. The European Commission should not be entrusted to decide by an implementing act what is no longer personal data after pseudonymisation as it directly affects the scope of application of EU data protection law.”

Element’s multi-tenancy implementation of Synapse Pro has secured a Good rating in a penetration test commissioned by gematik, Germany’s national digital health agency.

The security analysis rating is an important milestone in the widespread adoption of gematik’s TI-M Pro standard, which creates a sovereign, interoperable and secure messenger for healthcare professionals, by embedding healthcare specific requirements on top of the decentralised Matrix open standard.

Gematik commissioned an external service provider to conduct the pentest. It used active exploitation techniques to assess the security status of Element's Synapse Pro multi-tenancy implementation - as used in Element Server Suite Pro for TI-Messenger - against best practice criteria, validate security mechanisms, and identify application-level vulnerabilities.

The resulting report found that: “The security of the tested application is rated as ‘Good’. Key interfaces of the Synapse Pro server, including both interfaces for Matrix clients and the server-to-server API, behaved in the examined solution in a manner consistent with a deployment scenario in which a dedicated Synapse instance is used for each tenant.”

The successful gematik pentest now brings external security validation to ESS Pro for TI-M, making it a proven and mature solution; ESS Pro for TI-M already being the server-side component in T-Systems’ TI-M ePA compliant communications solution for BARMER, which launched in July 2025.

A catalyst for local healthcare practitioners to adopt TI-Messenger

Multi-tenancy ESS Pro for TI-M is the first solution available to enable hosting providers to deliver a cost efficient TI-M Pro compliant service to family doctors, local clinics and high street pharmacies. 

Total cost of ownership efficiencies are driven by optimisations within Synapse Pro to reduce RAM usage and associated costs by around 90%, and server-side fleet management features to simplify the administration of thousands of multiple deployments.

For the first time, hosting providers now have a professional server-side solution to deliver affordable TI-M Pro compliant services profitably - even to small healthcare organisations with just a few employees.

A competitive marketplace is now ready to explode as healthcare technology providers race to provide TI-M Pro compliant communications to local healthcare providers. The ecosystem can now build their own frontend TI-M Pro clients, knowing that self-hosted ESS Pro for TI-M is a proven, cost efficient and secure solution backend.

The benefits of a professional server-side solution for TI-Messenger

Element Server Suite Pro for TI-Messenger (ESS Pro for TI-M) is the only standalone server-side product available for healthcare technology providers, enabling them to build their TI-Messenger solutions on top of a vendor-backed server built for TI-Messenger. It includes Synapse Pro, a TI-M Messenger Proxy, Push Gateway, dedicated Federation List Service for TI-M and stays aligned with evolving specifications.

Synapse Pro, an enhanced version of community Synapse, dynamically scales to save resources during low demand and automatically cover demand spikes to ensure performance. Resource savings for large single tenant deployments (meeting TI-M ePA standard) are typically in excess of 80%, and for multi-tenant (meeting the TIM Pro standard) are usually in excess of 90%. ESS Pro for TI-M also ensures stable operations with minimal downtime as it enables High Availability deployments, along with Element’s SLA, technical support and regular security updates. Perhaps most important for multi-tenancy deployments, ESS Pro for TI-M includes effective administration features to make it easy for a hosting provider to manage thousands of small hosts individually.

Organisations not using ESS Pro for TI-M have to build their own backend, typically by building from scratch on Element’s community FOSS Synapse implementation and then servicing the associated technical debt and maintenance burden. The community version of Synapse is not designed for commercial use. A host with just five end-users has a memory footprint of around 150MB, which is considerable for a service provider wanting to host 50,000 small hosts (for, say 50,000 local pharmacies) and makes providing such a service uneconomic. A subscription to ESS Pro for TI-M removes all of those challenges in an instant.

Multi-tenancy within ESS Pro for TI-M allows the pooling of resources, keeping costs predictable and performance consistent - while preserving the isolation each tenant requires. Each shard can support up to 50 tenants, with every tenant segregated at a database schema level. The solution is delivered with a Kubernetes controller to manage the shards and their tenants dynamically (via a tenant management API that is provided by Synapse Pro), and enables integration with continuous deployment tooling and GitOps processes for automation.

Similarly Element’s TI-Messenger Proxy is designed for performance, efficiency, and compliance. Built in Rust, it benefits from modern memory safety and concurrency models, reducing operational risk by eliminating data races. With an idle memory footprint of just 10 MB - compared to around 800 MB in the TI-M reference implementation - it is exceptionally resource efficient. The proxy fully complies with the latest TI-M Pro and TI-M ePA specifications, integrates with the FHIR Directory via a dedicated Federation List Service, and supports automatic, load-dependent scaling to ensure high availability and resilience.

A deep dive on multi-tenancy within ESS Pro for TI-M, given at Matrix Conference 2025.

Focus on your own frontend client

The successful pentest signals a game change for secure healthcare communications. With ESS Pro for TI-M providing a state-of-the-art server-side component for a TI-Messenger compliant solution, healthcare technology providers can focus their own development efforts on creating an outstanding frontend client for frontline healthcare professionals such as family doctors, local clinics and high street pharmacies.

Understanding and meeting healthcare professionals’ exact requirements will determine healthcare technology providers’ marketplace success, without having to focus on reinventing TI-Messenger server-side performance and features. Just as laptop and smartphone manufacturers work with semiconductor firms, the TI-Messenger ecosystem is now mature enough for healthcare technology providers to use highly specialised components as a part of their own overall solution.

Europe has been pursuing a digitally sovereign strategy for many years. The strategy entered the limelight back in 2019 when Ursula von der Leyen, European Commission President, called for Europe to “achieve technological sovereignty in some critical technology areas.” 

With war on the edge of the EU, and an apparent breakdown of the rules-based international order, European governments are seeking full control of their technology with ever more urgency.

The definition we hear most often from our European government customers is “the ability to operate our technology even if we’re the last country we can rely on.” That means real digital sovereignty equates to ensuring a government has the decision-making power and technical flexibility to completely self-manage a solution, and having the ability to easily choose and switch between trusted vendors. 

Governments must have agency over the technology they use 

Genuine digital sovereignty goes far beyond a European government buying European software. It means a government not having to rely on a specific vendor - European or otherwise. A vendor can disappear, or go rogue, for a variety of reasons; from chasing profits to ending up with an HQ that is in a country that has become hostile. 

In a world that can no longer trust interdependence, a government cannot leave itself vulnerable to the threat of critical digital services being withdrawn. So a government is left with the choice of developing and maintaining all its own technology - the antithesis of focusing on core competencies - or working with industry to build digitally sovereign technology that guards against vendor lock-in to ensure a government has autonomy over its technology.

Open source software and ideally open standards provide a large part of that model. The transparency of open source software makes it ideal for digital sovereignty. Even if governments use an upstream vendor for a particular solution, the majority of the underlying code is available as FOSS which gives governments the ability to bring the solution in-house or change vendor, which is even easier if the solution is based on an open standard, as it will encourage a vibrant ecosystem.

Europe, as a continent, already has a strong open source industry. EU countries account for 22% of GitHub repositories accounts, comparable to that of the United States (23%) and substantially higher than that of China (≈10%). It makes perfect sense for Europe to build on its open source strengths and work to super-charge its open source software projects and companies.

Europe is making good progress in supporting open source and open standards as a matter of public policy. The European Commission's DG DIGIT has an open source software strategy which is being renewed this year, Europe possesses three European Standards Organisations, including CEN, CENELEC (together CEN-CENELEC), and ETSI, and it has in the past experimented with open source funding through the Next Generation Internet programme.

Governments need to stoke the ecosystem, not compete with it

For all the positivity, there is still much more that could be done. European open source software is underfunded, and overly reliant on volunteer ecosystems and SMEs which have to fight to get paid. There should be more investment, better procurement mechanisms and institutional mechanisms to aid the development of durable open source products, companies, policies, and infrastructure. 

Open source needs to be recognised for its transparency and sovereignty. The subscriptions that have been paid to US vendors should be redirected to European upstream vendors, rather than being allocated to in-house bespoke software development. That means integrating open technologies into industrial and public procurement policies, and aligning national strategies around open technologies that transform latent strength into increased sovereign capability.

If executed properly, the positive impact of open source strategies goes beyond sovereignty. Each euro invested in open source software multiplies its impact across the European economy, not only helping to ensure sovereignty but also driving economic growth and job creation.

Open source, AND open standard

The relationship between European governments and European open source software is symbiotic. It is hugely inefficient for governments to build and maintain their own software solutions from scratch. They need to work with software vendors. However, a European open source software vendor cannot promise genuine sovereignty if its product locks customers into that vendor. Being locked to a vendor, even if it’s European and open source, is not fully sovereign. Both sides need to commit to the principle of interoperability.

In the context of communications - Element builds on the Matrix open standard. Implementations of Matrix components are FOSS, as is the majority of Element. A government can take a Matrix-based solution in-house if circumstances dictate. The French government was an early adopter of Matrix and, with some support from Element, has created and now maintains Tchap (and LaSuite).

Other governments, including Germany and Sweden, subscribe to Element’s enterprise-grade product built for governments. That removes the maintenance burden, and ensures out-of-box enterprise-grade scalability, features and compliance - along with SLAs, technical support and all the rest of the benefits associated with traditional commercial software. That’s a standard buy or build decision.

The benefit of interoperability is that, should Element turn out to be problematic, a government can turn to any other vendor in the Matrix ecosystem rather than face the significant challenge of a ‘rip and replace’ solution. This is the power of choice that is so important within digital sovereignty. It doesn’t mean doing everything yourself, it means working with open source software vendors that are part of a competitive ecosystem built on a common standard. 

Open discussions

We doubtless all wish that the drivers for digital sovereignty are less fundamental than national security. Never-the-less it is exciting to see European governments reappraise their use of technology and embrace open source software from European vendors. This is an opportunity to improve the resilience of our nations, and strengthen our ability to negotiate with other countries. It brings with it the opportunity to transform our ways of working, and perhaps be less vulnerable to huge centralised systems that have the power to destabilise. And every Euro of tax-payers’ money invested in European open source is also an investment in Europe’s economy. 

Amandine Le Pape is Co-Founder and COO at Element and Co-Founder of the Matrix.org Foundation, as well as a founding member and the Head of the Business and Impact Section at the European Open Source Academy.

At FOSDEM 2026, the world’s largest open source conference, David Baker (Staff Software Engineer and the original author of Element Web) and Florian Duros (Senior Software Engineer) presented an inside look at Element Web - from its early days to the bold plans shaping its future. They shared how the team is modernising the platform to be faster, more reliable and more flexible - all while keeping the experience seamless for the millions of people who rely on it worldwide.

Watch the whole presentation

Where we started

Element Web first launched in 2015 alongside the Matrix JS SDK. Its earliest prototype was small, simple, and lightning fast - switching between rooms felt instantaneous. But it came with trade-offs: features like end-to-end encryption, Spaces, and other core Matrix functionality weren’t yet in place and, as the platform grew, so did the complexity and technical debt.

The initial architecture leaned on a Flux-style model (“good God, Marty”) and a shared SDK, matrix-react-sdk, which was intended to be a reusable foundation for any Matrix app. In practice, however, it became tightly coupled and increasingly difficult to maintain. Business logic often lived inside UI components, making updates and improvements tricky as React evolved and the wider web ecosystem changed. On top of that, code quality fluctuated, reflecting both that particular project’s open-source nature and the evolving practices of a growing team.

Despite these challenges, Element Web has laid the groundwork for everything that followed. It became a fast, flexible client trusted by millions and widely adopted across the ecosystem. Projects like BundesMessenger in Germany and LuxChat in Luxembourg, along with countless other organisations and community deployments, have shown the value of a web-based Matrix client that is both reliable and trusted. This strong foundation now sets the stage for the next generation of Element Web.

Why this matters

We believe decentralised communication must be fast, reliable, and competitive with closed-source alternatives. While many in the Matrix community appreciate the platform’s values, broader adoption will only happen if everyday users find the experience familiar and fluid - not something they put up with because they “get it.” To achieve this, Element Web needs to feel as polished and performant as mainstream consumer apps.

This is exactly why we have been evolving our architecture and building shared components. These provide a foundation that is both flexible and future-proof while maintaining a smooth, reliable user experience.

Our Vision: Shared, reusable, UI-first components

Rather than rewriting Element Web from scratch, which would be risky and disruptive, we are evolving it piece by piece. The core idea is to break the app into shared components - building blocks that focus purely on the user interface. They do not contain any Matrix business logic, they work independently of the underlying SDK, and they handle display and interaction only.These components know what to show and what actions to trigger, but not where the data comes from. This separation allows us to reuse them across different apps, not just Element Web, but also clients like Aurora and modules for Element Web.

We started with smaller components and are now tackling larger parts of the interface, including the room list and timeline tiles. After that, we will move on to panels like the Spaces sidebar and login or registration screens. Each shared component has its own module with clearly defined interfaces, which means we can improve the UI and accessibility without touching the data layer.

This approach also allows us to gradually replace how data is fetched without rewriting the entire app. Shared components already allow us to reuse UI code between Element Web and Aurora, avoiding duplication, improving maintainability, and ensuring a consistent experience across clients.

A Modern Architecture: MVVM

At the heart of this transformation is the Model-View-ViewModel (MVVM) pattern. In MVVM, models represent data sources, whether that’s the JS SDK, the Rust SDK, or simple in-memory stores. Views are the shared components - the UI elements that display data and handle user interactions. ViewModels sit in between, translating data into a form the views can use and managing the actions that views trigger.

This separation makes it easier to maintain, test, and evolve both the UI and the business logic independently. In practice, shared components declare what data they need, and the view model provides it. That data can come from legacy sources or newer backends like the Rust SDK, allowing us to modernise the architecture without rewriting everything at once.

Better tooling, accessibility and testing

As part of this work, we’ve modernised our tooling to make development faster, safer, and more reliable. Shared components are built with Vite and documented using Storybook, making it easier to explore and understand each piece of the UI.

We use visual tests to capture light and dark theme states, interface variations, and accessibility concerns early in the process. Automated tests help catch regressions and ensure features behave consistently across different contexts.

This focus on tooling and testing improves not just performance, but also stability and confidence. The result is a more reliable Element Web for developers, contributors, and users alike.

The Rust SDK and what comes next

A key part of our long-term plan is integrating the Rust SDK into Element Web via WebAssembly. The Rust SDK already powers Element X mobile apps, delivering dramatically improved performance and memory efficiency. Bringing that same core to the web will unlock similar benefits for Element Web users.

Our shared component approach makes this transition possible. Because the UI and views are decoupled from the data sources, we can gradually replace the underlying logic, including syncing, without rewriting the entire interface.

This approach allows us to continue delivering user-facing improvements while we integrate the Rust SDK. It gives us the best of both worlds: ongoing enhancements for today and a modern, high-performance foundation for the future.

What this means for you

This phased approach allows us to evolve Element Web progressively, reduce technical debt over time, and roll out UI improvements across multiple apps. At the same time, it prepares the web client for the next generation of Matrix SDKs.

We’re excited about the path ahead and hope this gives you a clear view of the work already underway and what’s coming next. Stay tuned for more updates, and as always, we welcome your feedback as we continue to refine and improve Element Web and our shared UI platform.

Cloud-based communication platforms like WhatsApp, Microsoft Teams, Signal or Zoom are widely adopted and generally considered “secure enough” for everyday enterprise collaboration. For defence organisations, and other sensitive areas, that assumption does not hold.

Modern SaaS platforms require organisations to entrust their communications to vendor-controlled cloud services, frequently operated under foreign jurisdictions. In a defence context, where communications are intrinsically tied to national security and operational integrity, this loss of control is not a theoretical concern. It is a structural risk.

At the same time, commercial vendors continue to prioritise cloud-first offerings, leaving self-hosted and on-premise systems to stagnate. The result is familiar across defence environments; outdated, siloed communication platforms that no longer reflect how people actually need to work. Email remains the backbone of communication in many organisations, despite being ill-suited to real time coordination or sensitive operational use.

When official tools fall behind, shadow IT fills the gap

Where sanctioned communication tools fail to meet user needs, unofficial alternatives inevitably emerge. Consumer messaging apps such as WhatsApp, Telegram and Signal have quietly become commonplace within defence organisations, used for both professional and personal communication. This behaviour is rarely malicious. More often, it reflects a lack of suitable alternatives being made available. Simply banning these tools is rarely effective. They are intuitive, habitual, and deeply embedded in daily communication. 

The challenge for defence organisations is not simply to prohibit the use of consumer messaging, but to offer an alternative that is just as usable and meets the requirements of the organisation; digitally sovereign, enterprise-grade and secure. 

The challenges caused by centralised, vendor-controlled system

Consumer messaging apps are often seen as secure because they highlight end-to-end encryption. In reality, organisations have little control over the service itself, the influences it’s under or how data is governed. Centralised vendor-controlled architectures offer limited oversight, minimal auditing, and create single points of failure.

These risks are not theoretical. When an AWS datacentre in Northern Virginia failed, for example, hundreds of thousands of organisations - including Signal, Slack and Zoom - went offline showing how a single third-party failure can disrupt critical operations. For defence organisations, this highlights the operational risk of relying on cloud systems that cannot be governed, controlled or independently hosted. 

A decentralised model for sovereign communications

In a volatile world, defence organisations require communications systems that are sovereign, resilient and fully under their control - while remaining able to connect with trusted partners. Achieving this demands a fundamentally different architectural approach.

A decentralised structure allows each organisation or nation to operate its own infrastructure under complete legal and operational control. It also provides a robust and resilient network that guards against global outages.

To make such a system practical, decentralised communication should be underpinned by an open standard to enable separate deployments to interoperate. Vendor-neutral federation allows each organisation - such as multiple allied forces - to maintain its own infrastructure while communicating multilaterally when and where it wishes across multinational operations.

An open standard for decentralised communications

Matrix is the leading open standard for secure, decentralised communication. Governed by the independent Matrix.org Foundation, it provides a common protocol designed from the outset to support sovereignty, interoperability and end-to-end encryption.

Rather than locking organisations into proprietary platforms, Matrix enables a diverse ecosystem of interoperable clients and servers, making it possible for defence organisations and partner forces to collaborate securely while retaining full control over their own systems. This approach has driven rapid adoption across government and defence, where control and transparency are non-negotiable. 

From protocol to platform

In practice, a defence-grade Matrix deployment combines a secure, user-friendly messaging client with an enterprise-grade backend - such as Element Server Suite Pro - that provides identity management, auditing and controlled federation. This foundation enables modern, real time communication without compromising ownership or control.

This model is already proven. NATO ACT’s NI2CE Messenger demonstrates how decentralised, sovereign messaging can be deployed at scale, supporting secure BYOD communication while retaining organisational oversight and trust. Built on the Element client and powered by Element Server Suite Pro, NI2CE shows what is possible when secure communications are designed for the realities of defence.

The way forward

Defence organisations face a clear choice: continue relying on ageing systems and unsanctioned consumer apps, or adopt a communication model designed for sovereignty, security and interoperability from the ground up.

Our whitepaper explores how decentralised communications enable defence organisations to modernise securely, reduce shadow IT, and regain control over their communications infrastructure. It also includes a decision making tree on methods and options on how to create your own sovereign and secure messenger.

New whitepaper

Real time communication is mission-critical, but legacy systems and consumer apps put defence operations at risk.

Download

In an ideal world, end-to-end encrypted (E2EE) messaging apps would work identically to their non-E2EE counterparts (e.g. transport-layer security only), without introducing any additional inconvenience for users.

In reality, in an environment where the server should not have the ability to read any of your messages, many “simple” problems become much harder to solve. Every user who has tried using an E2EE messaging app for some time, has probably felt the results of that one way or the other. Perhaps when you first sign up, and start on just one of your devices, everything seems as usual. You can create chats, you can send and receive messages. However, when you want to add a new device, or when you lose your very first device, things get more challenging - the usual “everything is in the cloud and I can unlock it with a reset to my password”, is no longer true.

Without an always-on server which is trusted to access users’ messages, things become challenging because users often have many devices - phones, tablets, laptops, etc. They may need to have a new device at any time, they may lose their devices - and it could be that at some point they have lost all of their devices. As usual, there are tradeoffs in solving those new challenges and, because no one has infinite budgets or time to launch their product, compromises have to be made. Those could be limitations on how the app can be used (for example, most apps have limitations on how many devices you can log into), a more complex model that the user needs to understand (many apps have a concept of a special “primary” device which is harder to replace than other “linked” devices) or additional user responsibilities (if you want to get access to your messaging history even if you have no logged in devices, you must have previously securely stored a recovery key for that purpose). As the technology matures, it is expected that some of these limitations will be eliminated or relaxed and user experience will improve at the same time. However, there will always be something that can not be fully eliminated compared to a non-E2EE app. If you have an electric car - even if the range and charging experience improve over time, you still need to charge it.

As one might expect, not all vendors have made the same amount or type of compromises. Let’s see how they compare in terms of the limitations that they have and the corresponding user experience.

Let’s start with the number of devices. Element does not limit the number of devices a user can have. You can have any number of desktop or mobile devices, using either native apps or browsers to connect. This is of course great from a user experience point of view - there’s no friction, just like a non-E2EE app. Also, the model is straightforward because there is no differentiation of “primary” or “linked” device. You can at any time add a laptop, throw away your old phone, and then add a new phone later - everything keeps working. If you need to have two phones, you can have two phones. All devices are “equal” and provide all the available features.

In contrast, WhatsApp and Signal enable just one (primary) phone and then a few linked devices (tablets, laptop). WhatsApp does have “companion mode” which allows the addition of up to four “companion phones” but there are limitations such as the need to log in to the primary phone at least every 14 days, to keep your account active. Threema 2.0 (still in Beta) has support for multiple devices, but it is still limited to one primary phone and a couple of linked devices. Wire is limited to eight devices out of which one can be a temporary device. Telegram does not directly limit the number of devices, however, E2EE chats only work on a specific device where you start them - which essentially limits them to a single device; hence Telegram is also not considered in the remainder of this blog as it is much more limited and hard to compare to the other E2EE apps which are at least attempting to make E2EE work in a device-agnostic manner.

Another classical hurdle for E2EE apps, has been the ability to access your messaging history on a new device that you have just added. Element provides that in a seamless manner. It works out of the box, with no specific user actions required to make the history visible. There are also no limitations on how far back you can go - you get the whole history. Of course, signing in to a new device on Element requires you to either have access to one of your existing devices or to your recovery key¹ (a 48-character random secret that only you know) - but that is a security feature which is hard to avoid and which serves several other purposes besides seeing the history on a new device. For super-sensitive users or use cases, there is an option to turn this feature off.

The other apps have limitations on what you can see on the new device or how much manual effort is needed to see it. Essentially, two categories exist.

WhatsApp and Signal automatically provide you with the history on the linked device; and of course you need your primary device to link a new device to do that. There are limitations, though. WhatsApp provides you with a history of 12 months. Signal provides you with unlimited history of text messages but media is limited to 45 days (as media itself is not embedded in the transferred data - a link to a copy on Signal’s servers is sent instead, and on Signal’s servers the retention is 45 days).

Note that the above only applies when you add a new linked device. If you’re replacing your primary phone, it is a different story. In that case, to get your history on the new primary device, you have to restore it from cloud backup (assuming you have set it up before) or use a phone-to-phone transfer (assuming you still have your old device).

Wire and Threema do not offer any chat history on a linked device in a seamless automated manner. You need to manually export and import between the two devices. The Threema Safe allows you to sync your ID and contacts, but not the chat history.

What about accessing the history when you have lost all of your existing devices? This does not mean that all of those devices have physically ceased to exist, but that they are no longer accessible to you - the apps and data may have been wiped, etc.

In the case of Element that is straightforward - as long as you remember where you stored your recovery key and can get it, you can retain access to the full history of all your chats. This of course does come with some additional responsibilities on the user side when compared to non-E2EE apps

• the user needs to set up recovery, which is a very simple process: the user is prompted to do it in the app and there are no external dependencies (such as a cloud provider for backup storage)
• the user must also securely store the recovery key (a 48-character secret generated during the recovery setup process).

However, the user does not need to think about where to store the backups, how often to create them, or how to secure them. How much friction storing the recovery key causes depends on the use case and environment - but it is certainly, both easier and safer, than asking the user to manually create backups and restore them - and still remember the decryption key. A typical consumer can store the recovery key in their favourite password manager together with the other secrets they have to remember. The experience for such users can also be relatively easily improved by providing an integration with the password manager, instead of manual copy and paste. There are also organisations who deploy password managers for their staff, but that is not always the case. Organisations always prefer a unified and automated solution that works the same way for all of their users, rather than relying on each of their employees to go and store it in their password manager in the correct manner. Thus, in such an environment, the challenges are harder to overcome.

Signal and WhatsApp are somewhat similar to Element, since there is a “cloud backup” option, but the implementation is different. WhatsApp depends on iCloud or Google for the backup storage. Signal does not depend on external platforms, and hence you always need your recovery key, just like with Element, to recover your history. WhatsApp allows you to just use the encryption provided by the platform (iCloud or Google), but you can add another layer of encryption if you want, in which case you also need to store the recovery key for decryption.

Wire and Threema do not offer anything automated out of the box: you would need to create backup files manually and export them to a location where you want to store them.

What about the ability to retain your cryptographic ID when you lose all of your devices?

In case of E2EE messaging, the username and password (or phone number, depending on the app) to log into your account are still needed and useful for a number of things. However, such authentication of yourself to your provider is not sufficient for end-to-end encryption. For that purpose each of the users (and their devices) have a key pair that is generated in their device when they log in for the first time.

For those who are not familiar with the basics of cryptography - imagine if Alice had an infinite number of locks which all open with a key that only Alice has. If Alice wants Bob to send her something securely, they meet and Alice gives Bob a large portion of these locks - in an open state so that Bob can use them to lock a package but only Alice has the key to open the package. This key and the locks can be considered as Alice’s cryptographic ID. Of course, this is a simplification because in reality each message is not directly locked (encrypted) with the same lock/key but it is good enough for explaining and understanding the problem.

The problem is that only Alice (and her devices) can have that key - otherwise it would not be E2EE - and if all her devices are gone, the key is gone too. That means, Alice needs to get a new key and corresponding infinite amount of locks. While this part is easy, she also needs to meet Bob, and everyone else she is messaging, to hand over the new locks to send her the messages so that she can open them. Such in-person handover is needed, as otherwise somebody could impersonate Alice and start stealing and opening the packages Bob is going to send to Alice.

While in a virtual world there is no literal in-person meeting to hand over the locks, there is still effort involved for both Bob and Alice in order to keep things secure in case Alice resets their ID. The minimum is that Bob is notified about that reset - which gives Bob at least the ability to check with Alice (via other independent channels) if it was really her who lost the key, and had to reset. Another layer of protection that some of the apps apply is to block messaging with Alice and require the two users to perform a verification of the new ID (involves communication via another independent channel) to make sure that a man-in-the middle is not spoofing Alice’s new ID. This is typically the case if Alice and Bob performed such a verification when they first started to communicate.

Different apps use different wording (e.g. “Your security code with Bob has changed” or “Bob’s identity was reset”), and they make it more or less prominent, but essentially they are all pointing out the same issue that is described above. Thus, it is also obvious that such ID resets should happen as rarely as possible - otherwise they become noise that everybody just ignores and no one ever bothers to check if this was the person themselves or a malicious party. In particular, because most regular users probably won’t understand what this exactly means and how to behave, it is something that does not exist in the non-E2EE world.

In the case of Element, the cryptographic ID is backed up to the server when you set up recovery (the same recovery that is mentioned above for message history). While the corresponding key-pair leaves your device, it is encrypted with your recovery key. Thus if you have access to your recovery key, you can always retain your ID and can continue communicating with your contacts as if nothing happened. This is, of course, a trade-off - having to reset your ID often is bad, but if your recovery key leaks or gets stolen, your ID gets stolen as well. Thus, setting up recovery on Element is not mandatory and each customer or user can choose the right level and type of protection depending on their use case and scenarios.

Signal does not offer an option to back up your cryptographic ID, even when you have set up the (message) backup, and have your recovery key. You can get access to your message history, but you need to create a new ID. WhatsApp behaves effectively in the same way - there’s no way to retain your cryptographic ID.

Threema does offer the option to retain the ID via the Threema Safe. To restore your identity, you need to know your 12-word recovery phrase or QR code.

Wire offers to retain your ID via its ID Shield feature (only available on the on-premise deployment, and requires a paid enterprise plan) without the user needing to store a recovery key or a similar secret. However, since it is accomplished via a server-side central and trusted infrastructure (e.g. a certificate authority issues a certificate, if the user provides enough proof of their identity), it can not be considered a superior solution but rather a trade-off where the trust anchor moves from the users (and their devices) to a trusted server.

That’s not all! There are more features that look “obvious” for anyone who has used a messenger before but which are not necessarily available in the context of E2EE messaging. One of them is the ability to get access to past messages when you join a group chat. If you told anyone using Slack or Teams that they could not see history when they are invited to a channel, they would find this shockingly bad. Now, to be fair, there are cases when you do not want that - but it's one thing not to want this for a specific chat, and quite another not to have it at all. In most workplace use cases, this ability is a must-have.

In the case of Element, we allow² the user to decide for each group chat whether they want historic messages to be shared with new members or not: if they are shared then users are able to see and successfully decrypt those historic messages. This applies to the entire history of the chat, and if someone changed the history visibility setting during the lifetime of the chat, only messages sent during the time when history sharing was turned on are accessible. A current limitation is that the new user needs to be explicitly invited (added) to the group chat by someone because someone needs to share the decryption keys for those historic messages (this is worth highlighting because there are other ways to join a chat on Element besides being explicitly added by someone).

Signal, Threema and Wire have no ability to provide history to someone who was added to the chat later. WhatsApp is able to provide a history of the last 24 hours. It is limited because the admin of the chat is re-encrypting those messages for the new member.

Finally, what about the ability to read messages that were sent while you were logged out everywhere? It is again something that is obvious in non-E2EE messaging - but becomes difficult to accomplish if you can only rely on end-users' devices.

Element currently offers limited support for this (requires using Element Web or Desktop client, with experimental MSC3814 explicitly enabled on the server) in a beta stage. It creates a virtual device (via a process called device dehydration) for the user and stores it on the server so that messages can still be encrypted for this user, even if the user has zero physical logged-in devices. The entire virtual device is fully encrypted on the server and no secrets are available to malicious admins or men-in-the-middle, but as it potentially still increases the attack surface (given an attacker who manages to dehydrate the device can steal both your identity and message history), it is only activated when the user has set up recovery and is ready to make that trade-off.

On WhatsApp (primary phone) there’s no literal logout button - because that would only cause you trouble. However, an equivalent situation occurs when you uninstall WhatsApp on that physical device and then install it on a different device. In such a case you may be able to receive and decrypt the messages that were sent while you did not have a running app on any of your devices. It is a “maybe”, because it requires the sender to be online (in order to re-encrypt the message for the new device) and it works only if not too much time has passed since sending the original message (exact limit not known, but 24h was not too much).

Signal is similar in the sense that there is no literal logout button on the primary phone, but unlike WhatsApp, the messages that were sent while you had no app running won’t ever be delivered to you.

Wire offers you two ways of logging out. If you log out without “Deleting all your personal information and conversations on this device” - you are able to get and decrypt the pending messages that were sent while you were logged out. This means the cryptographic keys that power the E2EE are kept on the device. If you choose to delete this data when you’re logging out, you’re not able to get any of the pending messages when you log back in.

Threema does not also offer a literal logout function but you can delete your data on the given device, or you can reinstall the app to simulate that. None of the backup functions (e.g. the Threema Safe or the Backup on local device) will provide you with the messages that were sent while you had no devices.

As a summary, Element is able to offer many of the table stake features of non-E2EE apps, for example accessing history on new devices, accessing history when you lose all of your devices and retaining your ID when you lose all of your devices. It can do that with a simple device model (e.g. no limited number of primary or linked devices and the related complexities that the user has to learn), and offers the ability to configure the app according to the needs of the use case - balancing privacy and convenience. There are of course some new things the end user needs to do and learn - what a recovery key is, how to securely store it and when to use it; but fortunately, that is the only thing the user has to learn to get almost the same experience as with non-E2EE apps. We are continuing to find ways to make storing and retrieving the recovery key both easier and more secure for the end users.

¹ For the sake of clarity, besides a generated key, in the past Element apps also allowed the users to enter their own passphrase for recovery purposes.
² This feature will be generally available soon, but early adopters can already try it out by turning on the feature flag “Share encrypted history with new members” under Labs (in Element Web/Desktop) or Developer Settings (in Element X, mobile).