Users

The Accounts page (/admin/accounts) lists every account — search by email or name, then narrow by provider, group, membership (assigned to a group explicitly vs inheriting the default), status (active or disabled) and lifecycle (live or deleted). Columns show roles, group, status, creation and last login.

Two things happen here: finding an account, and moving accounts between groups in bulk. Everything else — roles, disabling, deletion — happens on the account’s own page, reached from the row’s detail link (/admin/users/{id}).

Roles

Pia has two effective roles:

• User — the default. Can sign in, sync, and use the AI proxy.
• Admin — additionally has access to /admin/*.

There is no built-in “viewer” or “support” role; the admin UI is all-or-nothing. Open the account and press Grant admin or Revoke admin; both are audited as Admin.Role.Granted / Admin.Role.Revoked.

Two guards on demotion

Revoking admin from the only remaining administrator is blocked — it would lock the instance out of its own admin pages. So is revoking your own admin role, or soft-deleting your own account: ask another administrator. A session whose identity cannot be read fails the same way rather than being waved through.

The admin count on Settings is a different number

The status strip on Settings → Overview counts addresses in the Admin:Emails bootstrap list, not accounts holding the admin role. Who actually holds it is visible in the Roles column here.

Identity sources

A user’s authentication provider is recorded as one of:

• Local — email + password registered through /auth/register.
• Google — OAuth via Google.
• Microsoft / EntraID — OAuth via Microsoft Entra (see Entra OAuth).

A given email belongs to exactly one provider; the OAuth callback returns 409 email_exists if the same address shows up under a second provider. This avoids account-confusion attacks where a victim’s local-password account could be silently linked to an attacker-controlled OAuth identity.

Account actions

Action	Effect
Disable account	The user is signed out and cannot sign in again until re-enabled. Their data stays exactly as it is
Enable account	Reverses it
Force password reset	Local accounts only — issues a reset for the account
Revoke all sessions	Invalidates issued tokens without disabling the account. The right response to a suspected token leak
Grant / Revoke admin	The role change above
Soft-delete	Tombstones the account. It disappears from the working views and is purged permanently after the grace window

Disabling is the reversible option and the one to reach for first. Soft-delete starts a clock: Gdpr:DeletionGraceDays (default 14) after the tombstone, a background service purges the account and its data for good — which is how a deletion request is satisfied without an irreversible click. Within the window the account shows as deleted and awaiting purge; after it, there is nothing left to restore.

Every action here is audited — Admin.User.Disabled, Admin.User.Enabled, Admin.User.ForcePasswordReset, Admin.User.SessionsRevoked, Admin.User.SoftDeleted, and Admin.Role.Granted / Admin.Role.Revoked — with the acting administrator recorded.

Recovery

If a user has lost access to all their devices:

• No E2EE: an admin can force a password reset (for local accounts) or the user can re-sign-in via OAuth on a new device.
• E2EE enabled: the user must use their recovery code. Without it, encrypted records (memory, sessions, providers, todos) cannot be decrypted by anyone — including admins.

To see what an account is actually holding on the server, and what remains readable when E2EE is on, use Synced items.