Why this environment matters
A tactical edge computer may operate with intermittent links and an increased risk of physical capture. It must make useful local decisions without assuming that a central identity or update service is reachable. This concept examines how a mission-scoped execution environment could constrain access while making its disconnected limits explicit.
The security challenge
Before deployment, an authorised process could provision a defined set of mission applications, datasets and temporary permissions. A candidate NØNOS runtime would admit only the approved capsules and expose the devices needed for that task. A communications decoder would not automatically obtain the authority to modify mission data or approve an outgoing command.
How the capsule model could help
The hard question is how permissions age without connectivity. The design would specify what continues, what expires and which local authority may approve an exception. It would also identify how the device detects clock uncertainty. Simply caching an online login and treating it as permanent would leave the mission boundary undefined. RAM-resident operation might limit some persistent application residue, but it does not make captured hardware self-protecting. Keys can remain exposed during an active session, and firmware, peripherals or retained storage may hold relevant material. The hardware trust base and key-handling design would therefore be explicit assessment items. On reconnection, the device should reconcile mission events and revocation information rather than silently extending yesterday’s permissions. An evaluation could exercise these transitions with synthetic mission data, while keeping operational authorisation, classified material and deployment approval outside the prototype.
Deployment requirements
No military accreditation, classified-processing approval or capture-resistance guarantee is claimed. Drivers, cryptographic provisioning, secure boot, hardware behavior and mission-specific operating procedures would need independent assessment. Evaluation requirements: Remove connectivity across a permission-expiry boundary and verify the documented continuation or refusal behavior. Introduce clock uncertainty and demonstrate that the device does not silently extend time-bounded authority. Revoke a provisioned application while the device is offline, then check the defined reconciliation behavior on return.
Current public-beta limitations, hardware support and application availability must be assessed before any pilot. Neither this use case nor an industry source establishes NONOS certification or a current customer deployment.
Carry a bounded authority into a disconnected period
Before deployment, an authorised process could provision a defined set of mission applications, datasets and temporary permissions. A candidate NØNOS runtime would admit only the approved capsules and expose the devices needed for that task. A communications decoder would not automatically obtain the authority to modify mission data or approve an outgoing command.
The hard question is how permissions age without connectivity. The design would specify what continues, what expires and which local authority may approve an exception. It would also identify how the device detects clock uncertainty. Simply caching an online login and treating it as permanent would leave the mission boundary undefined.
Plan for capture and for lost state separately
RAM-resident operation might limit some persistent application residue, but it does not make captured hardware self-protecting. Keys can remain exposed during an active session, and firmware, peripherals or retained storage may hold relevant material. The hardware trust base and key-handling design would therefore be explicit assessment items.
On reconnection, the device should reconcile mission events and revocation information rather than silently extending yesterday’s permissions. An evaluation could exercise these transitions with synthetic mission data, while keeping operational authorisation, classified material and deployment approval outside the prototype.
Who could buy or integrate it?
- Defence programme offices buying rugged tactical computing systems
- Rugged computer manufacturers integrating execution platforms into equipment
- Mission-system primes adapting applications for disconnected field operation
Industry examples: Curtiss-Wright, Mercury Systems. These are research prospects, not represented as NONOS customers, partners or endorsers.