On this page

Secure Field Communications

Secure field communications protect sensitive conversations from interception in contexts where adversaries monitor network traffic, compromise telecommunications infrastructure, or conduct targeted surveillance. This task establishes encrypted messaging, voice, and data channels for field staff operating in environments where standard organisational communications would expose operational details, staff locations, or beneficiary information to hostile actors.

Complete this task before deploying staff to high-risk contexts, when threat assessments indicate communications surveillance, or when existing channels have been compromised. The outcome is a functioning secure communications capability with trained staff, verified encryption, and tested fallback procedures.

Prerequisites

Requirement	Specification
Threat assessment	Completed assessment identifying surveillance actors, capabilities, and likely interception methods
Security classification	Communications classified by sensitivity level requiring protection
Device availability	Devices meeting security requirements (see device specifications below)
Network access	Internet connectivity for initial setup; procedures for offline key exchange if unavailable
Administrative access	MDM administrator role or device ownership for configuration
Staff availability	Minimum 2 hours per user for training and verification
Budget	Approximately £50-200 per user for hardware tokens and premium service tiers where required

Verify the threat assessment has identified specific adversary capabilities:

Threat Assessment Checklist for Communications Planning
-------------------------------------------------------
[ ] Network-level interception capability identified (ISP, state actor)
[ ] Device-level compromise risk assessed (malware, physical access)
[ ] Metadata collection capability identified (who contacts whom, when)
[ ] Location tracking via communications assessed
[ ] Legal compulsion risk evaluated (lawful interception orders)
[ ] Social engineering / insider threat considered

Confirm devices meet minimum security requirements before proceeding:

Platform	Minimum version	Required configuration
Android	10.0	Full-disk encryption enabled, Google Play Protect active
iOS	14.0	Passcode enabled (6+ digits), Find My disabled for high-risk contexts
Windows	10 21H2	BitLocker enabled, TPM 2.0 present
macOS	11.0	FileVault enabled, firmware password set
Linux	Kernel 5.4+	LUKS full-disk encryption, Secure Boot where supported

Device integrity

Secure communications on a compromised device provide no protection. Complete device hardening per the Field Security Hardening checklist before establishing secure channels.

Procedure

Phase 1: Platform selection and architecture

Map communication requirements to security properties needed for each channel. Different operational needs require different protection levels:

Communication type	Confidentiality	Integrity	Metadata protection	Deniability
Beneficiary case discussions	Critical	Critical	Critical	Required
Staff check-ins	High	High	High	Preferred
Logistics coordination	Medium	High	Medium	Not required
Public information sharing	Low	Medium	Low	Not required

For each communication type, record the required security properties and the staff roles involved. This mapping determines which platforms and configurations apply to which conversations.

Select platforms based on security requirements. The selection considers encryption strength, metadata protection, jurisdiction, and operational constraints:

   +------------------------------------------------------------------+
   |                    PLATFORM SELECTION MATRIX                     |
   +------------------------------------------------------------------+
   |                                                                  |
   |  HIGHEST SECURITY (beneficiary data, sensitive operations)       |
   |  +------------------------------------------------------------+  |
   |  | Signal (self-destructing messages enabled)                 |  |
   |  | - E2E encryption: Signal Protocol                          |  |
   |  | - Metadata: Minimal (sealed sender)                        |  |
   |  | - Jurisdiction: US (Signal Foundation)                     |  |
   |  | - Requires: Phone number (can use secondary)               |  |
   |  +------------------------------------------------------------+  |
   |                                                                  |
   |  HIGH SECURITY (internal sensitive, partner coordination)        |
   |  +------------------------------------------------------------+  |
   |  | Wire (team accounts)                                       |  |
   |  | - E2E encryption: Proteus (MLS migration ongoing)          |  |
   |  | - Metadata: Some server-side                               |  |
   |  | - Jurisdiction: Switzerland (Wire Swiss GmbH)              |  |
   |  | - Requires: Email only (no phone number)                   |  |
   |  +------------------------------------------------------------+  |
   |  | Element/Matrix (self-hosted)                               |  |
   |  | - E2E encryption: Olm/Megolm                               |  |
   |  | - Metadata: Controlled (self-hosted)                       |  |
   |  | - Jurisdiction: Your hosting location                      |  |
   |  | - Requires: Infrastructure, maintenance capacity           |  |
   |  +------------------------------------------------------------+  |
   |                                                                  |
   |  STANDARD SECURITY (general operations, non-sensitive)           |
   |  +------------------------------------------------------------+  |
   |  | Organisational collaboration platform with E2E where       |  |
   |  | available (Microsoft Teams E2E calls, etc.)                |  |
   |  +------------------------------------------------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 1: Platform selection by security requirement tier

