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
Export data	Downloads everything stored for the account as a ZIP. Needs Manage on accounts; see below

Disabling is the reversible option and the one to reach for first. Soft-delete starts a clock: Gdpr:DeletionGraceDays (default 14, at most 30) 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, Admin.User.Exported, and Admin.Role.Granted / Admin.Role.Revoked — with the acting administrator recorded.

Handing the data back

Export data is for returning an account’s data when a contract ends. It downloads the same ZIP the user gets from their own export in Pia, and it works for a disabled or soft-deleted account for as long as its data has not been purged. Items the user encrypted stay encrypted in the file: the server holds only the ciphertext. The file contains personal data, so handle it like the account itself. The download is recorded as Admin.User.Exported with the administrator and the account’s id, never with the content.

In the file, an audit entry in which someone else acted on the account — an administrator, or a manager of the customer’s organisation — names that actor only by role and a pseudonym that stays the same within the file (admin-1, manager-1). The action and its time stay; the actor’s address, account id, IP address and browser are left out.

Other people the account’s own entries name are treated the same way. When the account itself acted on someone else — a manager inviting, moving or removing a member, an administrator granting a role — the other account appears as a pseudonym from the same list (member-1 in the organisation’s entries, user-1 in the others), not by its id. The details of an entry keep only the account’s own address: another person’s address, such as the invitee’s or the inviting manager’s, is left out, and one inside a free-text value reads (address removed). This applies to the user’s own export as well, and the audit log on the server is unchanged.

On Pia Cloud, operations hands the file over like this: the ZIP is packed into a 7z archive with AES-256 encryption and shared through a SharePoint link that only the recipient can open and that expires after 14 days. The password goes to the recipient through a separate channel. If you run your own server, the export is the file to hand back; how you transfer it is up to you.

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.