Secure Communications Under Surveillance
Secure communications under surveillance encompasses the technical controls, platform selection, and operational practices that protect message content and communication patterns from interception by hostile actors. Staff operating in authoritarian contexts, conflict zones, or environments with pervasive state monitoring face threats that extend beyond content interception to include metadata analysis, traffic correlation, and device compromise. The communication security architecture must address all three attack surfaces while remaining usable for staff who are not security specialists.
- End-to-End Encryption
- Cryptographic protection where only communicating parties hold decryption keys. The service provider cannot access message content. Abbreviated E2EE.
- Metadata
- Data describing communication patterns rather than content: who communicated with whom, when, for how long, and from where. Often more valuable to surveillance than content itself.
- Perfect Forward Secrecy
- Cryptographic property ensuring that compromise of long-term keys does not compromise past session keys. Each session generates unique ephemeral keys. Abbreviated PFS.
- Signal Protocol
- Cryptographic protocol providing E2EE with PFS, developed by Open Whisper Systems. Used by Signal, WhatsApp, and others. Considered the gold standard for secure messaging.
- Traffic Analysis
- Intelligence technique deriving information from communication patterns without accessing content. Identifies relationships, schedules, and locations from metadata alone.
- Man-in-the-Middle Attack
- Interception technique where an adversary positions between communicating parties, potentially modifying or recording communications. Abbreviated MITM.
- Disappearing Messages
- Feature automatically deleting messages after a configured time period. Reduces exposure if device is later compromised or confiscated.
Communication Security Threat Model
Adversaries targeting humanitarian staff communications operate across distinct capability tiers. Understanding these tiers determines appropriate countermeasures, as defences against opportunistic interception differ substantially from defences against nation-state surveillance.
The first tier encompasses passive network interception. Adversaries with access to network infrastructure, whether through telecommunications company cooperation, compromised network equipment, or physical wiretaps, can capture unencrypted traffic traversing those networks. Internet service providers in many operating contexts either cooperate with government surveillance programmes or operate under legal frameworks requiring data retention and lawful intercept capabilities. Mobile network operators face similar requirements, with some jurisdictions mandating real-time access to voice calls and SMS messages. Passive interception captures everything transmitted without encryption, including email content over unencrypted connections, SMS messages, voice calls over traditional telephony, and HTTP web traffic.
The second tier involves active network manipulation. Adversaries inject themselves into communication flows, presenting false certificates to intercept encrypted traffic or redirecting connections through monitoring infrastructure. Kazakhstan’s 2019 mandate requiring citizens to install a government root certificate exemplifies this approach, enabling MITM attacks against HTTPS traffic. Active manipulation fails against properly implemented certificate pinning and E2EE applications that verify cryptographic identity independently of the certificate authority system.
+-------------------------------------------------------------------------+| COMMUNICATION THREAT TIERS |+-------------------------------------------------------------------------+| || TIER 1: PASSIVE INTERCEPTION || +-------------------------------------------------------------------+ || | Adversary: ISP, mobile operator, network tap | || | Capability: Capture unencrypted traffic | || | Defeated by: Transport encryption (TLS), E2EE | || +-------------------------------------------------------------------+ || | || v || TIER 2: ACTIVE MANIPULATION || +-------------------------------------------------------------------+ || | Adversary: State with CA control, compromised infrastructure | || | Capability: MITM against standard TLS, traffic injection | || | Defeated by: Certificate pinning, E2EE with identity verification | || +-------------------------------------------------------------------+ || | || v || TIER 3: METADATA ANALYSIS || +-------------------------------------------------------------------+ || | Adversary: Any with network visibility | || | Capability: Traffic correlation, contact mapping, pattern analysis| || | Defeated by: Metadata-protecting protocols, traffic obfuscation | || +-------------------------------------------------------------------+ || | || v || TIER 4: ENDPOINT COMPROMISE || +-------------------------------------------------------------------+ || | Adversary: Nation-state, sophisticated criminal | || | Capability: Device malware, zero-day exploits, physical access | || | Defeated by: Device security, compartmentalisation, air gaps | || +-------------------------------------------------------------------+ || |+-------------------------------------------------------------------------+The third tier targets metadata rather than content. Even when E2EE prevents content access, communication metadata reveals who contacts whom, when, how frequently, and from what locations. A protection officer communicating daily with the same phone number in a refugee camp, followed by communications with UNHCR, creates a pattern identifying protection cases regardless of message content. Metadata analysis at scale maps organisational structures, identifies key individuals, and predicts activities. Protecting against metadata analysis requires protocols specifically designed to obscure communication patterns, not merely encrypt content.
The fourth tier encompasses endpoint compromise. Adversaries with sufficient resources bypass network-layer protections entirely by compromising devices themselves. Commercial spyware like Pegasus, developed by NSO Group, exploits zero-day vulnerabilities to gain complete device access, capturing communications before encryption or after decryption. Nation-state actors maintain similar capabilities. Defending against endpoint compromise requires device security measures covered in Device Security in Hostile Environments and operational security practices covered in Operational Security.
The threat model for a specific operating context determines required controls. Staff in a context with passive interception but no active manipulation capability can rely on standard E2EE applications. Staff facing nation-state adversaries with endpoint compromise capabilities require defence in depth: E2EE, metadata protection, device security, and operational compartmentalisation.
End-to-End Encryption Architecture
End-to-end encryption ensures that cryptographic keys exist only on communicating devices, never on intermediate servers. The service provider transports encrypted messages but cannot decrypt them. This architecture fundamentally differs from transport encryption, where the provider holds keys and can access content.
The Signal Protocol represents the current state of the art for secure messaging cryptography. It combines the Extended Triple Diffie-Hellman (X3DH) key agreement protocol for initial key establishment with the Double Ratchet Algorithm for ongoing message encryption. X3DH establishes a shared secret between parties who may never have communicated before, using a combination of long-term identity keys, signed prekeys, and ephemeral keys. The Double Ratchet then derives new encryption keys for each message, providing perfect forward secrecy at the message level.
+------------------------------------------------------------------------------+| SIGNAL PROTOCOL KEY ESTABLISHMENT |+------------------------------------------------------------------------------+| || ALICE (Initiator) BOB (Recipient) || || +------------------+ +------------------+ || | Identity Key | | Identity Key | || | (IK_A) long-term | | (IK_B) long-term | || +------------------+ +------------------+ || || +------------------+ +------------------+ || | Ephemeral Key | | Signed Prekey | || | (EK_A) one-time | | (SPK_B) rotated | || +------------------+ +------------------+ || || +------------------+ || | One-Time Prekey | || | (OPK_B) single | || +------------------+ || || X3DH computes shared secret from: || DH(IK_A, SPK_B) || DH(EK_A, IK_B) || DH(EK_A, SPK_B) || DH(EK_A, OPK_B) || || | || v || +---------------------+ || | Root Key (32 bytes) | || +----------+----------+ || | || v || +--------------------------------------------------------------------+ || | DOUBLE RATCHET | || | +------------+ +------------+ +------------+ | || | | Chain Key |--->| Chain Key |--->| Chain Key |---> ... | || | | (send) | | (send) | | (send) | | || | +-----+------+ +-----+------+ +-----+------+ | || | | | | | || | v v v | || | +------------+ +------------+ +------------+ | || | | Message Key| | Message Key| | Message Key| | || | | (msg 1) | | (msg 2) | | (msg 3) | | || | +------------+ +------------+ +------------+ | || +--------------------------------------------------------------------+ || |+------------------------------------------------------------------------------+The Double Ratchet maintains separate sending and receiving chain keys. Each message consumes a message key derived from the chain key, then advances the chain. Message keys cannot be reconstructed from later chain states, ensuring that compromise of current keys does not expose past messages. When a reply is received, the ratchet performs a Diffie-Hellman step with new ephemeral keys, establishing fresh chain keys for future messages. This continuous ratcheting limits the damage from key compromise to a small window of messages.
Perfect forward secrecy in the Signal Protocol operates at message granularity rather than session granularity. TLS with forward secrecy generates ephemeral keys per session but uses those keys for all messages within the session. An adversary recording encrypted traffic who later compromises session keys can decrypt the entire session. The Double Ratchet generates unique keys per message, limiting exposure to individual messages even if chain keys are compromised.
Implementations of the Signal Protocol vary in security-relevant details. Signal itself implements the protocol with additional protections including sealed sender, which encrypts sender metadata, and secure value recovery for cloud backup of encryption keys. WhatsApp implements the protocol but with different key backup mechanisms and metadata practices. Wire implements the protocol with modifications for group messaging. When selecting a platform, examine not just the cryptographic protocol but the complete implementation including key management, backup handling, and metadata protection.
Cryptographic verification prevents MITM attacks against E2EE. Each user possesses a public identity key that should remain constant across devices. Users can verify each other’s identity keys through a safety number, a numeric or visual representation of both parties’ keys. If an adversary intercepts communication by substituting their own keys, the safety number changes. Organisations operating in high-risk contexts should establish key verification procedures: staff verify safety numbers with contacts when establishing communication relationships, and re-verify if the application warns of key changes.
Metadata Protection
Content encryption addresses only part of the surveillance threat. An adversary observing encrypted communications between a journalist and a whistleblower learns that those parties are in contact, how frequently they communicate, at what times, and from what locations. This metadata often reveals more than content would.
Traditional E2EE applications protect content but expose metadata to the service provider and network observers. The service provider necessarily knows sender and recipient to route messages. Network observers see connection patterns to the service. In jurisdictions where the service provider cooperates with authorities or where network monitoring is pervasive, metadata collection occurs at scale.
Several architectural approaches reduce metadata exposure. Sealed sender, implemented in Signal, encrypts the sender’s identity so that the server knows only the recipient. The server delivers messages to recipients without logging sender information. Network observers still see connections to Signal’s servers but cannot determine specific communication relationships from network traffic alone.
Onion routing, as implemented in Tor, routes traffic through multiple relays such that no single relay knows both source and destination. The entry relay knows the source but not the destination; the exit relay knows the destination but not the source. Combining E2EE messaging with onion routing reduces metadata exposure to network observers, though timing correlation attacks against Tor remain possible for sophisticated adversaries.
+------------------------------------------------------------------------------+| METADATA EXPOSURE BY ARCHITECTURE |+------------------------------------------------------------------------------+| || 1. STANDARD E2EE (e.g., WhatsApp, iMessage) || +------------------------------------------------------------------------+ || | [ Alice ] ----------> [ Service Provider ] ----------> [ Bob ] | || | | || | PROVIDER KNOWS: Sender identity, Recipient identity, IP addresses, | || | Message timestamps, Frequency, and Payload size. | || | OBSERVER SEES: Alice <-> Provider IP, Bob <-> Provider IP | || +------------------------------------------------------------------------+ || || 2. SEALED SENDER (e.g., Signal) || +------------------------------------------------------------------------+ || | [ Alice ] ---[??]---> [ Service Provider ] ----------> [ Bob ] | || | | || | PROVIDER KNOWS: Recipient identity, IP addresses, Timestamps. | || | HIDDEN FROM PROV: Sender identity (encrypted within the envelope). | || | OBSERVER SEES: Alice <-> Provider IP, Bob <-> Provider IP | || +------------------------------------------------------------------------+ || || 3. ONION ROUTING + E2EE (e.g., Signal over Tor) || +------------------------------------------------------------------------+ || | [ Alice ] -> [Tor Entry] -> [Relay] -> [Exit] -> [Provider] -> [ Bob ] | || | | || | PROVIDER KNOWS: Recipient identity, Message timing/size. | || | HIDDEN FROM PROV: Alice's true IP address (sees Tor Exit node IP). | || | OBSERVER SEES: Alice <-> Tor Entry node (Hidden destination). | || +------------------------------------------------------------------------+ || || 4. PEER-TO-PEER + ONION (e.g., Briar, Cwtch) || +------------------------------------------------------------------------+ || | [ Alice ] <---------[ Anonymous Tor Hidden Service ]---------> [ Bob ] | || | | || | CENTRAL SERVER: None. No central provider to log or subpoena. | || | METADATA: Minimized to timing/size; IP addresses obscured. | || | OBSERVER SEES: Both parties connecting to Tor; no link visible. | || +------------------------------------------------------------------------+ || |+------------------------------------------------------------------------------+Briar implements peer-to-peer messaging without central servers, routing messages through the Tor network to hidden services run by recipients. This architecture eliminates the metadata exposure inherent in centralised services but requires both parties to be online simultaneously unless using asynchronous bridges. Briar suits high-risk contexts where communication relationships must be protected from network observers, though its usability constraints limit deployment to staff with specific operational needs.
Timing and traffic analysis extract information from encrypted communication patterns. Regular communication at specific times suggests scheduled check-ins. Communication volume spikes may correlate with events. Message sizes may reveal content types even when encrypted. Mitigations include constant-rate traffic generation, message padding to uniform sizes, and randomised timing for non-urgent communications. These techniques trade bandwidth and immediacy for reduced metadata exposure.
For most humanitarian operations, the practical metadata protection approach involves selecting platforms with sealed sender capabilities, advising staff that communication patterns reveal relationships even when content is protected, and reserving metadata-protecting architectures like Briar for the highest-risk communication relationships.
Secure Messaging Platform Selection
Platform selection balances security properties against operational requirements. The most secure platform provides no protection if staff cannot or will not use it. Selection criteria include cryptographic strength, metadata protection, verification mechanisms, usability, device support, and jurisdictional considerations.
Signal provides the strongest combination of security properties and usability for general secure messaging. The Signal Protocol provides E2EE with PFS. Sealed sender reduces metadata exposure. Safety numbers enable identity verification. Disappearing messages reduce exposure from device compromise. The application is open source, enabling independent security review. Signal operates under US jurisdiction, which provides some legal protections but also CLOUD Act exposure. The Signal Foundation’s non-profit structure and commitment to user privacy mitigate commercial incentives to weaken security.
Signal requires a phone number for registration, creating an identity linkage that may concern staff in some contexts. This requirement enables social contact discovery but exposes phone numbers to contacts and potentially to Signal’s servers during registration. For staff whose phone numbers should remain unlinkable from their Signal identity, alternatives include registering with a secondary number from a different jurisdiction or using platforms that do not require phone numbers.
Wire provides E2EE messaging without requiring phone numbers, supporting registration with email addresses or usernames. Wire’s implementation of the Signal Protocol differs in group messaging handling. Wire operates under Swiss jurisdiction and offers self-hosted deployment options for organisations requiring data sovereignty. The commercial licensing model creates different incentive structures than Signal’s non-profit approach. Wire suits organisations that require username-based identity or Swiss data residency.
Element (Matrix protocol) implements end-to-end encryption through the Megolm protocol for group messaging and Olm for one-to-one messaging. The Matrix protocol’s federated architecture enables self-hosted deployment with full control over infrastructure and data. Element’s encryption implementation has received security audits though the protocol differs from the Signal Protocol in its approach to key management and group encryption. Organisations with infrastructure capacity and data sovereignty requirements may prefer Element’s self-hosted deployment model.
Briar provides the strongest metadata protection through peer-to-peer architecture and Tor routing. Messages can route through Tor, WiFi, or Bluetooth without central servers. The lack of servers eliminates service-level metadata collection. Briar suits specific high-risk scenarios: journalists communicating with sources, protection staff communicating about sensitive cases, staff operating in contexts with pervasive network monitoring. Usability constraints limit broader deployment; both parties must be online simultaneously for direct communication, and the application prioritises security over feature richness.
WhatsApp implements the Signal Protocol, providing E2EE for message content. However, WhatsApp’s metadata practices differ substantially from Signal’s. Meta collects extensive metadata including contact lists, usage patterns, and group membership. WhatsApp’s cloud backup feature, if enabled, stores message content accessible to Meta. WhatsApp may be appropriate where contact reach matters more than metadata protection, such as communicating with beneficiaries who use WhatsApp universally. Staff should understand that while content is encrypted, communication patterns are not protected.
Telegram’s “secret chats” feature provides E2EE but standard chats are not end-to-end encrypted; Telegram holds keys and can access message content. Telegram’s MTProto protocol has received less independent scrutiny than the Signal Protocol. Telegram may be prevalent in specific operating contexts, requiring staff to use it for external communications, but should not be relied upon for sensitive internal communications.
| Platform | E2EE | Metadata Protection | Registration | Self-Host | Jurisdiction |
|---|---|---|---|---|---|
| Signal | Yes (Signal Protocol) | Sealed sender | Phone number | No | USA |
| Wire | Yes (Signal Protocol variant) | Standard | Email/username | Yes | Switzerland |
| Element | Yes (Megolm/Olm) | Federated option | Email/username | Yes | UK (company) |
| Briar | Yes (custom) | Tor/P2P | None required | P2P only | N/A |
| Yes (Signal Protocol) | Extensive collection | Phone number | No | USA (Meta) | |
| Telegram | Secret chats only | Standard | Phone number | No | UAE (registered) |
Voice and Video Communication Security
Voice and video communications present distinct security challenges from text messaging. Real-time constraints limit cryptographic options. Voice and video codecs produce predictable patterns that may leak information even when encrypted. Bandwidth requirements strain field connectivity.
Signal supports encrypted voice and video calls using the SRTP protocol with keys established through the Signal Protocol. Call metadata, including call timing and duration, remains visible to Signal’s servers for call setup, though sealed sender reduces some metadata exposure. Signal’s voice quality adapts to bandwidth, remaining usable on connections as low as 100 kbps, though quality degrades substantially below 256 kbps.
Wire provides encrypted calling with similar properties to Signal. Wire’s calling infrastructure supports larger group calls than Signal, relevant for team meetings. Wire’s self-hosted option places call signalling and TURN servers under organisational control, eliminating external metadata exposure for organisations with infrastructure capacity.
Jitsi Meet provides open-source video conferencing with optional E2EE. Standard Jitsi deployments use server-side mixing without E2EE; enabling E2EE requires specific configuration and limits some features. Self-hosted Jitsi instances eliminate external metadata collection but require infrastructure expertise. Jitsi suits organisations needing video conferencing for larger groups where commercial platforms present unacceptable jurisdiction or privacy concerns.
+---------------------------------------------------------------------+| ENCRYPTED CALL ARCHITECTURE |+---------------------------------------------------------------------+| || PEER-TO-PEER (Signal/Wire direct) || || +--------+ +--------+ || | Device |<========= SRTP (E2EE) ============>| Device | || | Alice | | Bob | || +--------+ +--------+ || | | || +------> Signaling Server <-------------------+ || (call setup only, || no media access) || || RELAYED (Signal/Wire via TURN) || || +--------+ +-------------+ +--------+ || | Device |<=====>| TURN Relay |<=====>| Device | || | Alice | SRTP | (encrypted | SRTP | Bob | || +--------+ | E2E, relay | +--------+ || | sees only | || | ciphertext)| || +-------------+ || || GROUP CALL (Jitsi with E2EE) || || +--------+ || | Alice |<-----+ || +--------+ | +------------+ || +----->| | || +--------+ +----->| Jitsi SFU | || | Bob |<-----+ | (forwards | || +--------+ | | encrypted | || | | streams, | || +--------+ | | no decode)| || | Carol |<-----+ +------------+ || +--------+ || |+---------------------------------------------------------------------+Commercial platforms including Microsoft Teams and Zoom provide encryption but with significant caveats for high-risk contexts. Neither platform offers E2EE by default for standard meetings; the provider can access call content. Both platforms operate under US jurisdiction with associated CLOUD Act implications. Both platforms collect substantial metadata. These platforms may be necessary for coordination with external parties who use them, but should not carry sensitive internal communications in high-risk contexts.
Voice communication over mobile networks, including standard phone calls and voice over LTE (VoLTE), lacks end-to-end encryption. Mobile operators and entities with access to their infrastructure can intercept voice calls. IMSI catchers (cell site simulators) operated by local authorities can intercept mobile communications including voice calls. Staff in high-risk contexts should conduct sensitive voice communications exclusively over encrypted platforms, treating mobile voice calls as equivalent to unencrypted communication.
Operational Communication Patterns
Technical controls provide a foundation, but operational practices determine actual security outcomes. Staff must understand which communications require protection, apply appropriate tools, and maintain practices that preserve security properties.
Communication classification establishes which channels suit which communication types. Organisations operating in high-risk contexts should define explicit categories: routine operational communications, sensitive programme communications, protection-related communications, and high-sensitivity communications such as security incidents or advocacy activities that could attract hostile attention. Each category maps to appropriate tools and practices.
Routine operational communications, including scheduling, logistics, and general coordination, may traverse standard organisational channels including email and standard messaging. Protection requirements match general organisational standards rather than high-risk context adaptations.
Sensitive programme communications, including beneficiary information, partner relationships, and programme details that could enable interference, require E2EE messaging platforms. Staff should use Signal or equivalent for such communications rather than email or SMS. Group chats for programme teams should operate on E2EE platforms.
Protection-related communications demand the highest security standards. Communications identifying protection cases, survivors, or vulnerable individuals should occur only on E2EE platforms with disappearing messages enabled. Such communications should not reference identifiable information in message previews, notifications, or group names visible on lock screens.
High-sensitivity communications, including security incidents, advocacy activities, or communications that could specifically attract hostile attention, may require metadata protection beyond standard E2EE. Staff should discuss such matters on platforms with sealed sender capabilities, avoid communication patterns that reveal relationships or schedules, and consider Briar or similar for the most sensitive communications.
Contact verification establishes authentic communication relationships. When establishing contact with a new party on an E2EE platform, staff should verify the contact’s identity key through an independent channel. In practice, this means comparing safety numbers (Signal) or key fingerprints (other platforms) through a voice call, in-person meeting, or a separate verified channel. Verification prevents MITM attacks where an adversary interposes between parties with their own keys.
+------------------------------------------------------------------------+| COMMUNICATION CLASSIFICATION EXAMPLE |+------------------------------------------------------------------------+| || +------------------------------------------------------------------+ || | ROUTINE OPERATIONAL | || | - Staff scheduling and leave | || | - Office logistics | || | - Public-facing coordination | || | | || | Channels: Organisational email, standard platforms | || | Controls: Transport encryption, standard authentication | || +------------------------------------------------------------------+ || | || v || +------------------------------------------------------------------+ || | SENSITIVE PROGRAMME | || | - Beneficiary coordination (non-identifying) | || | - Partner communications | || | - Programme planning | || | | || | Channels: Signal, Wire, Element | || | Controls: E2EE, verified contacts | || +------------------------------------------------------------------+ || | || v || +------------------------------------------------------------------+ || | PROTECTION-RELATED | || | - Case discussions | || | - Survivor communications | || | - Referral coordination | || | | || | Channels: Signal with disappearing messages | || | Controls: E2EE, disappearing messages, no identifying info in | || | previews, verified contacts | || +------------------------------------------------------------------+ || | || v || +------------------------------------------------------------------+ || | HIGH-SENSITIVITY | || | - Security incidents | || | - Advocacy activities | || | - Communications likely to attract hostile attention | || | | || | Channels: Signal (sealed sender), Briar for highest risk | || | Controls: E2EE, metadata protection, compartmentalised contacts, | || | randomised timing | || +------------------------------------------------------------------+ || |+------------------------------------------------------------------------+Disappearing message configuration should match communication sensitivity. Signal supports message timers from 30 seconds to 4 weeks. Protection-related communications should default to short timers, 24 hours representing a reasonable balance between operational needs and exposure reduction. Staff should understand that disappearing messages delete only from visible history; forensic recovery may be possible from device storage, and messages may persist on recipients’ devices if they have taken screenshots or disabled the feature.
Group chat security requires attention to membership management. Adding a participant to an E2EE group chat does not expose past messages, but any current participant can add others. Sensitive groups should maintain explicit membership policies, remove departed staff promptly, and create new groups rather than repurposing existing ones when sensitivity levels change.
Device notification settings affect communication security. Message previews displayed on lock screens expose content to physical observers. Staff should configure secure messaging applications to hide message content in notifications, displaying only “New message” rather than sender and content. This configuration prevents casual observation but reduces usability; staff must unlock devices to read messages.
Connectivity Constraints
Field operations frequently encounter bandwidth limitations, intermittent connectivity, and network restrictions that affect secure communication. The communication architecture must accommodate these constraints without forcing staff to fall back on insecure alternatives.
Low-bandwidth environments require communication tools that function on constrained connections. Signal’s voice calls adapt to bandwidth as low as 100 kbps, though quality degrades substantially. Text messaging consumes minimal bandwidth: a Signal message with 1,000 characters consumes approximately 2-3 KB including protocol overhead. Image sharing consumes more bandwidth but Signal compresses images by default. Staff in low-bandwidth contexts should prefer text over voice, disable automatic media download, and send images at reduced resolution.
Intermittent connectivity requires store-and-forward capability. Signal and similar applications queue messages when offline and transmit when connectivity returns. Messages sent while both parties are offline will deliver when both regain connectivity and the message traverses the server. This model differs from peer-to-peer systems like Briar, which require synchronous connectivity unless using bridging mechanisms.
Network restrictions in some jurisdictions block access to secure communication services. Blocking may target DNS resolution, IP addresses, or deep packet inspection identifying application protocols. Circumvention approaches include VPN services that tunnel traffic through unrestricted servers, Tor which routes traffic through multiple relays, and domain fronting where available. Signal supports censorship circumvention features that route traffic through CDN infrastructure difficult to block without broader impact. Staff in restrictive contexts should have circumvention tools configured before entering those contexts.
Satellite connectivity, common in remote field locations, introduces latency that affects real-time communications. Geostationary satellite links add 500-600ms round-trip latency, making voice conversation difficult and video calling impractical. Low-earth orbit constellations like Starlink reduce latency to 20-40ms, enabling voice and video. Text messaging functions normally regardless of latency. Staff relying on satellite connectivity should prefer text communication for sensitive matters rather than struggling with degraded voice quality.
Implementation Considerations
Deploying secure communications across an organisation requires balancing security requirements against operational realities. The implementation approach differs by organisational capacity and risk profile.
Organisations with minimal IT function operating in high-risk contexts should focus on deploying Signal across all staff. Signal provides strong security with minimal administration overhead. Implementation involves installing Signal on staff devices, establishing a verification culture where staff verify safety numbers with key contacts, configuring appropriate disappearing message defaults, and training staff on appropriate use for different communication types. This approach addresses the highest-impact threats without requiring infrastructure or ongoing security administration.
Organisations with established IT function can implement tiered communication architecture. Standard operations use organisational platforms with appropriate security. Sensitive communications use mandated E2EE platforms with enforced configurations. The highest-risk communications use metadata-protecting tools for staff with specific operational needs. Implementation includes defining communication classification policies, deploying and configuring multiple platforms, establishing verification procedures, and maintaining training programmes.
Organisations requiring data sovereignty or operating under specific regulatory constraints should evaluate self-hosted options. Element with a self-hosted Matrix server provides E2EE messaging under full organisational control. Wire offers self-hosted deployment. Jitsi provides self-hosted video conferencing. Self-hosting requires infrastructure expertise, ongoing maintenance capacity, and security competence to configure and harden deployments. The operational burden suits organisations with dedicated IT staff rather than those with minimal IT function.
Staff training determines whether technical controls provide actual protection. Training should cover threat model concepts appropriate to the operating context, platform selection for different communication types, contact verification procedures, disappearing message configuration, notification security settings, and recognition of social engineering attacks targeting secure communication. Training should use realistic scenarios relevant to staff roles rather than abstract security concepts.
Periodic verification ensures controls remain effective. Verify that staff are using appropriate platforms for sensitive communications rather than falling back to email or SMS. Verify that disappearing messages are configured appropriately. Verify that new staff complete verification procedures with key contacts. Conduct tabletop exercises simulating communication security incidents, such as a device confiscation scenario, to validate staff understanding and response.