Record the selected platform for each communication type:

   Communication Channel Assignment
   --------------------------------
   Beneficiary case discussions:  Signal (disappearing messages 1 week)
   Staff emergency check-ins:     Signal (disappearing messages 24 hours)
   Partner coordination:          Wire (team workspace)
   Logistics:                     Organisational Teams
   Public coordination:           WhatsApp (if required for external contacts)

Design the secure communications architecture showing how platforms integrate with existing infrastructure:

   +--------------------------------------------------------------------+
   |                 FIELD SECURE COMMUNICATIONS ARCHITECTURE           |
   +--------------------------------------------------------------------+
   |                                                                    |
   |  FIELD STAFF DEVICES                                               |
   |  +------------------+  +------------------+  +------------------+  |
   |  | Mobile (primary) |  | Laptop           |  | Backup device    |  |
   |  | - Signal         |  | - Signal Desktop |  | - Signal         |  |
   |  | - Wire           |  | - Wire           |  | - Satellite SMS  |  |
   |  | - Org apps       |  | - Element        |  |   (emergency)    |  |
   |  +--------+---------+  +--------+---------+  +--------+---------+  |
   |           |                     |                     |            |
   |           +----------+----------+----------+----------+            |
   |                      |                     |                       |
   |                      v                     v                       |
   |           +----------+----------+  +-------+--------+              |
   |           | Internet (encrypted |  | Satellite      |              |
   |           | tunnel if needed)   |  | (fallback)     |              |
   |           +----------+----------+  +-------+--------+              |
   |                      |                     |                       |
   +--------------------------------------------------------------------+
   |                      |                     |                       |
   |  TRANSIT LAYER       v                     v                       |
   |           +---------------------------------------------+          |
   |           |  Signal/Wire/Matrix servers                 |          |
   |           |  (no access to message content)             |          |
   |           +---------------------------------------------+          |
   |                                                                    |
   +--------------------------------------------------------------------+
   |                                                                    |
   |  HQ / COORDINATION                                                 |
   |  +-------------------+  +-----------------+  +------------------+  |
   |  | Security focal    |  | Programme team  |  | Leadership       |  |
   |  | - All platforms   |  | - Signal        |  | - Signal         |  |
   |  | - Key verification|  | - Wire          |  | - Wire           |  |
   |  | - Incident resp   |  | - Org apps      |  |                  |  |
   |  +-------------------+  +-----------------+  +------------------+  |
   |                                                                    |
   +--------------------------------------------------------------------+

Figure 2: Secure communications architecture showing platform distribution

Document the architecture decisions and rationale. Create a communications security plan that records:
- Selected platforms and their purposes
- Staff roles and their platform assignments
- Key management responsibilities
- Fallback procedures when primary channels fail
- Review schedule (quarterly minimum for high-risk contexts)

Phase 2: Platform deployment

Install Signal on primary mobile devices. Signal provides the strongest combination of encryption and metadata protection for mobile communications:
On Android:

   1. Install from Google Play Store (verify publisher: Signal Foundation)
   2. Open Signal and grant required permissions:
      - Contacts (optional - can skip for maximum privacy)
      - Phone (for registration)
      - Storage (for media)
   3. Register with phone number
      - For high-risk: use secondary SIM or data-only SIM with SMS verification via another device
   4. Set PIN (minimum 6 digits, recommend 8+)
      - Enable Registration Lock in Settings > Account
   5. Complete device transfer if migrating from another device

