The message is encrypted. Who is in the conversation?

What happened

On 9 March 2026, AIVD and MIVD warned of Russian account-takeover attacks targeting officials, including Dutch government employees. Attackers sought verification codes and abused linked-device features. The services said individual accounts were targeted; the messaging services themselves had not been broken.

The participant list changes during an operation

Consider a coordinator handing an incident over to the next shift. A private contractor has finished work, a specialist joins for one question and a field colleague replaces a lost phone. These are ordinary operational changes. Each can alter who should be able to receive the next report. A group name or familiar profile picture does not establish that the participant behind it still has the same role or that a replacement device has been approved.

The practical challenge is to make those changes visible to the people responsible for the conversation. Someone needs authority to approve a new participant, verify the request and end the old access. That responsibility should survive a shift change. A security design also needs to distinguish withdrawing future access from recovering information already received. Once a participant has obtained a document or recording, removing them from a group cannot by itself guarantee that every copy disappears.

The risk crosses the public–private boundary

A ministry discusses a disruption with an electricity operator. A municipality coordinates with a port terminal. A defence supplier shares a site report with its customer. These are illustrative situations, but the responsibility is concrete: each organisation must know which information can leave its environment, and with whom.

Encryption protects a communication path. It does not decide whether the person behind an account is still authorised, whether a contractor has left, or whether a request really comes from the crisis lead. A compromised participant can sit inside an otherwise protected conversation.

What a secure operational channel must establish

• Identity and access. Named people, approved devices, verified partner invitations and a tested way to revoke access. Check a sensitive request through a separate trusted channel.
• Information boundaries. Agree the sensitivity level, permitted recipients, storage location, retention and ownership of encryption keys. Classified work requires an appropriately approved environment.
• Responsibility. Attach a report to its incident, time and location. Name the decision owner and record acknowledgement; a delivered message does not confirm that someone acted.
• Continuity. Prepare a fallback that does not depend on the same account or infrastructure. Exercise a lost phone and an unavailable primary channel.

From another chat group to one working picture

An illustrative Meridian deployment would bring authorised messages, reports and positions into the incident context. The security design must be validated with both the public body and the private operator: authentication, endpoint management, encryption, key custody, access controls and records policy. This is not a claim of accreditation for classified use or a guarantee against account compromise.

Follow one report across the boundary

Imagine a field team sending a site observation to an authorised public–private incident group. The report carries its location, observation time and source. A coordinator requests a technical assessment, assigns it to a named person and records the acknowledgement. The assessment then becomes part of the incident history. This is a proposed workflow to design with users, not a description of an existing government deployment.

The application should help participants distinguish a question, an instruction and a confirmed outcome. If a request appears unusual, the agreed process can require verification through a separate trusted route. When a file is shared, its permitted recipients and retention need to be known. Optional voice, video and AI transcription add further decisions about processing, copies and review. These requirements belong in the project scope alongside the communications features; they cannot be inferred from the presence of encryption alone.

Exercise the end of access as well as the start

A useful pilot would test an invitation, a shift handover, an external participant leaving and a suspected account compromise. Users should be able to explain who owns each response and what record is retained. Technical teams must demonstrate the required authentication, revocation, audit and retention controls before operational acceptance.

European control becomes concrete in the same exercise: identify the hosting operator, maintenance responsibilities, processing locations and support access. Then remove the primary channel and test the fallback. The goal is an agreed way of communicating through changing circumstances, with a visible boundary between information people may share and information that requires a different approved environment.

Communications built around your mission.

Meridian designs and develops secure communications software for government bodies, defence organisations and private operators. We can build standalone applications for messaging, voice and video calls, and file sharing, tailored to your users and security requirements.

The question is not only whether outsiders can read a message. It is whether every person inside the conversation should still be there.