# Sovereign Communications

> *"Your incident response plan assumes your communication platform is available. Your incident response plan is wrong."*

## For the Executive Reader

Every organisation has a single communication platform — Teams, Slack, or similar — that depends on the same corporate identity, the same internet connection, and often the same Microsoft or Google account as everything else. When an incident takes down corporate IT, the communication platform goes down too. When Active Directory is compromised, the attacker can monitor your incident response in real time.

Sovereign communications solves this with a two-tier architecture:

- **Tier 1 — Delta Chat**: A 10-minute deployment on independent infrastructure. Encrypted, works on mobile, requires no corporate account to log in. Used as an out-of-band channel and crisis fallback.
- **Tier 2 — Matrix/Element**: A full sovereign messaging platform for organisations that want to own their primary communications entirely — no vendor dependency, federated, self-hosted.

These are not competing products. They serve different needs and often both are deployed.

*For the module overview, see [Modular Engagements](../core/modular-engagements.md#module-14-sovereign-communications).*

---

## Why Communications Infrastructure Is a Security Control

Most organisations treat their communication platform as a productivity tool and their security tools as a separate category. This is the mistake. Communication infrastructure is:

| Risk Category | Exposure |
|--------------|---------|
| **Incident response dependency** | If Teams is down during a ransomware attack, how do you coordinate response? |
| **Identity dependency** | M365 Teams requires Entra ID. If identity is compromised, the communication platform is too. |
| **Insider threat surface** | A compromised admin account can read every Teams channel in your tenant silently. |
| **Vendor continuity** | A Teams or Slack outage is outside your control. Your response capability should not be. |
| **OT/Crisis operations** | Control room operators cannot rely on a communication tool that depends on corporate IT — especially when the incident is in the corporate IT. |

**The antifragile principle**: Your crisis communication channel must be independent from the infrastructure that might fail during the crisis.

---

## Tier 1: Delta Chat

### What It Is

Delta Chat is an open-source messaging application that uses **email as its transport layer** — specifically IMAP/SMTP with Autocrypt end-to-end encryption (OpenPGP). It looks and works like a modern instant messenger. It is, technically, encrypted email.

### Why This Is Antifragile

| Property | Why It Matters |
|----------|---------------|
| **Runs on email infrastructure** | SMTP/IMAP is the most resilient, federated, widely deployed protocol in existence |
| **Works with any email account** | No new accounts, no new server required if existing email is used |
| **E2E encrypted by default** | Messages are encrypted before leaving the device; the server never sees plaintext |
| **No accounts to compromise** | Delta Chat uses email addresses — there is no separate "Delta Chat account" to take over |
| **Federated** | Anyone with an email address can participate; no walled garden |
| **Works on mobile without corporate MDM** | Personal devices can be enrolled in crisis channels without corporate management |
| **Open-source and auditable** | No opaque server-side processing; the encryption implementation is public |

### The Two Deployment Options

#### Option A: Use Existing Email Infrastructure

Delta Chat can be pointed at any existing IMAP/SMTP server. If the client already has a stable email platform, Delta Chat adds encrypted messaging on top of it with no new infrastructure.

**Best for**: Adding encryption and a better UX to existing internal communication; M365/Exchange clients who want an encrypted channel without new servers.

**Limitation**: If the email server goes down, Delta Chat goes down. The communication channel and the email infrastructure are the same.

#### Option B: Deploy a Chatmail Relay (Recommended for Crisis/OT)

**Chatmail** is a purpose-built, minimal email relay optimised for Delta Chat. It is not a full mail server — it is designed specifically to be fast, lightweight, and easy to deploy as a Delta Chat backend.

| Chatmail Property | Detail |
|------------------|--------|
| **Deployment time** | ~10 minutes on any small VPS |
| **Infrastructure cost** | €5–10/month on a small cloud instance |
| **Independence** | Completely separate from the client's corporate email/IT infrastructure |
| **No domain dependency** | Does not require integration with the client's existing email domain |
| **Optimised for push** | Purpose-built for Delta Chat's push notification model — messages arrive instantly on mobile |
| **Minimal attack surface** | Not a full mail server; purpose-built, smaller footprint than Postfix + Dovecot |

**Deployment**: One VPS, one domain (e.g., `chat.clientname.cqre.net`), 10 minutes. Users create accounts by scanning a QR code in Delta Chat. No IT involvement required on the user side.

**This is the recommended approach for OT/critical infrastructure clients** and any client where the crisis channel must be independent from corporate infrastructure.

**The conversation**:

> *"We are going to spin up a €7/month server that runs a dedicated chat relay. It has nothing to do with your Active Directory, your Exchange, your Azure, or your corporate network. When your primary infrastructure has a bad day, this server does not care. Your operations team scans a QR code and they are on a channel that is encrypted end-to-end, works on personal phones, and requires no corporate account. We do this today, in this meeting. It takes 10 minutes."*

### Typical Deployment Scope

| Use Case | Delta Chat Configuration |
|----------|------------------------|
| **Crisis/incident response** | Chatmail relay on independent cloud; separate from corporate infra; key responders enrolled |
| **OT operations channel** | Chatmail relay; separate from IT network; control room operators + management enrolled |
| **Board/executive channel** | Chatmail relay; executives enrolled on personal devices; no corporate MDM dependency |
| **Supplier/vendor coordination** | Existing email (Option A); suppliers use their own email addresses; no account setup required |
| **Primary encrypted comms for small teams** | Existing email (Option A); team uses Delta Chat daily for all sensitive communication |

---

## Tier 2: Matrix / Element

### What It Is

Matrix is an open standard for decentralised, federated real-time communication. Element is the primary client application. Synapse and Dendrite are the main server implementations. The combination provides a full-featured, sovereign alternative to Teams or Slack: text, voice, video, file sharing, bridges to other platforms, and automation.

### When Tier 2 Is Warranted

| Client Situation | Matrix/Element Appropriate? |
|-----------------|---------------------------|
| Needs a full Teams/Slack replacement with sovereignty | ✅ Yes |
| Regulated industry requiring data residency for all communications | ✅ Yes |
| OT operator who wants persistent rooms for shift handovers + crisis channel | ✅ Yes |
| Needs bridges to existing platforms (Slack, Teams, Signal, WhatsApp) | ✅ Yes |
| Just needs a crisis fallback channel | ❌ Delta Chat is simpler and faster |
| Just needs encrypted messaging on existing email | ❌ Delta Chat is simpler and faster |

### Matrix/Element Feature Comparison vs Teams/Slack

| Feature | Matrix/Element | Teams / Slack |
|---------|---------------|---------------|
| Persistent rooms | ✅ | ✅ |
| Voice/video calls | ✅ | ✅ |
| File sharing | ✅ | ✅ |
| E2E encryption | ✅ (per room) | Limited/none |
| Self-hosted | ✅ (required for sovereignty) | ❌ |
| Federation with other instances | ✅ | ❌ |
| Bridges (Slack, Teams, Signal) | ✅ (via bridges) | Limited |
| Bot/automation support | ✅ | ✅ |
| Third-party data exposure | None (self-hosted) | Vendor has access |
| Per-user licensing cost | None (self-hosted) | €5–30/user/month |
| Data residency guarantee | Full control | Vendor-dependent |

### CQRE Implementation Options

| Option | Description | Best For |
|--------|-------------|---------|
| **Fully Managed** | CQRE hosts and operates Synapse in our infrastructure; client datacenter region selectable | Clients who want the capability without operating it |
| **On-Premises** | CQRE installs and configures Synapse on client infrastructure; client operates it | Clients with strict data residency requirements |
| **Managed On-Premises** | CQRE installs and manages Synapse on client infrastructure on a support contract | Best of both: sovereign data, no operational burden on client |

**The conversation**:

> *"You are paying €20 per user per month for Slack. That is €240K per year for 1,000 users. Every message your executives send about acquisition targets, regulatory responses, and incident response sits on Slack's infrastructure. We replace that with a self-hosted Matrix instance. Same features. Better encryption. Zero per-user cost after infrastructure. Your messages never leave your building."*

---

## The Dual-Stack Architecture

For most clients, the recommended posture is:

```
PRIMARY CHANNEL: Teams / Slack / email (existing corporate platform)
    ↓ Fails during incident
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
    (independent infrastructure, works on personal devices)

For organisations wanting full sovereignty:
PRIMARY CHANNEL: Matrix/Element (self-hosted)
    ↓ Fails during infrastructure incident  
OUT-OF-BAND CHANNEL: Delta Chat on chatmail relay
    (different infrastructure, different failure mode)
```

**The key insight**: The out-of-band channel must have a **different failure mode** from the primary channel. If both run on the same VPS or depend on the same corporate identity, they will fail together.

---

## OT and Critical Infrastructure

For utilities, telco, and manufacturing clients, sovereign communications is not a convenience — it is an operational requirement.

| Scenario | Recommendation |
|----------|---------------|
| **Ransomware hits corporate IT** | Delta Chat on chatmail relay — independent from corporate domain; operations can continue coordinating |
| **Power outage affects datacenter** | Delta Chat on cloud-hosted chatmail relay — works on mobile over 4G/5G while datacenter is dark |
| **OT incident requires IT/OT team coordination** | Delta Chat channel pre-enrolled with OT engineers, IT responders, management, and external incident response team |
| **Regulator requires documented crisis comms capability** | Matrix/Element with full audit log + Delta Chat as the fallback — both documented in IR runbooks |
| **Vendor coordination during OT maintenance** | Delta Chat on chatmail relay — vendor uses their own email address; no corporate account provisioning required |

**NIS2 relevance**: NIS2 Article 21 requires operators of essential services to have documented crisis communication procedures. A deployed, tested out-of-band channel is evidence; a policy that says "we will use Teams" is not.

---

## Deployment Complexity

| Tool | Time to First Value | Infrastructure | Expertise Required |
|------|--------------------|-----------|--------------------|
| Delta Chat (existing email) | 5 minutes (per user) | None | Very low |
| Delta Chat + chatmail relay | 10–30 minutes total | One small VPS | Low |
| Matrix/Element (managed by CQRE) | 1–2 days | CQRE infrastructure | Low (client side) |
| Matrix/Element (on-premises) | 2–5 days | Client VPS or VM | Medium |

---

## Integration With Existing Frameworks

| Document | Integration |
|----------|-------------|
| [Modular Engagements](../core/modular-engagements.md) | Module 14; natural follow-on to Module 7 (Recovery & Resilience) and Module 8 (OT Security) |
| [Vertical: Power and Utilities](../reference/vertical-power-utilities.md) | OT crisis communications; NIS2 Article 21 crisis procedure evidence |
| [Vertical: Telco](../reference/vertical-telco.md) | Network operations out-of-band channel; incident bridge coordination |
| [Rapid Modernisation Plan](rapid-modernisation-plan.md) | Delta Chat chatmail relay is a Phase 3 (Sovereignty) quick win — 10 minutes of deployment, immediately demonstrable |
| [T0 Asset Framework](../core/t0-asset-framework.md) | Crisis communication channel is a T1 operational asset; Delta Chat relay should have the same protection as other critical services |

---

*For the OT security context, see [Vertical: Power and Utilities](../reference/vertical-power-utilities.md).*
*For recovery and resilience planning, see [Implementation Playbook](implementation-playbook.md).*
*For the full module menu, see [Modular Engagements](../core/modular-engagements.md).*