Technical architecture

One managed architecture from device to oversight.

W.O.L.F combines managed Android devices, private connectivity, selected user services, lifecycle controls and monitoring within one coordinated technical model.

This page presents a public-safe capability view. Detailed configuration, credentials, addressing and defensive settings are not published.

  1. 01Managed device and identity
  2. 02Private access
  3. 03User services
  4. 04Management and lifecycle
  5. 05Monitoring and recovery
Connected layers
05
Service access
Private
Device lifecycle
Managed
Evaluation
Evidence captured

Architecture overview

Five connected layers link the managed device, private access, selected services, lifecycle controls and monitoring within one coordinated capability.

  1. Layer 01

    Managed device and identity

    Each managed handset has a named device record, managed Android baseline, unique WireGuard peer identity, TAK client certificate, Matrix device identity, named Nextcloud account and Guardian registration. Device and administrative credentials are not shared.

  2. Layer 02

    Private access

    WireGuard-based private connectivity uses individually assigned peer credentials and approved service paths. Public internet exposure is minimised and access can be removed independently for one device.

  3. Layer 03

    User services

    Matrix and Element support encrypted communications; Nextcloud, Talk and Collabora support controlled collaboration; TAK and WinTAK support authorised location and common-operating-picture functions.

  4. Layer 04

    Management and lifecycle

    Control Centre and Guardian support registration, issue and return records, check-in, access enablement and removal, authorised lock or wipe, rebuild, reissue and retained lifecycle evidence.

  5. Layer 05

    Monitoring and recovery

    Centralised security-event monitoring, configuration and integrity review, encrypted backup, documented restore testing and recovery evidence support technical review and controlled recovery.

Device and identity

Each approved handset is prepared to a defined baseline and associated with an accountable device and user identity.

Managed device baseline

  • Prepared Android configuration
  • Named device record and managed user association
  • Restricted application set and installation controls
  • Guardian registration and check-in
  • Issue, return, rebuild and reissue record

Accountable identity

  • Unique WireGuard peer identity
  • Unique TAK client certificate
  • Matrix device identity and named Nextcloud account
  • Separate administrative accounts
  • No shared device, user or administrative credentials

The device, user identity and approved access remain connected throughout the managed lifecycle.

Private access

Approved devices use WireGuard-based private connectivity to reach selected W.O.L.F services without directly exposing those services to the public internet.

  1. 01

    Per-device access

    Each managed device uses one individually assigned WireGuard peer identity and private-access profile; client configuration is not shared across the fleet.

  2. 02

    Restricted routes

    Routing is limited to approved service paths, keeping selected services behind the VPN-internal service boundary.

  3. 03

    Access removal

    A lost, returned or retired device can have its own peer identity removed without replacing the full fleet configuration.

  4. 04

    Private service boundary

    Service exposure to the public internet is minimised; authorised devices reach selected services through private connectivity.

Detailed cryptographic parameters, network ranges, endpoints and firewall configuration are not published.

WireGuard transport security

WireGuard provides the private transport layer between approved managed devices and selected services. Its configuration is managed per device rather than shared across the fleet.

Private transport

Per-device encrypted access

  • UDP-based encrypted tunnelling for the private transport layer
  • ChaCha20-Poly1305 authenticated encryption and BLAKE2s hashing
  • HKDF key derivation with forward secrecy and re-keying
  • One peer identity and key pair per managed device
  • Device-specific access removal without a shared client configuration

Revocation boundary

Contain one device

Loss of one device should result in removal of that device’s peer identity rather than replacement of the full fleet configuration.

Addresses, endpoints, routes, peer configuration and defensive settings remain controlled operational information.

Communications, files and location

Selected applications provide approved communications, collaboration, file access and location-awareness functions inside the managed environment.

Matrix and Element

Connect

Matrix is the messaging protocol and Element the user client for approved encrypted rooms within the managed service boundary.

  • Device-specific cryptographic identity and session management
  • Approved-room end-to-end encryption
  • Public registration and guest access disabled
  • Lost-device session removal where required

Nextcloud and collaboration services

Files

Nextcloud, Talk and Collabora support controlled collaboration through private access, named users and role-appropriate permissions.

  • HTTPS/TLS transport protection
  • Restricted external sharing and public registration
  • Named users, groups and role-appropriate permissions
  • File retention, encrypted backup and restore testing

TAK and WinTAK

Track

TAK and WinTAK support authorised location awareness, CoT information, markers and routes through controlled private access.

  • One client certificate per managed device
  • Authorised location awareness
  • Location services separated from messaging and file services
  • Certificate removal when a device is lost or retired

Matrix and Element cryptography

Demonstrated

  • Olm supports device-to-device session establishment; Megolm supports encrypted group sessions.
  • Curve25519 and Ed25519 support device identity and signing functions.
  • Approved rooms use end-to-end encryption; this does not imply all service metadata is end-to-end encrypted.
  • Federation, public registration and guest access are disabled where currently applicable.

Nextcloud, Talk and Collabora security

