Offboarding in tiCrypt: What Happens When Someone Leaves or Changes Role
Offboarding is how tiCrypt takes access away from a person: by deactivating their account, changing their role or permissions, removing them from a project, or deleting the account.
- The problem: students graduate, postdocs move on and staff move between studies. Access to CUI has to end when the decision is made, not when the person next logs out.
- Mechanism: each sign-in gives the person a server session that holds a copy of their role, permissions and projects. Every offboarding action ends or updates those sessions, not only the account.
- Deactivation: ends every session acting for the person at once: the web app, file transfers, the person's VMs and uploads into their inboxes. Open tabs log out and show the reason.
- Role and permission changes: end open sessions, so the person signs in again with the new rights.
- Leaving a project: takes the project out of open sessions at once.
- Automatic deactivation: the account locker deactivates accounts with no sign-in for 365 days by default, or past their expiration date. An identity system can deactivate accounts through the REST API.
- Who does what: your organization decides when someone leaves. Administrators deactivate accounts and change roles, administrators and Sub-admins who manage a project remove its members, and system administrators set the account locker.
- Availability: tiCrypt backend 3.16.1 (2 November 2026) and web app 2.18.3 (3 November 2026).
Why offboarding has to reach open sessions
A session is not an account. The account is the record in Management > Users: the person's role, permissions, state and memberships. A session is what the server issues when the person signs in, and it carries a copy of the account's role, permissions and projects as they were at that moment. The server checks each request against the session.
Because each session holds its own copy, changing the account alone would leave the sessions already issued as they were. tiCrypt therefore ends or updates the sessions too, every time a person loses access.
Several kinds of session can act for one person:
| Session | Held by |
|---|---|
| Sign-in session | The web app, wherever the person is signed in: a browser tab or tiCrypt Connect |
| Sub-session | File transfers between the Vault and a VM or the person's computer, which run in a sub-session of the sign-in |
| VM session | Each running VM the person owns, which has its own session with the server |
| Inbox upload session | Each upload that someone makes into one of the person's inboxes |
Each offboarding action treats them differently:
| Action | Open sessions | Open tabs | Next sign-in |
|---|---|---|---|
| Deactivate the account | All end, including those of VMs and inbox uploads | Log out at once and show the reason | Refused, with the reason |
| Change the role or permissions | All end, except inbox uploads | Show the lock screen at the next request | Carries the new rights |
| Remove from a project | Stay open, without that project | Keep working, without the project | Leaves the project out |
| Delete the account | All end, including those of VMs and inbox uploads | Show the lock screen at the next request | Refused |
Deactivation ends everything at once
To deactivate an account, an administrator selects it in Management > Users > Users, opens Open full menu > Change state, selects Inactive, enters a Reason for deactivation and clicks Deactivate. For more information, see Change State of User(s) from Management.
As soon as the change is saved, tiCrypt:
- Ends every session acting for the person: sign-in sessions, sub-sessions and temporary sessions, the sessions of the person's VMs, and inbox uploads. The server logs each session it ends.
- Fails any sign-in for the person that is still under way.
- Tells the person's open tabs, which log out. The login page then shows Account deactivated, for example: "You were logged out because your account has been deactivated. Details: Left the department on 31 October. Contact your administrator if you need access."
- Refuses new sessions for the account. A sign-in attempt shows "This account has been deactivated." with the same reason, and no new VM session, temporary session or inbox upload can be opened for the account either.
As a second safeguard, the web app checks once a minute that the signed-in account is still active, and logs out if it is not.
The Reason for deactivation appears in the Deactivation Reason column of the Users table and in the message the person reads on the login page. Write it for both readers.
Deactivation deletes nothing. The person's files, drives, VM configurations, and team and project memberships stay as they are, and setting the account back to Active lets the person sign in again.
Automatic and scripted deactivation
Not every deactivation starts in Change state. Each of these paths ends sessions in the same way:
| Path | What triggers it | What the person reads |
|---|---|---|
| Inactivity | The account locker finds no sign-in for 365 days, by default. It never locks Super-admins this way | "Too long since last login" |
| Expiration | The account locker finds the account past its expiration date, shown in the Expires column | "User deactivated because of expiration date" |
| REST API | A script or identity system calls POST /api/users/disable | "Disabled via API Token request" |
| Temporary deactivation | An administrator bars the account until a set date and time, through the server API | "This account is deactivated until", then the date |
The account locker is a task of the tiCrypt maintenance service, set in the account-locker section of ticrypt-maintenance.conf. It runs every 4 hours by default (frequency), and time-before-account-old sets the inactivity period. Setting an account to Active removes any expiration date it has, so the next run does not deactivate it again. For the settings, see Account Locker.
Role, permission and project changes
Changing a person's role or permissions, including applying a profile, ends their open sessions. Uploads into their inboxes are the exception: they read their permissions from the inbox on every request, so they continue. In an open tab, the next request to the server brings up the lock screen. Unlocking signs the person in again in full, and the new session carries the new role and permissions.
Removing a person from a project acts on that project alone. Deleting the membership in Management > Projects > Project Memberships takes the project out of every open session acting for the person, at once. They keep working, but resources tagged with the project are out of their reach. tiCrypt refuses to remove a membership while the person still belongs to one of the project's sub-projects, so remove those memberships first.
Memberships can also end on a date. At every sign-in, tiCrypt checks each of the person's project memberships and leaves a project out of the session when the membership has expired, or when the person lacks a certification that the project's security requirements call for, or holds only an expired one.
Deleting an account
Deleting an account (Delete, then Delete user) also ends every session acting for the person. Deletion does not remove the person's files, drives or VMs, or their team and project memberships, and the account stays restorable from Deleted Users for 365 days by default. Deactivate first, and delete later if your policy calls for it. For more information, see Delete a User from Management.
Who can take access away
Since backend 3.16.1, only Super-admins skip permission checks. An Admin needs the matching permission, like any other role:
| Action | Permission |
|---|---|
| Deactivate an account | Deactivate users with a lower role |
| Change a role | Lower the role of users with a lower role, or Raise the role of users with a lower role, up to their own role |
| Change permissions | Change the permissions of users with a lower role |
| Remove from a team | Remove users from any team |
| Remove from a project | Remove users from any project, or Remove users from projects they manage |
| Delete an account | Delete users with a lower role |
For the full list, see Permissions.
Offboarding from your identity system
Most institutions learn that someone has left from an HR or identity system, not from a tiCrypt screen. The REST API lets that system act on its own:
- Deactivate:
POST /api/users/disabletakes a list of user IDs and deactivates them, ending their sessions as above. It needs an API key of the User type with Full control. Super-admins cannot be deactivated this way. For more information, see Deactivate Users. - Compare:
GET /api/usersreturns each account's state and expiration date, for a scheduled comparison with HR records. A Read-only key is enough. For more information, see List Users.
API keys follow the person who created them. A key acts for the Super-admin who created it, and stops working when it expires or when that Super-admin is deleted, deactivated or no longer a Super-admin. Before an administrator who set up integrations leaves, check the Owner column in Management > Miscellaneous > API Keys, and have another Super-admin create replacement keys. For more information, see API Keys.
Reviewing who still has access
Not every departure gets reported. The Last Login and Expires columns of the Users table show accounts that have gone quiet or are about to lapse, and the table exports to CSV for a periodic access review. Since backend 3.16.1, anyone who can see a user also sees that user's last login in the user's details, so project managers can spot members who no longer sign in.
An offboarding checklist
When someone leaves:
- API keys: if the person is a Super-admin, replace the API keys they own first.
- Account: deactivate it with Change state > Inactive and a reason. Their sessions end at once.
- VMs: in the user's overlay (Open full menu > Open overlay), review Running VMs, and shut down the ones that should stop with the account from Running VMs.
- Memberships: remove the project memberships that should end, sub-projects first, and the team memberships.
- Deletion: delete the account later, if your policy calls for it.
When someone moves to another study or role, change their role, permissions or project memberships instead. Each change reaches their open sessions at once.
How this maps to CMMC Level 2 and NIST SP 800-171
| Requirement | What tiCrypt does | What your organization does |
|---|---|---|
| PS.L2-3.9.2: protect systems during and after personnel actions such as terminations and transfers | Ends every session at once on deactivation, and brings role, permission and project changes into open sessions | Decides who reports departures and transfers and how fast access must end, then acts on each one |
| AC.L2-3.1.11: terminate a user session after a defined condition | Ends sessions on deactivation, deletion, and role or permission changes, in addition to inactivity timeouts | Sets the session timeouts |
| IA.L2-3.5.6: disable identifiers after a defined period of inactivity | Deactivates accounts with no sign-in for a set period, through the account locker | Sets time-before-account-old to the period its policy defines |
| AC.L2-3.1.1: limit system access to authorized users | Refuses sign-in to inactive accounts, and to the VMs, inbox uploads and API keys acting for them | Reviews accounts, using Last Login and expiration dates |
In NIST SP 800-171 Rev. 3, the same ground is covered by 03.09.02, Personnel Termination and Transfer, and 03.01.01, Account Management, which also asks that expired accounts be disabled. PS.L2-3.9.2 remains your organization's responsibility: tiCrypt makes a deactivation take effect at once, but someone has to decide to deactivate. For the full split, see Shared Responsibility in Secure Compute.
Ending sessions on deactivation, deletion, and role, permission and project changes shipped in tiCrypt backend 3.16.1 on 2 November 2026. Logging open tabs out with the reason shipped in web app 2.18.3 on 3 November 2026. For the full lists of changes, see Backend 3.16.1 and Frontend 2.18.3.
Related documentation: User Management | Deleted Users | Project Memberships | Session Lock | Shared Responsibility in Secure Compute