The Phone That Left With The Storekeeper
Somebody leaves on Friday. Four separate things still connect their handset to your system, they are revoked in four different places, and one of them has no button at all. Here is the actual offboarding sequence.
Offboarding is usually written down as one line — disable the account — and that line is usually enough. The reason it is worth going past it is that a phone accumulates more than one connection to a system over a couple of years, those connections are made at different times for different reasons, and they do not all end together.
This is not a story about a dishonest employee. The far more common version is a phone that was lost, sold, or handed down to a relative, by somebody who still works for you and thought nothing of it. The connections outlive the handset just as easily as they outlive the employment.
So the useful thing to know is what those connections actually are, because you cannot remove what you have not enumerated.
The four connections
| What it is | What it lets the handset do | Where it ends |
|---|---|---|
| An open session | Stay signed in without a password | Terminated individually, or all of a person's at once |
| A trusted device record | Be recognised as a known device | Locked, or revoked |
| A biometric enrolment | Sign in with the phone's own unlock instead of typing a password | Revoked separately, from its own list |
| A push registration | Receive your organisation's notifications | Nowhere on this screen |
The first three all have controls. The fourth is listed and counted on the same screen as the other three, and there is no action to remove it.
That is worth being direct about rather than burying, and worth understanding correctly. It does not mean somebody can read your data. A push registration is an address a message can be delivered to, not a key that opens anything — a phone holding one cannot sign in, cannot open a record and cannot make a request. What it can do is keep receiving notifications addressed to the organisation, and notification text says things like which order was approved and which customer is overdue.
A push registration is an address, not a key. It cannot open anything. It can keep receiving the messages you send to everybody.
What to actually do about it today
Two things, and neither needs a developer. First, disable the user account as your primary control — that is the one action that ends the ability to sign in, and it is what your offboarding checklist should already say. Second, treat the content of push notifications as something that could reach a former handset, which mostly means not putting figures or customer names in the notification body where the title alone would do. If a specific registration needs removing, it is a straightforward request to make of your administrator through the support channel rather than something to work around.
Lock or revoke, and why there are two
Both stop the device being trusted and both immediately end every session bound to it — the handset is signed out within seconds, not at the next check.
The difference is what you are saying about the future.
Lock
- Sessions on that device end immediately
- The device stops being trusted
- Stamped with the moment it was locked
- Restoring it is one action, and clears the mark
- For "something looks wrong and I want to stop it while I find out"
Revoke
- Sessions on that device end immediately
- The device stops being trusted
- Stamped with the moment it was revoked
- Restoring it is technically the same one action
- For "this device is not coming back"
Mechanically they do the same thing, and either can be undone. The distinction is a record of intent rather than a difference in effect, and that is fine — but it means the safety of the choice is in your process rather than in the system. Nothing stops somebody restoring a revoked device as easily as an accidentally locked one.
Note also that both are scoped to the device. Locking somebody's phone does not touch the session they have open on the office desktop. If what you want is to end everything that person has open everywhere, that is the separate action for terminating all of a user's sessions.
The biometric enrolment is the one people forget
Signing in with a fingerprint or a face on a phone does not send that fingerprint anywhere. What it does is unlock a credential the phone is already holding, which is then presented instead of a password.
The consequence that matters for offboarding: that credential is a separate long-lived thing from a session. Ending sessions does not end it. Locking the device does not delete it. It sits in its own list, with its own record of when it was created and when it was last used, and it is removed by its own action.
The list showing when each enrolment was last used is more useful than it first appears. An enrolment created eighteen months ago and last used eleven months ago is almost certainly a phone that is no longer in service, and clearing those out periodically is a five-minute job that removes a category of risk nobody is tracking.
Sessions, and the one thing to check first
Active sessions are listed and can be ended one at a time or all at once for a person. Ending a session is immediate — it is removed rather than marked, so there is no window in which it still works.
The reason to look at the session list before anything else in an incident is that it is the only one of the four that tells you about right now. A trusted device tells you a handset was registered. An enrolment tells you a credential exists. A session tells you somebody is signed in at this moment, and where from.
-
Open the session list first
It answers the only urgent question — is anybody signed in on this right now — and it is the fastest thing to act on.
-
End that person's sessions
All of them, not the one you are worried about, because you are rarely certain which device you are looking at from a session row alone.
-
Lock or revoke the device
This stops it being trusted going forward and ends anything bound to it that you missed.
-
Remove the biometric enrolment
Separate list, separate action, and the step most commonly skipped because the other three feel like they finished the job.
-
Disable the user account
The control that covers everything at once and does not depend on you having enumerated devices correctly. If you only do one thing, do this one.
The order is deliberate. The first four are precise and depend on you having identified the right rows. The fifth is blunt and does not. In an actual incident, do the fifth first and the rest afterwards.
The screen is worth opening when nothing is wrong
Everything above is the incident use. The routine use is more valuable and takes less time, because the summary counts on that screen tell you things about your operation that nobody reports.
- More trusted devices than people is normal after two years and worth pruning once a year — old handsets, replaced phones, a device registered from a laptop nobody has seen since.
- A biometric enrolment last used many months ago is a phone that has probably left the building.
- A count of push registrations far above your headcount is the accumulation described earlier, and is the clearest signal of it.
- Active sessions at three in the morning are either a genuine night shift or a question worth asking.
- Someone with far more devices than colleagues in the same role usually has a practical explanation, and occasionally has an interesting one.
Both viewing and acting are permissioned separately, which is the right split — a security lead or an internal auditor can be given the ability to look at all of this without the ability to lock anybody out.
What AWRA OpsHub does today
- One screen showing four things at once — trusted devices, active sessions, biometric enrolments and mobile push registrations, with counts for each.
- Lock and revoke on a device, both of which immediately delete the sessions bound to that device rather than marking them for later.
- Terminate one session, or every session a person has, taking effect at once.
- Revoke a biometric enrolment, from its own list, with the created and last-used dates visible so stale ones are identifiable.
- Separate permissions for viewing and for acting, so oversight can be granted without control.
- Search across all four lists by device label, address, platform, model, name or email.
What it does not do
- A mobile push registration cannot be removed from this screen. It is listed and counted; there is no action for it. A handset that has left keeps receiving organisation notifications until that record is cleared by other means. It cannot sign in, open a record or make a request — but it can keep receiving what you send.
- Lock and revoke do the same thing. The distinction is a record of intent, not a difference in effect, and either can be undone as easily as the other.
- No alerts. A new device appearing, an unusual sign-in location, a burst of sessions — nothing notifies anybody. The screen has to be opened.
- No automatic expiry of unused trust. A device trusted three years ago and untouched since is still trusted. Pruning is manual.
- Revoking a device does not remove that person's biometric enrolment. They are separate records with separate actions, and the offboarding sequence has to do both.
Not ours, by choice
- We will not remove a device or end a session on somebody's behalf as a routine support action. The permission for it exists inside your organisation deliberately — an outside party who can sign your staff out is a bigger risk than the one it solves.
- We will not describe a push registration as more dangerous than it is in order to make the gap sound urgent. It is an address, not a key. Stating it accurately is the point of writing it down at all.
Removing a push registration from the device trust screen, alerting on a new device, and expiring trust that has gone unused for a set period, are all scope rather than ceilings — the records, the screen and the notification infrastructure all exist.
The single most useful habit here is an annual prune. Open the screen, work down the trusted device list, and remove anything last seen more than a year ago. It takes twenty minutes, it needs no judgement, and it is the only thing on this page that reliably does not happen unless somebody puts it in a calendar.
Where this sits in a leaver process
The device half of offboarding
- Disable the user account. Everything else is refinement; this is the control.
- End all of that person's sessions rather than the one you can see.
- Revoke their trusted devices, which also ends anything still bound to them.
- Remove their biometric enrolment — the separate list, and the step most often missed.
- Note that a push registration may persist, and keep it in mind for what your notifications say rather than treating it as an open door.
- If they had a company handset, do all of the above regardless of whether the handset came back, because a returned phone tells you nothing about what was signed in on it.
The wider security picture is in the security and compliance page, the attendance side of device registration in the QR that changes every thirty seconds, and offline devices carrying unsynced work in the device that has not phoned home.
Our take
Disabling the account is the control, and everything on the device trust screen is refinement on top of it — do that first and the rest at your own pace. The refinement worth doing is the biometric enrolment, because it survives everything else and is the step people skip. Put an annual device prune in a calendar. And know that a push registration outlives the person, which is a reason to keep notification text plain rather than a reason to worry about the data behind it.
See device trust
Trusted devices, live sessions, biometric enrolments and push registrations on one screen, with locking, revocation and session termination that take effect immediately.
Explore securityFrequently asked questions
What is the fastest way to cut off a lost phone?
Disable the user account. It is blunt, it does not depend on you having identified the right device row, and it ends the ability to sign in outright. Then, at your own pace, end that person's sessions, revoke the device and remove their biometric enrolment. In an incident the order matters: do the blunt thing first and the precise things afterwards, because the precise things all require you to be looking at the correct record and you are rarely certain of that in the first five minutes.
What is the difference between locking and revoking a device?
In effect, nothing — both stop the device being trusted and both immediately delete every session bound to it. Each is stamped with the moment it happened, and either can be undone by restoring the device. The difference is what you are recording about your intent: locked reads as "stopping this while I find out", revoked reads as "this is not coming back". Because the safety is in your process rather than in the system, be clear internally about who may restore a revoked device.
Does revoking a device remove their fingerprint sign-in?
No, and this is the step most commonly missed. A biometric enrolment is a separate long-lived credential in its own list with its own removal action. Ending sessions does not touch it and locking the device does not delete it. If somebody has left, remove the enrolment explicitly. The list shows when each was created and last used, which also makes it easy to spot enrolments belonging to phones that went out of service months ago.
Can a former employee still receive our notifications?
Their handset can, until the push registration is cleared, and there is no action on the device trust screen that clears it. Be accurate about what that means: a push registration is a delivery address, not a credential. The phone cannot sign in, open a record or make any request. What it can do is receive notifications sent to the organisation. The practical response is to disable the account as your control, and to keep notification text plain — a title that says an order was approved rather than a body carrying the customer and the amount.
Will we be told if a new device signs in?
No. Nothing alerts on a new device, an unusual location or a burst of sessions. The screen shows all of it and has to be opened. That makes a routine worth more here than it does in most places: an annual prune of devices last seen over a year ago, and a look at biometric enrolments last used months ago, catches the accumulation that no notification is going to bring to you.
Who should be able to see this screen?
Viewing and acting are permissioned separately, which is worth using. A security lead, an internal auditor or a senior operations manager can be given the ability to see every device, session and enrolment without the ability to lock anybody out — useful for oversight, and useful for the annual prune, which is a reading exercise that only occasionally needs an action. Keep the acting permission narrow, because it can sign your own people out.
