Offboarding someone
What to do when a person leaves, in the order that closes access first and tidies up second.
Nothing you change on a member waits for their next sign-in. Their role and blocked state are read on every request, not cached in a session. With group propagation on, which is the default, a change to their groups also moves the devices they already have straight away.
What offboarding misses is what does not belong to the person: machines enrolled with an enrollment key, the enrollment keys themselves, and the access tokens of service accounts they used. Blocking or removing the member touches none of those. Close the person's own access first, then go through the rest deliberately.
The order that works
- 1
Block the member
On People → Members, switch on Blocked in their row, or open them and use Block user on Profile. It takes effect at once: every dashboard and API request they make is refused, including requests with their own access tokens, and every device they enrolled by signing in is expired and disconnected. The record stays, so you can work through the rest of this list calmly. The owner cannot be blocked until ownership has been transferred.
- 2
Account for machines they enrolled with a key
A device enrolled with an enrollment key has no owner and no session, so neither blocking nor removing the member reaches it. To find the ones this person set up, start from their keys. Open Activity, widen the date range and choose the person in the member filter: each Enrollment key created names a key they made. Under Devices, a machine enrolled with a key shows No email where other devices show their owner, and it starts out with the groups of its key. Decide each one: delete it, or keep it and check the Assigned groups on its page. Changing a key's auto-assigned groups now does not regroup the devices that key already enrolled.
- 3
Revoke the keys they could use
Under Access → Enrollment keys, choose Revoke on every key the person could read. A copied key stays valid until it is revoked, expires or reaches its usage limit. Revoking is permanent and only stops new enrolments: devices the key already enrolled stay, which is why they had a step of their own.
- 4
Rotate the service-account tokens they had access to
Removing a person deletes their own access tokens, not the tokens of a service account they used. For each one, create a new token, update the consumer, then delete the old token; see Service accounts and tokens.
- 5
Remove the member
On their Profile, under Remove from this organization, choose Remove member and confirm. This deletes every device they enrolled by signing in and all their access tokens, in one step. Their sign-in account is not deleted, so any other organization they belong to is unaffected. The owner cannot be removed until ownership has been transferred.
Machines they enrolled
A device enrolled by signing in has that person as its owner and goes when they are removed. A device enrolled with an enrollment key has no owner: a build server the person set up belongs to the organization, not to them, it never expires, and nothing you do to the member changes it.
That is the right behaviour, and it is also the gap people miss. Find these machines as step 2 describes and decide each one deliberately.
What limits the damage beforehand
Offboarding is easier when these were already set well:
- Device session expiry. Under Settings → Security, Expire device sessions is on by default with a Session length of 24 hours. A device enrolled by signing in has to sign in again when it runs out, so no machine keeps its access for long without its owner signing in.
- Group propagation. Enable user group propagation, under People → Groups → Settings, is on by default. It moves a member's existing devices along when their groups change; see Group propagation.
- Keys only where nobody signs in. Enrol people's machines by signing in and keep enrollment keys for servers, with a short Expires in, and reusable only where several machines need the same key. That keeps the list of ownerless machines short enough to review.
Neither session expiry nor propagation applies to key-enrolled machines, which is why those need the deliberate pass above.
How to tell it worked
Under People → Members the person is gone, and under Devices none of the machines they enrolled by signing in remains. For each key-enrolled machine you kept, check what it can still reach: open it under Devices and look at its Accessible devices tab.
The same list is available from the API. It holds devices only, not routes, resources or ports, and it includes devices that are offline. In the call below, DEVICE_ID is the device's id from GET /api/devices. Ask with an owner's or admin's access token: for a network admin, an auditor or a regular member, the call returns an empty list for any device that is not their own, so an empty answer from them proves nothing.
curl -sS "https://app.sxaccess.com/api/devices/$DEVICE_ID/reachable-devices" \ -H "Authorization: Token $SXACCESS_TOKEN"What Activity records
The Activity page records each step. Blocking appears as Member blocked, followed by Device login expired for every device it expired. Removal appears as Device deleted for each device that went with the member, and Member deleted for the membership. Revoked keys appear as Enrollment key revoked, and the service-account tokens you replaced as API token deleted. The event-type filter finds them quickly; see Activity log.