Architecture overview
Five connected layers link the managed device, private access, selected services, lifecycle controls and monitoring within one coordinated capability.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 02
Restricted routes
Routing is limited to approved service paths, keeping selected services behind the VPN-internal service boundary.
- 03
Access removal
A lost, returned or retired device can have its own peer identity removed without replacing the full fleet configuration.
- 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.
- 01Identify and confirm the affected device
- 02Remove the device’s WireGuard peer access
- 03Revoke its TAK client certificate
- 04Disable the relevant Matrix device and sessions
- 05Disable or suspend its Nextcloud access and sessions
- 06Queue Guardian lock or wipe only where authorised
- 07Preserve audit and lifecycle evidence
- 08Create replacement credentials
- 09Rebuild and reissue a clean managed handset
- 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.
- 01Service reliability
- 02Device-management effectiveness
- 03Monitoring and recovery
- 04Security and assurance evidence