The Certified Information Systems Auditor (CISA)’s recent warning about two critical vulnerabilities in TeleMessage TM SGNL—actively being exploited by threat actors—has prompted stakeholders to sit up and take notice.
The US federal cybersecurity agency strongly urged organizations to immediately implement any vendor-provided mitigations, underscoring the severity of the flaws.
“In the case of TM SGNL, the vulnerabilities arose from multiple severe design and implementation errors, undermining the intended security and resulting in what can best be described as “security theater”,” said Kee Jefferys, co-founder of Session, an open-source encrypted messaging app, in a conversation with Invezz.
The growth of decentralized messaging apps is being driven by a convergence of factors: rising privacy concerns, growing distrust of Big Tech, advances in blockchain and peer-to-peer architecture, and shifting regulatory environments.
While Session has earned praise for its commitment to anonymity and metadata resistance, some tech reviewers argue that Signal—another encrypted messaging platform—strikes a more mainstream balance by combining strong privacy protocols with user-friendly, community-building features.
“In Session’s case, it’s built for users who need anonymity and metadata resistance, even if that means making a few trade-offs on features or UX,” Jefferys said.
He also touched on the rising institutional interest in decentralized messaging platforms and why he believes that departments such as national security and foreign service are likely to explore these technologies more seriously in the coming years, especially for internal communications involving sensitive or high-risk scenarios.
Excerpts:
On the CISA flagging vulnerabilities in TM SGNL
Invezz: The CISA directive highlights vulnerabilities in TM SGNL. What, in your view, made these flaws so dangerous despite the use of end-to-end encryption?
End-to-end encryption, when implemented correctly, prevents anyone outside the conversation from accessing users’ messages.
However, in the case of TM SGNL, the vulnerabilities arose from multiple severe design and implementation errors, undermining the intended security and resulting in what can best be described as “security theater.”
Rather than a single isolated flaw, it was a chain of poor design decisions that ultimately exposed user data.
First, TM SGNL created an unencrypted copy of every message sent in a conversation and then stored this copy on a server.
This practice effectively created a honeypot of sensitive data, making it highly attractive to attackers.
Second, the server publicly exposed a URL from which anyone could download the current state of its memory.
As the server received and processed these unencrypted messages, it stored them in memory alongside sensitive authentication details, including users’ weakly hashed passwords.
Combined, these vulnerabilities allowed an attacker, even one with relatively limited sophistication, to routinely download server memory, extract authentication information, breach user accounts, and access plaintext conversations.
This scenario underscores a critical point: secure protocols are only as strong as the underlying code quality and infrastructure implementation.
How decentralisation reduces risk structurally
Invezz: You’ve argued that single-vendor control is the real threat. Can you walk us through how decentralization structurally reduces this risk?
Absolutely. When one company controls everything, including the code, the servers, the updates, even a single mistake can put everyone at risk.
Decentralization spreads out that control, reducing ability to target any one server to achieve a full network compromise.
In networks like Session, there’s no central server to attack, nor any single entity holding all the messages.
Instead, the network consists of independently operated nodes distributed around the globe, and the source code is openly available for anyone to inspect.
As a result, rather than relying on the trustworthiness of a single vendor, you have a system purpose-built to function without needing trust at all.
Difference between Session and Signal
Invezz: Session is often touted as a fully decentralized, metadata-resistant messenger. How does your infrastructure fundamentally differ from Signal or other encrypted apps?
Most messengers still depend on centralized infrastructure, Session is different.
Session operates on a decentralized onion-routing network inspired by Tor, specifically built for messaging.
Instead of relying on central servers, Session routes messages through a series of community-operated nodes, effectively concealing users’ IP addresses from any node storing their messages.
Additionally, Session doesn’t require a phone number, email, or any other real-world identifier to create an account.
All messages are end-to-end encrypted, and unlike traditional TM SGNL, Session never sends an unencrypted audit log of users’ communications to a central server.
Session’s use case and ongoing efforts to improve usability
Invezz: Some tech reviewers have said that while Session offers a level of privacy which is great for security purposes, Signal blends robust privacy policies with helpful community-building features, making it appealing to a wider audience. What are your thoughts on this?
That’s a fair take. Signal has done an amazing job making private messaging feel seamless, especially for people who aren’t privacy experts.
In Session’s case, it’s built for users who need anonymity and metadata resistance, even if that means making a few trade-offs on features or UX.
But Session is definitely not ignoring usability, Session contributors have been working hard on improving the UX, by simplifying technical jargon and making it easy to jump in and start messaging without having to worry about the technical details.
On institutional demand for decentralised messaging
Invezz: Do you see institutional or enterprise demand for decentralized messaging growing? If so, what verticals are showing early traction?
Absolutely. Session is seeing growing interest from journalists, NGOs, whistleblowers, and legal professionals, basically anyone who handles sensitive information or needs to keep communication private.
Some DAOs and privacy-focused startups are starting to explore decentralized messaging too.
It’s still early, but the common thread is they all want strong privacy and infrastructure that doesn’t have a single point of failure or control.
As regulations tighten and data breaches pile up, decentralization is starting to look less like a niche and more like a necessity.
Gov branches like national security/ foreign service likely to explore decentralised messaging
Invezz: Do you believe governments will ever seriously adopt decentralized messaging protocols, or will they remain dependent on vendors they can oversee?
That’s a tough one. Governments naturally prefer control and auditability, which often leads them toward proprietary or vendor-managed systems.
However, as the TM SGNL incident clearly illustrates, this centralized approach carries inherent risks.
I anticipate that certain branches of government, particularly those dealing with national security or foreign service, will increasingly explore decentralized solutions for sensitive internal communications or high-risk scenarios.
We probably won’t see immediate, widespread adoption overnight, but the escalating cost and impact of security breaches are compelling enough to make even traditionally risk-averse institutions reconsider their approach.
The post Interview: Anticipate certain govt depts to start exploring decentralised messaging, says Session co-founder Kee Jefferys appeared first on Invezz