On iOS:

   1. Install from App Store (verify publisher: Signal Messenger, LLC)
   2. Open Signal and grant permissions when prompted
   3. Register with phone number
   4. Set PIN and enable Registration Lock
   5. Enable Face ID/Touch ID for app lock:
      Settings > Privacy > Screen Lock

Verify Signal installation by checking the app version:

   Settings > Help > Version
   Minimum acceptable: 6.0 (Android), 6.0 (iOS)

Configure Signal security settings for field use:

   Signal Security Configuration
   -----------------------------
   Settings > Privacy:
     [ ] Screen Lock: ENABLED (biometric or PIN)
     [ ] Screen Lock Timeout: 1 minute
     [ ] Screen Security: ENABLED (prevents screenshots)
     [ ] Incognito Keyboard: ENABLED (prevents keyboard learning)
     [ ] Always Relay Calls: ENABLED (hides IP in calls) *
     [ ] Sealed Sender: Allow from anyone: DISABLED

   Settings > Privacy > Disappearing Messages:
     Default timer: 1 week (adjust per conversation as needed)

   Settings > Chats:
     [ ] Generate Link Previews: DISABLED

   Settings > Notifications:
     [ ] Show: Name and Message: DISABLED
     [ ] Show: Name Only: As appropriate for context
     [ ] Show: No Name or Message: For highest security

   * Always Relay Calls routes through Signal servers, adding ~200ms
     latency but preventing IP address exposure to call recipients

Install Signal Desktop for laptop/workstation use where staff need to communicate from computers:
On Windows:

   # Download from signal.org/download (verify HTTPS, check certificate)
   # Or via winget:
   winget install -e --id Signal.Signal

On macOS:

   # Download from signal.org/download
   # Or via Homebrew:
   brew install --cask signal

On Linux:

   # For Debian/Ubuntu (official repository):
   wget -O- https://updates.signal.org/desktop/apt/keys.asc | \
     gpg --dearmor > signal-desktop-keyring.gpg
   sudo mv signal-desktop-keyring.gpg /usr/share/keyrings/
   echo 'deb [arch=amd64 signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] https://updates.signal.org/desktop/apt xenial main' | \
     sudo tee /etc/apt/sources.list.d/signal-xenial.list
   sudo apt update && sudo apt install signal-desktop

Link Signal Desktop to mobile device:

   1. Open Signal Desktop
   2. QR code displayed
   3. On mobile: Settings > Linked Devices > Link New Device
   4. Scan QR code
   5. Approve on mobile device

Deploy Wire for team communications where email-only registration is preferred or phone number exposure is unacceptable:

   Wire Deployment Steps
   ---------------------
   1. Create Wire team account at wire.com/create-team
      - Use organisational email domain
      - Record admin credentials in password manager

   2. Configure team settings:
      Team Settings > Security:
        [ ] Enforce SSO: Enable if IdP integration available
        [ ] Guest access: DISABLED
        [ ] External communications: Per policy

   3. Invite team members via email
      - Each member creates account linked to team
      - No phone number required

   4. Install clients:
      - Mobile: App stores (Wire Swiss GmbH)
      - Desktop: wire.com/download
      - Web: app.wire.com (for temporary access only)

Configure Wire security settings on each device:

   Settings > Privacy:
     [ ] Read receipts: Per user preference
     [ ] Share analytics: DISABLED

   Settings > Account > Devices:
     [ ] Review and remove unrecognised devices