Demonstrated

  • Private service access and HTTPS/TLS protect approved transport paths.
  • Named users, groups and role-appropriate permissions support controlled collaboration.
  • Ordinary file storage is not presented as automatically end-to-end encrypted.
  • Retention, encrypted backup and documented restore testing support recovery.

TAK and WinTAK service controls

Demonstrated

  • Private-access-only connectivity and one client certificate per managed device.
  • Authorised CoT information, markers and routes support accountable location awareness.
  • WinTAK access remains controlled and associated with an accountable user and device.
  • Certificate removal supports lost-device or retirement actions.

Device and credential isolation

Each device remains associated with distinct service identities and lifecycle evidence, so access can be reviewed and removed without changing unrelated devices.

Device record
Named device, issue and return record
WireGuard
Individual peer identity and private-access profile
TAK
Individual client certificate
Matrix
Device-specific cryptographic identity and sessions
Nextcloud
Named account or controlled session
Guardian
Device registration and lifecycle record

VPN profiles, TAK certificates, Matrix device identities, Nextcloud accounts and administrative credentials are not shared. Unknown application installation is restricted, and lost-device actions are recorded against the named device record.

Management and lifecycle

Control Centre and Guardian link project oversight with device registration, status, access removal, recovery and rebuild.

Control Centre

Demonstrated
  • Device and project records
  • User and device association
  • Current device status
  • Lifecycle records
  • Access-management support
  • Evidence capture

Guardian

In development
  • Device registration
  • Device check-in
  • Access revoke
  • Remote lock and wipe demonstrated in testing
  • Recovery and rebuild support
  • Expanded controls in development

Lost-device revocation chain

Remove, preserve, replace and confirm

The sequence separates service access, lifecycle evidence and authorised device action so one affected device can be contained without changing the wider fleet.

  1. 01Identify and confirm the affected device
  2. 02Remove the device’s WireGuard peer access
  3. 03Revoke its TAK client certificate
  4. 04Disable the relevant Matrix device and sessions
  5. 05Disable or suspend its Nextcloud access and sessions
  6. 06Queue Guardian lock or wipe only where authorised
  7. 07Preserve audit and lifecycle evidence
  8. 08Create replacement credentials
  9. 09Rebuild and reissue a clean managed handset
  10. 10Confirm the old identity cannot reconnect

Server hardening, Wazuh and recovery

The current pilot uses a restricted server baseline, isolated services, monitoring and recovery procedures to support technical operation and evaluation.

Server hardening and isolation

Demonstrated
  • Supported Ubuntu LTS baseline
  • SSH key-only administration and named admin accounts
  • Default-deny firewall and minimal public exposure
  • Private service boundary and separated operational administration
  • Secrets excluded from public repositories
  • Logged administration, documented patching and controlled change

Wazuh monitoring and security evidence

In development
  • Planned Wazuh XDR/SIEM layer for security-event review
  • Central collection of authentication and administrative events
  • Integrity, configuration and selected vulnerability monitoring
  • Alert triage, retained evidence and review records
  • Coverage of firewall, VPN, Matrix, Nextcloud, TAK and device-management events

Backup, restore and recovery evidence

Planned
  • Encrypted backups and documented retention decisions
  • Restore testing against a clean environment
  • Device and service recovery procedures
  • Rebuild and reissue support for managed handsets
  • Recovery evidence retained for technical review

Governance and assurance controls

Technical controls are supported by accountable ownership, maintained procedures and evidence that can be reviewed before any wider decision.

Accountability and evidence

Controlled technical operation

  • Named capability or system owner and technical administrator
  • Maintained device register and approved information-handling rule
  • Issue and return process, lost-device SOP, and backup and recovery SOP
  • Restore-test evidence, patching routine and incident-management process
  • External technical review and independent testing before wider scale
  • Formal approval and authority to operate retained as separate decisions

Approval boundary

Technology does not grant authority

The technical model supports structured review. Formal classification, risk acceptance, accreditation and authority to operate remain separate accountable decisions.

Technical status and boundaries

The architecture distinguishes demonstrated technical functions, work still in development and decisions that remain separate from implementation.

Demonstrated

  • Managed pilot devices
  • Private device access
  • Selected communication and file services
  • Authorised location-awareness integration
  • Functional web-based Control Centre
  • Device registration and Guardian check-in
  • Access removal and rebuild
  • Remote lock and wipe demonstrated in testing

In development

  • Expanded Guardian management controls
  • Application installation and update support
  • Stronger role and account management
  • Improved monitoring and recovery
  • Multi-project separation
  • Larger fleet support
  • Formal trial evidence

Separate approval decisions

  • Independent security testing
  • Classification decision
  • Residual-risk acceptance
  • Requirement-owner approval
  • Authority to operate
  • Wider deployment approval

A technically demonstrated architecture does not itself constitute formal assurance, accreditation or authority to operate.

Next technical questions

The next phase should assess whether the architecture provides reliable services, effective device management, recoverable operation and sufficient evidence for a wider pilot decision.

  1. 01Service reliability
  2. 02Device-management effectiveness
  3. 03Monitoring and recovery
  4. 04Security and assurance evidence