User Roles
Every tiCrypt account holds one system role. It decides two things: which other users the account can see, its visibility, and which other users it can manage. Roles form a hierarchy, so a higher role can modify accounts below it and never the reverse. Every role change is recorded permanently in the audit trail.
A role does not decide what a person can do. That comes from permissions, granted through User Profiles. Super-Admin is the single exception: it bypasses permission checks entirely.
Permissions govern actions, not readability. Data stays cryptographically inaccessible unless its owner has shared the keys, so no role, including Super-Admin, can read user data.
The roles at a glance
Ordered from the most common to the rarest.
| Role | Purpose | Typical control | Where authority stops |
|---|---|---|---|
| User | Research work | Own files, drives, and VMs; collaboration they are permitted | No administrative authority over anyone |
| Sub-Admin | Delegated administration | The teams and projects assigned to them | Anything outside that assigned scope |
| Admin | Deployment administration | Users, teams, projects, and infrastructure, under profile permissions | No user data, and no Super-Admin-only settings |
| Super-Admin | Global platform administration | The entire system configuration | Still no access to encrypted user data |
| Escrow User | Key recovery | One key part of the recovery key | No access to tiCrypt itself |
| Site Key Admin | Certification authority | Signing escrow certificates and deletion requests | Operates outside tiCrypt; manages no users |
User
The default role and the one nearly everyone holds. A User is a researcher who stores data in the Vault and works in virtual machines.
Day to day they create and run VMs, attach drives, upload and download files, and share with the people they collaborate with.
They must belong to a team to be active, and may own groups or projects where permitted. A User holds the private key that decrypts their resources. If that key is lost and the deployment has no escrow, the data cannot be recovered.
Sub-Admin
An administrator with a boundary. Sub-Admin is delegated management scoped to specific teams, projects, or both, assigned by an Admin or Super-Admin.
Day to day they do what an Admin does, but only inside their scope: managing users, resource limits, memberships, and the VMs and drives belonging to the teams or projects they were given.
Outside that scope they have no authority at all, and they gain no access to data unless it is explicitly shared with them. Not every deployment uses Sub-Admins.
- Teams carry resource constraints for a set of users. A user removed from every team is deactivated.
- Projects are access-controlled containers. Resources tagged with a project are restricted to certified members.
Admin
Deployment-wide administration, under permission control.
Day to day they manage users, teams, projects, infrastructure, and the permissions themselves through User Profiles.
An Admin sees everything a Super-Admin sees, but what they may change is governed by their own profile. They cannot modify global settings, system services, or Super-Admin configuration, and they have no access to user data.
Super-Admin
Unrestricted authority over the system, and the only role that bypasses permission checks.
Day to day they hold deployment settings, system services, and global configuration, and they execute escrow orders signed by the Site Key Admin. They can promote or demote any account, including other Super-Admins.
Deployments typically keep only two or three, enough for redundancy without spreading unrestricted authority. Even here the boundary holds: a Super-Admin still cannot read user data.
Escrow User
A recovery participant rather than a tiCrypt user. Escrow Users operate outside the main system with a separate login.
Day to day they do nothing. They are called on only when a key must be recovered.
They are organized into escrow groups, at least three per deployment. Each group holds one key part of the recovery key, and every member of a group holds that same part, so recovery needs one member from each group rather than several from one. Administrators can require escrow on an account but take no part in the recovery itself.
Site Key Admin
An offline certification authority, one per deployment, operating entirely outside tiCrypt.
Day to day they sign escrow user certificates, escrow group certificates, and deletion requests.
The site key must be countersigned by Tera Insights before it can be used. The Site Key Admin manages no users and holds no tiCrypt account.
Related Pages
- Institutional Role Mapping: how positions such as PI, Lab Manager, or Graduate Researcher map onto these roles.
- VM Roles and Permissions: the separate VM roles that apply inside a machine and take precedence over system permissions.