Revoke a platform admin's access
Use this procedure when a Novalien staff member leaves the platform-admin roster — voluntary departure, role change out of on-call, or suspected compromise. Platform admin access spans every customer org (via scoped impersonation), so revocation is higher-stakes than revoking a normal user. This page covers the product-side revocation; adjacent systems (Slack, PagerDuty, VPN, 1Password) are listed because a platform admin with partial access is more dangerous than one with none.
Procedure
-
Get approval from at least one other platform admin. Paste the revocation request, the reason (departure/role-change/compromise), and the target email into
#novavms-platform-ops. Wait for an ack from another platform admin. Self-revocation is allowed only for the compromise case and still requires the ack before the disable call. -
Set
disabled_aton the platform_users row. Under your own platform JWT:Terminal window curl -X PATCH https://novavms.novalien.com/api/v1/platform/users/<id>/disable \-H "Authorization: Bearer $PLATFORM_JWT" \-d '{"reason":"offboarding ticket=<id>"}'This call (per
prd-platform-admin.mdUS-PLAT-2) also revokes every active impersonation session the target had open. Sessions in flight return401 IMPERSONATION_REVOKEDon the next request.
- Rotate 2FA. Even with the account disabled, a leaked TOTP seed or hardware key should not persist. Use the admin-account console to clear the enrolled factors; the target cannot re-enrol because the account is disabled.
-
Remove from adjacent systems. All four in the same session:
- Slack: remove from
#novavms-incidents,#novavms-platform-ops, demote to single-channel guest or deactivate. - PagerDuty: remove from every on-call rotation and every escalation policy they appear in.
- VPN (Tailscale): tag their node
disabled, expire the node key. - 1Password: remove from the
novavms-platform-opsvault and the shared-secrets vault.
- Slack: remove from
-
Hand over on-call duties if the target was an active responder. See Hand over on-call — do this in the same session, not later.
-
Audit check. Verify both of these exist in
platform_audit_log:platform.user_disabledwith the reason and ticket_ref.- One
platform.impersonation_endedper session revoked in step 2, each withrevoke_reason = "platform_user_disabled".
Common variations
- Suspected compromise, not clean departure: run this procedure first, then escalate to security. Do not wait for full forensic confirmation — revoke first, investigate after. The audit trail survives the disable.
- Temporary suspension (medical leave, investigation): use the same disable call. Re-enable when the suspension ends. The enrolled 2FA must be re-added, not restored — there is no partial-disable mode.
- Account owned the last
allow_platform_impersonationsession for an org mid-investigation: the disable revokes that session too. If Legal needs the impersonation to continue, a different platform admin must mint a fresh token before step 2.
Related
- Scoped impersonation — what you are revoking.
- Hand over on-call — the rotation-side companion to this page.
- Audit log investigation — if the reason for revocation is suspected misuse and you need the trail.