For self-hosted requirements, deploy Element (Matrix client) with organisational Synapse server. This provides complete metadata control but requires infrastructure:
Self-hosting decision
Self-hosted Matrix requires ongoing maintenance (security updates, backups, monitoring). Only proceed if the organisation has dedicated infrastructure capacity. For most field operations, Signal or Wire provides adequate security without operational overhead.
If proceeding with Element:

   # Server deployment (Synapse) - abbreviated
   # Client installation
   # Desktop: element.io/download
   # Mobile: App stores (Element - Secure Messenger)

   # Create account on organisational homeserver
   # Enable cross-signing for device verification

Phase 3: End-to-end encryption verification

Verify Signal encryption by checking safety numbers between all field staff who will communicate sensitive information. Safety numbers confirm that encryption keys belong to the expected person:

   Safety Number Verification Process
   -----------------------------------
   1. Open conversation with contact
   2. Tap contact name/header
   3. Select "View Safety Number"
   4. Compare the 60-digit number OR scan QR code

   Comparison methods (in order of security):
   - In person: Scan QR code from each other's screens
   - Video call: Read numbers aloud, comparing visually
   - Voice call: Read numbers aloud (less secure - voice can be spoofed)
   - Never: Compare via text/email (defeats the purpose)

   After verification:
   - Tap "Mark as Verified"
   - If safety number changes later, Signal will warn you

Create a verification log:

   Safety Number Verification Log
   ------------------------------
   Date       | Verifier    | Contact     | Method     | Status
   -----------+-------------+-------------+------------+--------
   2024-01-15 | J. Smith    | M. Johnson  | In person  | Verified
   2024-01-15 | J. Smith    | R. Okonkwo  | Video call | Verified
   2024-01-16 | M. Johnson  | R. Okonkwo  | In person  | Verified

Verify Wire device fingerprints for team members. Wire uses device-specific keys that should be verified before sensitive communications:

   Wire Device Verification
   ------------------------
   1. Open conversation
   2. Tap contact name > Devices
   3. Each device shows a fingerprint
   4. Compare fingerprint via secure channel (in person or verified Signal)
   5. Tap to mark as verified

   All devices should be verified for high-security communications
   Unverified devices show warning indicator

For Element/Matrix, complete cross-signing setup and device verification:

   Element Cross-Signing Setup
   ---------------------------
   1. Settings > Security & Privacy > Cross-signing
   2. Set up cross-signing (creates master key)
   3. Secure backup: Save recovery key in password manager
   4. Verify other own devices:
      - New device login triggers verification request
      - Compare emoji pattern or scan QR code between devices
   5. Verify other users:
      - User profile > Verify
      - Compare emoji pattern in person or via verified channel

Document encryption verification status for all field staff:

   Field Team Encryption Verification Matrix
   -----------------------------------------
                    | J.Smith | M.Johnson | R.Okonkwo | A.Chen
   -----------------+---------+-----------+-----------+--------
   J.Smith          |    -    |    ✓      |    ✓      |   ✓
   M.Johnson        |    ✓    |    -      |    ✓      |   ✓
   R.Okonkwo        |    ✓    |    ✓      |    -      |   ✓
   A.Chen           |    ✓    |    ✓      |    ✓      |   -

   ✓ = Mutually verified via in-person or video
   ○ = Verified via voice only (re-verify when possible)
   ✗ = Not yet verified

Phase 4: Metadata protection configuration

Configure metadata protection measures beyond message encryption. Metadata comprises information about communications other than the content: who communicated, when, how often, from where, and for how long. Encrypted messages with exposed metadata still reveal patterns.

   +---------------------------------------------------------------------+
   |                       METADATA EXPOSURE POINTS                      |
   +---------------------------------------------------------------------+
   |                                                                     |
   |  Content     +---------+   Encrypted by E2E    +---------+          |
   |  (protected) | Sender  |---------------------->|Receiver |          |
   |              +----+----+                       +----+----+          |
   |                   |                                |                |
   |                   |         METADATA EXPOSURE      |                |
   |                   v              POINTS            v                |
   |   +---------------+--------------------------------+-------------+  |
   |   |                                                              |  |
   |   | - Phone number (registration)                                |  |
   |   | - IP address (network connection)                            |  |
   |   | - Timing (when messages sent)                                |  |
   |   | - Frequency (how often)                                      |  |
   |   | - Contact graph (who talks to whom)                          |  |
   |   | - Location (if location services enabled)                    |  |
   |   | - Device identifiers                                         |  |
   |   |                                                              |  |
   |   +--------------------------------------------------------------+  |
   +---------------------------------------------------------------------+

