Across Europe, a familiar decision is being made in capital after capital. Governments are right to conclude that sensitive business should not depend on consumer messaging apps and that official communications must remain under national control. France runs Tchap. Germany operates BundesMessenger. Belgium, Poland, Luxembourg, and others have launched national equivalents, and NATO has built one for its own staff. The direction is unmistakable. The sharper question is whether sovereignty is best delivered by owning the code, or by owning the controls that determine where the system runs, who holds the keys, whose law governs it, and who is accountable for keeping it secure.

BlackBerry Secure Communications approaches this question from long experience inside government-grade secure communications, including deployments where national control, domestic operation, and certified assurance are non-negotiable. Sovereignty should be the standard. The question is whether a self-built platform or certified technology deployed on national terms delivers stronger control over time — and what a country must sustain to keep that control secure.

Build or Deploy on National Terms

Governments usually have two routes to sovereign control of official communications:

1. They can build or fork its own platform and operate it itself;

2. They can deploy certified commercial software entirely on its own terms: on national infrastructure, with the encryption keys held by the state and no one else, approved by its own national authority, and operated inside its own borders.

Both paths can put a government in control. The difference is not the goal, but the operating model a country accepts to reach it. A self-built platform concentrates responsibility for patching, certification, staffing, resilience, and long-term funding inside one national program. A certified commercial model can preserve national control while drawing on engineering depth, vulnerability response, and operating experience already sustained across a broader customer base.

The build path appeals for understandable reasons: It feels like the fullest expression of independence; modern tooling has made a working prototype faster to stand up than ever; and a national platform can be presented as an investment in domestic capability. None of those motivations are wrong. But they describe the moment of launch. The harder test is what the country must fund, staff, certify, and defend after the platform is live.

What a Build Commits a Country to

Almost none of the national messengers now in service were written from nothing. Most are forks of the same open-source foundation, adapted and then maintained by the state from that point forward. It is a reasonable engineering choice. It also means the government inherits everything downstream of that foundation — and inherits it permanently.

Standing a platform up is a project, with a beginning and an end. Running it securely is a permanent function of government. It means continuous patching, round-the-clock operations, recurring certification, in-house cryptographic and security expertise, and public accountability when something goes wrong.

A build is often quoted as a one-time figure. The real number is the ten-year cost of ownership, most of it arriving after launch. Continuous patching, a security operations center, recurring certification, and the specialists behind them cost roughly the same whether they serve one government or fifty. A vendor maintains that capability once and spreads it across every customer. A government that builds its own carries the whole of it on a single national budget. 

The same operational load exists on both paths. The difference is whether one national budget carries it alone.

The Threat has Changed the Calculation

There is a newer dimension that anyone weighing the build path today should hold in view. As automated tooling compresses the time between a vulnerability becoming public and its being exploited, the constraint that matters is no longer whether a government can afford to patch. It is whether it can patch inside the window before the flaw is used against it.

Earlier this year, one of these national platforms was breached. No encryption was broken and no flaw was exploited in the software itself. A single user account was compromised through social engineering — and that was enough to reach the unencrypted public rooms the architecture makes readable to any authenticated user. The encryption did its job. The exposure appears to have come from the architecture around it: a model inherited from an open-source foundation and maintained within a single national program.

Depth matters because vulnerability response depends on telemetry, threat intelligence, engineering capacity, customer visibility, and fast testing and deployment. A small national team waiting on an upstream fix it does not control is at a structural disadvantage in a race now measured in hours. An organization that runs vulnerability response across a broad customer base is positioned to move faster as the threat accelerates.

Resilience carries the same logic. The ability to hold up under peak load, degraded networks, and infrastructure that may itself be under attack is proven in use across many deployments, not demonstrated for the first time during a platform’s own first national incident.

When exploitation follows disclosure in hours, accountability for the fix matters more than authorship of the code.

More than a Messaging App

There is one further part of the picture a messaging fork does not address. Securing voice and messaging is real work, and a fork that delivers it has done something substantial. But secure communications is broader than messaging alone. The device the conversation runs on must also be protected, or the exchange is only as strong as the endpoint beneath it. When an incident crosses agencies that share no chain of command, the response must also be coordinated across them. Each layer is its own build, with its own certification and operating burden. A fork delivers the first layer. A government that wants the full capability is, in effect, committing to build and sustain more than one platform.

Sovereignty Is Control, not Authorship

Underlying all of this is a confusion worth naming. Sovereignty is sometimes treated as a question of who wrote the code, when it is really a question of control: who holds the keys, where the system runs, whose law governs it, and who answers for it. A government can write every line and still depend on a foreign upstream for security fixes. It can also deploy commercial software while holding every control point that matters, when the architecture is built for it.

That is the distinction any government weighing this choice should hold onto. The goal is not authorship for its own sake. The goal is control over where the software runs, who holds the keys, who certifies and operates it, and who answers when it must be defended. Authorship can be one route to that control, but it is only one route. The engineering depth, operational attention, and budget a self-built platform demands every year are finite. What is spent here cannot be spent on the rest of a national security mission. Among like-minded nations, resilience is strengthened by depending on one another where it makes sense, rather than each rebuilding the same foundation alone.

Secusmart offers one example of this model in practice. It is a German company, engineered and operated within Germany’s own structures and certified by its federal authority. Its work in secure government communication has been part of the national landscape for years. It shows that sovereignty does not have to mean rebuilding every layer alone. Governments should demand sovereignty without compromise, then count the full ten-year cost before deciding which model to own.