Zero-trust GrapheneOS: a hardened daily-driver configuration

Zero trust is an architectural principle from enterprise network security: nothing is trusted by default, every component must prove its legitimacy before being granted access, and access is granted only to the minimum required scope. Applied to a mobile device, zero trust means treating every installed app, every network connection, and every permission grant as a potential risk — rather than assuming safety until something goes wrong. This article walks through a complete zero-trust configuration for GrapheneOS as a daily driver, covering each setting category and the reasoning behind it.

The baseline assumption

A zero-trust phone setup starts from a specific assumption: you cannot fully audit the code of every app you install, you cannot verify every network you connect to, and you cannot trust that app developers or their third-party SDKs will behave as stated. The configuration is designed to contain damage when one of these assumptions proves correct — not to prevent every possible scenario, but to ensure that a compromised app, a malicious SDK, or a network-level attack reaches as little of your data and functionality as possible.

GrapheneOS enables this approach because it provides per-app controls that stock Android does not. The same configuration cannot be replicated on a standard Android device or an iPhone.

Step 1: User profiles

GrapheneOS supports multiple isolated user profiles, each running as a completely separate Android instance with its own apps, data, and settings. No profile can access another profile's data.

The zero-trust approach: use your Owner profile as a minimal, high-security environment. Install only what you genuinely need for daily use, configured with strict permissions. Create secondary profiles for:

• Work or sensitive tasks: a profile for financial apps, email, or document handling — isolated from your personal profile
• Sandboxed Google Play: if you need apps that require Google Play Services, install them in a separate profile so Play Services cannot access your primary profile's data or contacts
• Untrusted apps: apps you need occasionally but don't fully trust go in a secondary profile that you can switch to, use, and switch away from

A profile that isn't active is not running. Its apps cannot make network connections, access sensors, or run background processes. This is a stronger isolation boundary than any per-app sandbox.

Step 2: Network permission per app

Navigate to Settings → Apps → [App Name] → Permissions for every installed app, and ask one question: does this app need internet access to perform its function for me?

Revoke network access from: calculators, local note apps, offline games, document editors where you control file sync separately, alarm clocks, flashlights, local media players, and any other app whose function is entirely local. This is not a theoretical protection — it prevents these apps from transmitting data regardless of what SDKs they contain or what their developers may decide in future updates.

For apps that do need network access, pair network permission with careful review of the other permissions they hold. An app with network access and microphone permission is a meaningful surveillance risk. An app with network access only is limited to data it generates locally.

Step 3: Sensor permissions

GrapheneOS exposes a Sensors permission toggle per app that controls access to the accelerometer, gyroscope, barometer, and other hardware sensors. This permission does not exist on standard Android.

Revoke sensors from any app that doesn't require motion sensing for its function. This matters because: motion sensors can be used to infer keystrokes via vibration analysis, identify your location via movement patterns, and serve as a side-channel for audio eavesdropping in some documented attack scenarios. Most apps have no need for this data at all.

Step 4: Encrypted DNS resolver

Configure a DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) resolver in GrapheneOS's network settings. By default, DNS queries reveal every domain you visit to your network operator and any passive observer on the network. Encrypted DNS prevents this.

Recommended options include Quad9 (operated by a Swiss non-profit with a no-logging policy), Mullvad DNS (operated by a privacy-first VPN provider in Sweden), or NextDNS (configurable blocklists, EU data residency available). GrapheneOS natively supports both DoH and DoT — no third-party app required.

Configure this at Settings → Network & Internet → Private DNS and enter your chosen resolver's hostname. This applies system-wide to all apps on that profile.

Step 5: Sandboxed Google Play

If you need apps that require Google Play Services, install sandboxed Google Play in a secondary profile only. Never install it in your primary profile. The reasoning: Google Play Services, even in sandboxed mode, has access to your installed app list, some device characteristics, and any permissions you grant it. Confining it to a secondary profile means it cannot access your primary profile's data, contacts, or communications.

Within the secondary profile, treat Play Services like any other over-privileged app: review its permissions, revoke what isn't necessary, and avoid logging into your primary Google account in this profile — use a separate account if Google account sign-in is required at all.

Step 6: Automatic reboot

GrapheneOS includes a built-in automatic reboot timer (Settings → Security → Auto reboot). When enabled, the device automatically reboots after a configurable period of inactivity — 8 hours, 12 hours, 18 hours, or 72 hours.

This matters because of Android's encryption architecture. After a reboot, the device is in a Before First Unlock (BFU) state: encryption keys are not loaded in memory, and data partitions are cryptographically inaccessible even to a sophisticated attacker with physical device access. Once you unlock the device, it enters After First Unlock (AFU) state where keys are in memory. Automatic reboot returns the device to BFU periodically, limiting the window during which physical access to the device could yield data.

For most users, a 72-hour auto-reboot is a reasonable starting point that provides meaningful protection without disrupting daily use.

Step 7: Hardware-backed attestation

GrapheneOS supports hardware-backed attestation via the device's Titan M security chip (on Pixel devices). Attestation allows the device to cryptographically prove to a remote service that it is running verified, unmodified software. The proof is signed by keys that are protected in the secure enclave and cannot be extracted or forged by software.

In practice, this means: a service that supports attestation can verify that your device is running the specific GrapheneOS build you claim, with a locked bootloader and no signs of tampering — before granting access. Several privacy-oriented services and enterprise deployments use this to verify device integrity at login.

You can verify your own device's attestation state through GrapheneOS's auditor app (available in the official GrapheneOS app repository), which performs a local or remote attestation check and confirms whether your device's software state matches what GrapheneOS's servers have on record for that build.

Step 8: App sources

In a zero-trust setup, app provenance matters. The two recommended sources for GrapheneOS:

• F-Droid: the open-source Android app repository. All apps are open source and can be audited. F-Droid builds apps from source, which means you're not relying on the developer's binary. The selection is comprehensive for privacy tools, utilities, and productivity apps.
• Obtainium: a tool that downloads APKs directly from developer GitHub releases or other specified sources. This is appropriate for apps that release openly on GitHub but aren't yet in F-Droid — it ensures you get the exact binary the developer signs and publishes, without an intermediary repository that could be compromised.

For the Play Store: if you use sandboxed Google Play in a secondary profile, it is available there for apps that have no open-source alternative. Treat Play Store apps as less trusted than F-Droid apps by default and apply stricter permission reviews accordingly.

Pre-configured on every Norypt Phone

This configuration requires time and familiarity with GrapheneOS to set up correctly from scratch. Every Norypt Phone ships with a zero-trust baseline configuration already applied: encrypted DNS configured, per-app network permissions reviewed, automatic reboot enabled, and the user profile structure established. The device arrives ready for daily use with the hardening already in place — not as a project for the recipient to complete after delivery.