Figure 3: Metadata exposure points in encrypted communications

Minimise phone number exposure. Phone numbers create persistent identifiers linkable to identity:
For Signal registration without exposing primary number:

   Option 1: Secondary SIM
   - Obtain prepaid SIM from vendor without ID requirements
   - Use only for Signal registration
   - SIM can be removed after registration if PIN/Registration Lock enabled

   Option 2: Data-only SIM with SMS verification elsewhere
   - Signal can send verification to different number
   - Register using burner number or trusted colleague's number
   - Primary device uses data-only connectivity

   Option 3: Organisational number pool
   - IT maintains pool of SIM numbers for high-risk deployments
   - Staff assigned number for registration only
   - Number recycled with appropriate delays after departure

Configure VPN or Tor for IP address protection where network monitoring is a concern:

   Network Protection Options
   --------------------------

   VPN (recommended for most field use):
   - Organisational VPN if available
   - Reputable commercial VPN (ProtonVPN, Mullvad)
   - Configure before launching secure messaging apps
   - Verify VPN connection: check IP at whatismyip.com

   Tor (for highest anonymity requirements):
   - Install Orbot (Android) or Onion Browser (iOS)
   - Enable "VPN Mode" in Orbot to route all traffic
   - Signal works over Tor but with significant latency
   - Not practical for voice calls

   Configuration check:
   $ curl -s https://check.torproject.org/api/ip
   {"IsTor":true,"IP":"185.220.xxx.xxx"}

Disable location services for secure communication applications:
Android:

   Settings > Apps > Signal > Permissions > Location: DENY
   Settings > Apps > Wire > Permissions > Location: DENY

iOS:

   Settings > Privacy > Location Services > Signal: Never
   Settings > Privacy > Location Services > Wire: Never

Configure disappearing messages to limit the window during which messages exist on devices:

Context	Recommended timer
Beneficiary case discussions	24 hours
Operational security communications	24 hours
Staff check-ins	1 week
General coordination	1 week to 4 weeks
Documentation requiring retention	Disabled (export before deletion)

Set default timers:

   Signal: Settings > Privacy > Disappearing Messages > Default Timer
   Wire: Conversation settings > Timed Messages (per conversation)

Phase 5: Voice encryption configuration

Configure Signal voice calls for encrypted audio communication:

   Signal Voice Call Configuration
   -------------------------------
   Settings > Privacy:
     [✓] Always Relay Calls
         - Routes calls through Signal servers
         - Adds ~200ms latency
         - Prevents IP address exposure to call recipient
         - Critical for calls with contacts outside organisation

   Settings > Data and Storage > Use Less Data:
     - Enable on metered connections
     - Reduces bandwidth from ~40kbps to ~20kbps
     - Some quality reduction

Test voice call encryption:

   1. Initiate call with verified contact
   2. During call, tap screen to show call info
   3. Both parties see matching two-word security phrase
   4. Read phrase aloud to verify (if not already verified via safety numbers)

Configure Wire for encrypted group calls where multiple participants need secure voice:

   Wire supports up to 12 participants in E2E encrypted calls

   Wire Call Settings:
   Settings > Audio/Video:
     [ ] Hardware acceleration: Enable if available
     [ ] Noise suppression: Enable
     [ ] Audio-only calls: Consider for low bandwidth

   Group call security:
   - All participants must be team members
   - External guests break E2E encryption
   - Verify all participants before discussing sensitive information

