Immutable Endpoint
Architecture
Read-only OS. Zero local persistence. Every boot verified.
VelaOS endpoints are designed to fail closed. No writable system partition, no local credential storage, no unsigned code execution. The device is a display terminal — the intelligence and the data live in the cloud, behind your firewall, in your tenant.
Five security pillars
Each pillar describes what the device does and what guarantee it provides. Architecture details are available under NDA.
Verified boot
Every boot is cryptographically validated. Tampered images refuse to start.
The bootloader verifies a cryptographic hash of the system partition against a hardware-anchored signature before loading any code. If the hash does not match — because the image was modified, corrupted, or replaced — the device refuses to boot and reports the failure to the cloud. There is no permissive mode, no override, and no way to skip the check. The operator sees the device drop out of the fleet, triggering an automated alert.
Atomic A/B updates
OTA applied to a parallel slot. Automatic rollback. Zero half-updated state.
The device maintains two system partitions. An OTA update is written to the inactive slot while the active slot continues running. On the next boot, the bootloader switches to the updated slot. If the new slot fails a health check within the watchdog window, the bootloader falls back to the previous slot — automatically, atomically, without operator intervention. Ring deployments enforce this further: pilot rings soak before broad promotion, and broad rings auto-halt if the failure rate exceeds a threshold.
Mandatory access control
Kernel-enforced process isolation. No privilege escalation between workloads.
Every process on the device runs in a security domain defined by kernel-level mandatory access control policies. The VDI client, the management agent, the network stack, and the system services each operate in isolated domains. A compromised VDI session cannot read the agent's policy store. A compromised browser cannot write to the system partition. These policies are enforced by the kernel, not by the applications themselves — they cannot be bypassed by user-space code regardless of the vulnerability.
Per-device mutual TLS
Hardware-backed key generation. The private key never leaves the device.
At enrolment, each device generates a key pair inside a hardware-backed secure enclave. The private key is bound to the hardware and cannot be exported, copied, or read by any software — including the management agent itself. All device-to-cloud communication uses mutual TLS with these per-device certificates, authenticated against a per-tenant certificate authority. If a device is wiped, its certificate is revoked and the key material becomes permanently unreachable.
Signed OTA chain
Every update payload is cryptographically signed. Hash-verified before install.
OTA payloads are signed with a release key during the build process. The agent verifies the signature against a pinned public key before writing anything to the inactive partition. App packages uploaded to the catalogue are hashed at upload time; the agent verifies the hash at install time. There is no mechanism to install unsigned code — not through the agent, not through the management console, and not through physical access to the device.
Compliance posture
Where we are today and what ships with v3.0.0 general availability.
Scheduled for v3.0.0 GA
Post-GA roadmap
Structural — EU-only hosting, no data leaves EU
Frankfurt primary, secondary EU region for backups
What this page does not disclose
This page describes the security model — the guarantees each device provides to the fleet operator. It does not describe the implementation: the build chain, the signing infrastructure, the CI/CD pipeline, or the internal architecture of the management agent. These details are available to enterprise customers under mutual NDA as part of a security review engagement.
Read the full security whitepaper
Procurement-ready. Ungated. No form, no email capture.