On This Page

KeyOS is Foundation's Rust-based microkernel operating system, built on the open-source Xous project. It's designed from the ground up for secure, modular, multi-app personal security hardware - and it's what every app on Passport Prime runs on top of.

Why a microkernel

Most operating systems run drivers and system services in the kernel, where a single bug can compromise the whole device. KeyOS instead runs everything as isolated user-space processes that talk to each other through managed message-passing.

This buys three things that matter for personal security hardware:

  1. Resilience and modularity. Each process is self-contained. A vulnerability in one app - even a system service - can't take down the system or read data it shouldn't.
  2. Process isolation. Apps run in their own kernel-enforced sandboxes. A buggy or malicious app cannot read another app's memory or storage.
  3. Message-passing communication. Processes interact only through declared message channels with declared permissions, drastically reducing attack surface compared to shared memory or unrestricted syscalls.

KeyOS manages permissions, mediates hardware access, and lets multiple apps run side-by-side without compromising security.

Security model

Prime takes a defense-in-depth approach to third-party apps. Here's what you can rely on as an app developer:

  • Process isolation. Every app runs in its own Xous process with its own address space. Apps cannot read each other's memory.
  • Storage scoping. Apps get their own filesystem scope. The fs API exposes distinct scopes - Airlock for quarantined incoming files, User for private app storage, USB for external - and an app cannot read another app's private storage.
  • Declarative permissions. Every system call your app needs is declared up front in manifest.toml. The kernel rejects undeclared calls. There is no "runtime escalation" - what's in the manifest is the entire attack surface.
  • Secure element gating. Access to seeds, the secure element, and device identity goes through os/security. Apps must declare these permissions explicitly, and sensitive operations (e.g. seed retrieval) require user confirmation on the trusted display.
  • Trusted display path. User confirmations and PIN entry happen through KeyOS-controlled UI, not through the requesting app's UI. An app cannot spoof a system prompt.
  • No network by design. Prime has no IP stack and no Wi-Fi. The only outbound paths are USB-C, NFC, camera, and QuantumLink Bluetooth - all user-initiated, all visible.
  • Open and auditable. KeyOS firmware is open source. Third parties can audit the kernel, the API surface, and your app independently.

Permissions

Every app declares the exact set of capabilities it needs in its manifest.toml. The kernel enforces this declared set at runtime - there is no escalation path.

Permissions are declared per-service. A typical declaration looks like:

[permissions]
"os/gui-server" = ["GetPendingNavRequest", "SwitchToLauncher"]
"os/quantum-link" = ["SendAccountUpdate", "PublishPsbt"]

For the full list of services and methods you can declare, see Building Apps and the Capability Matrix .

Architecture diagrams

🚧 Coming soon. Planned diagrams: (1) microkernel + services + apps via IPC, (2) permission declaration → kernel enforcement → trusted-display prompt, (3) app lifecycle state machine, (4) QuantumLink data flow between phone and Prime. Happy to generate these via FigJam — reviewers, let us know if there's an existing internal diagram to base them on.

Threat model

🚧 Coming soon. We're working on a formal threat model doc covering in-scope attackers (remote, local-software, physical with device access, supply-chain), out-of-scope scenarios, specific mitigations per class, and a side-by-side comparison vs Ledger's Secure Element and Trezor's Optiga. Security team input required before publishing.

Open source

KeyOS firmware lives at github.com/Foundation-Devices/KeyOS . Third-party security review is welcomed and encouraged - personal security hardware should not be a black box.

For more on the design philosophy and architecture, see the Building KeyOS blog post.