For satellite phone backup, understand encryption limitations:
Satellite phone encryption
Standard satellite phones (Thuraya, Iridium consumer handsets) do not provide end-to-end encryption. Satellite operators and state actors with appropriate equipment can intercept calls. Use satellite phones only for emergency coordination, not sensitive content. Assume all satellite voice calls are monitored.
Operational guidance for satellite voice:

   - Use pre-arranged code words for sensitive topics
   - Keep calls brief, factual, non-attributable
   - Never discuss beneficiary identifying information
   - Never discuss staff locations if security concern
   - Consider satellite phones as "check-in only" in high-risk contexts

Phase 6: Key management for field use

Establish key verification procedures that work in field conditions:

   +------------------------------------------------------------------+
   |                     KEY MANAGEMENT FLOW                          |
   +------------------------------------------------------------------+
   |                                                                  |
   |  INITIAL DEPLOYMENT                                              |
   |  +------------------------------------------------------------+  |
   |  | 1. Staff receives device with apps pre-installed           |  |
   |  | 2. In-person key verification with IT/Security focal       |  |
   |  | 3. Verification status recorded in secure register         |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  FIELD OPERATIONS                                                |
   |  +------------------------------------------------------------+  |
   |  | 4. Verify keys with new contacts via video before          |  |
   |  |    sensitive communications                                |  |
   |  | 5. Report any key change warnings immediately              |  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  KEY CHANGE EVENTS                                               |
   |  +------------------------------------------------------------+  |
   |  | 6. Device replacement: Re-verify all contacts              |  |
   |  | 7. App reinstallation: Re-verify all contacts              |  |
   |  | 8. Security number change warning: Verify before continuing|  |
   |  +------------------------------------------------------------+  |
   |                              |                                   |
   |                              v                                   |
   |  SUSPECTED COMPROMISE                                            |
   |  +------------------------------------------------------------+  |
   |  | 9. Stop using affected device/account                      |  |
   |  | 10. Report to security focal                               |  |
   |  | 11. New device, new account, new verification              |  |
   |  +------------------------------------------------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 4: Key management lifecycle for field operations

Create a key verification register accessible to the security focal point but protected from unauthorised access:

   Key Verification Register Template
   -----------------------------------
   Staff member: _________________
   Device ID: ___________________
   Platform: Signal / Wire / Element

   Verified contacts:
   +-------------+------------+------------+-------------+
   | Contact     | Date       | Method     | Verified by |
   +-------------+------------+------------+-------------+
   |             |            |            |             |
   +-------------+------------+------------+-------------+

   Key change log:
   +------------+-------------+-------------+-------------+
   | Date       | Event       | Resolution  | Verified by |
   +------------+-------------+-------------+-------------+
   |            |             |             |             |
   +------------+-------------+-------------+-------------+

   Store this register encrypted, access restricted to security focal

Establish procedures for handling safety number change warnings:

   Safety Number Change Response
   -----------------------------

   STOP: Do not send sensitive information

   1. Note which contact's safety number changed
   2. Contact them via alternative verified channel:
      - Different verified platform
      - Phone call to known number
      - In person if possible
   3. Ask: "Did you reinstall Signal / get a new device?"

   LEGITIMATE CHANGE (device replacement, reinstallation):
   - Re-verify safety number via secure method
   - Update verification register
   - Resume communications

   UNEXPLAINED CHANGE:
   - Do not resume communications
   - Report to security focal immediately
   - Security focal investigates:
     * Contact the person via out-of-band method
     * Confirm device status
     * If compromise suspected: incident response procedures

Configure backup and recovery for encryption keys:
Signal PIN and Registration Lock:

   The Signal PIN protects your account and enables recovery.

   Settings > Account > Signal PIN:
   - Create strong PIN (8+ characters recommended)
   - PIN can include letters if "Alphanumeric PIN" enabled
   - Write down PIN, store in sealed envelope with other emergency credentials
   - Enable Registration Lock to prevent account takeover

   Recovery: If you forget PIN, account is locked for 7 days before PIN can be reset.
   This prevents attackers from taking over your account by resetting PIN.

Element recovery key:

   Settings > Security & Privacy > Secure Backup

   1. Set up Secure Backup
   2. Save recovery key to password manager
   3. Optionally save to paper, store securely
   4. Recovery key format: EsTj sRAS YLkH pXPp... (groups of 4 letters)
   5. Test recovery before field deployment

Phase 7: Staff training

Conduct secure communications training covering platform operation, security practices, and incident response:

   Secure Communications Training Agenda (2 hours)
   -----------------------------------------------

   Module 1: Threat Context (20 minutes)
   - Why secure communications matter in this context
   - What adversaries can see without protection
   - What remains visible even with encryption (metadata)

   Module 2: Platform Operation (40 minutes)
   - App installation verification
   - Account setup and recovery
   - Basic messaging and calling
   - Voice call security verification
   - Disappearing messages
   - Hands-on practice with each platform

   Module 3: Security Practices (30 minutes)
   - Key verification procedures
   - When to use which platform
   - What not to discuss on which channels
   - Device security relationship to comms security

   Module 4: Incident Response (20 minutes)
   - Recognising compromise indicators
   - Reporting procedures
   - What to do if device lost/seized

   Module 5: Practical Assessment (10 minutes)
   - Verify safety numbers with trainer
   - Send disappearing message
   - Initiate encrypted call

Provide reference materials for field use:

   Secure Communications Quick Reference Card
   ------------------------------------------

   BEFORE SENDING SENSITIVE INFO:
   [ ] Am I using the right platform for this sensitivity?
   [ ] Is my contact's identity verified (safety number)?
   [ ] Are disappearing messages enabled?
   [ ] Is my device secured (locked, encrypted)?

   IF SAFETY NUMBER CHANGES:
   1. Stop - don't send anything sensitive
   2. Verify via alternative channel
   3. Report if unexplained

   IF DEVICE LOST/SEIZED:
   1. Report immediately to [security contact]
   2. Remote wipe if possible
   3. Assume all local messages compromised
   4. New device = new verification needed

   EMERGENCY CONTACTS:
   Security focal: [number]
   IT support: [number]
   24-hour emergency: [number]

Document training completion:

   Training Completion Record
   --------------------------
   Staff member: ________________
   Date: ________________
   Trainer: ________________

   Competencies demonstrated:
   [ ] Installed and configured Signal correctly
   [ ] Completed safety number verification with trainer
   [ ] Configured disappearing messages appropriately
   [ ] Explained when to use each communication channel
   [ ] Described safety number change response procedure
   [ ] Knows how to report suspected compromise

   Signature: ________________

Phase 8: Fallback procedures

Establish fallback communication channels when primary secure channels fail:

   Communication Channel Fallback Hierarchy
   ----------------------------------------

   Primary:     Signal (verified contacts)
                |
                | If unavailable (no internet, app blocked)
                v
   Secondary:   Wire (team communications)
                |
                | If unavailable
                v
   Tertiary:    Satellite phone (emergency coordination only)
                [Remember: NOT encrypted end-to-end]
                |
                | If unavailable
                v
   Emergency:   Pre-arranged physical meeting points
                Pre-arranged radio check-in times (if HF/VHF available)

Configure out-of-band verification channels. When primary platforms are compromised or unavailable, staff need a method to verify identity and coordinate:

   Out-of-Band Verification Setup
   ------------------------------

   Each staff member records:
   - Personal verification phrase (something only they would know)
   - Secondary contact method (family member phone, personal email)
   - Emergency code words:
     * "All clear" phrase: ________________
     * "Under duress" phrase: ________________

   Verification process if primary channel compromised:
   1. Contact via secondary method
   2. Request verification phrase
   3. Verify response before sharing sensitive information

Establish procedures for platform unavailability due to blocking:

   If Signal blocked in-country:

   Option 1: Domain fronting (if available)
   - Signal may use domain fronting in some regions
   - Automatically enabled; no user action required
   - Check signal.org/blog for current status

   Option 2: VPN/Proxy
   - Connect to VPN before launching Signal
   - Signal should work over VPN connection
   - Test before deploying to field

   Option 3: Bridge or proxy (advanced)
   - Tor: Orbot + Signal (high latency)
   - Organisational proxy: Requires infrastructure

   Option 4: Alternative platform
   - Fall back to Wire (different infrastructure)
   - Fall back to organisational encrypted email
   - Fall back to satellite for emergencies

Test fallback procedures before deployment:

   Fallback Testing Checklist
   --------------------------
   [ ] Signal works over VPN connection
   [ ] Wire works as Signal backup
   [ ] Satellite phone tested and functional
   [ ] Out-of-band verification phrases recorded securely
   [ ] Emergency contact numbers programmed
   [ ] Staff knows fallback hierarchy
   [ ] Fallback procedures documented in accessible location

Verification

Confirm secure communications are operational through the following checks:

Encryption verification complete:

[ ] All field staff have verified safety numbers with each other
[ ] Verification register is complete and current
[ ] All staff can explain verification procedure

Platform configuration correct:

# Signal configuration check (on device)
Settings > Privacy:
  Screen Lock: ENABLED
  Screen Security: ENABLED
  Always Relay Calls: ENABLED (for high-risk contexts)
  Incognito Keyboard: ENABLED

Settings > Privacy > Disappearing Messages:
  Default timer: Configured per policy

# Check from command line (desktop)
# Signal Desktop stores config in:
# Windows: %APPDATA%\Signal\config.json
# macOS: ~/Library/Application Support/Signal/config.json
# Linux: ~/.config/Signal/config.json

Staff competency confirmed:

[ ] All staff completed training with documented sign-off
[ ] All staff have reference materials
[ ] All staff demonstrated key verification
[ ] All staff know fallback procedures

Test message exchange:

1. Exchange test message with disappearing messages enabled
2. Verify message disappears after configured interval
3. Conduct test voice call
4. Verify both parties see matching security phrase
5. Test with VPN enabled (if used)

Troubleshooting

Symptom	Cause	Resolution
Safety number changed unexpectedly	Contact reinstalled app or changed device	Verify via out-of-band channel before continuing; if unexplained, report to security focal
Registration verification code not received	SMS delivery failure, carrier blocking	Use voice verification option; try at different time; use alternative number
Call quality poor	Bandwidth insufficient, relay routing	Disable “Always Relay Calls” if IP exposure acceptable; move to better connectivity; try audio-only
Cannot link desktop to mobile	QR code timeout, version mismatch	Ensure both on latest version; retry with fresh QR code; check same account on both
App blocked by network	National or local blocking	Enable VPN before launching app; try mobile data instead of WiFi; use Tor
Message not delivered	Recipient offline, app not running in background	Wait; verify recipient’s device configuration; try alternative channel
Key verification fails (numbers don’t match)	Verifying wrong contact, display error	Confirm contact identity; restart app; re-check; if persistent mismatch, investigate
VPN disconnects during use	Unstable network, VPN server issue	Reconnect; try different VPN server; check VPN client logs
Device won’t send messages after SIM change	Signal registration bound to old number	Re-register with new number; re-verify with all contacts
Backup/restore fails	Incorrect PIN, corrupt backup	Verify PIN; wait 24h if locked out; contact support; worst case: new account and re-verify
Wire team invitation not received	Email delivery failure, spam filter	Check spam folder; resend invitation; try different email address
Element decryption fails (UTD errors)	Key synchronisation issue, device not verified	Verify device via cross-signing; restore from backup if available; request re-send
Voice call shows no security phrase	Call not encrypted, older version	Update app; verify both parties on current version; check call is peer-to-peer
High latency on all communications	Relay routing, Tor, poor connectivity	If latency unacceptable: disable Always Relay (accepting IP exposure); upgrade connectivity