In short
Every handset, tablet and watch that has signed in to your account appears in your devices list, with the name it reported, the platform it runs, when it was first registered and when it was last seen. You can revoke any of them from any of the others, and revoking takes effect on our side immediately rather than waiting for that device to next connect.
The thing worth understanding before you touch anything is that this is a list of keys, not a list of phones. When a device is trusted, your account holds a small cryptographic key for it. Revoking does not remove the device from the list — it destroys that key and keeps the record. That single fact explains almost everything else on this page: why a revoked device still appears, why the biometric column can change without you changing a setting, and why the Enable Biometric switch in Settings cannot end a device’s access — only revoking it here does that.
On this page
- What the list is actually showing
- Reading a row
- Enable Biometric pauses; revoking ends
- Revoking a device
- Revoked is not banished
- Watches are bound under a stricter rule
- How signing in with a device key works
- What a device key does beyond signing in
- Symptoms, causes and fixes
- Things people commonly get wrong
What the list is actually showing
Most device lists in most products are inventories: a record that a particular phone once logged in, kept for your reference. This one is different in kind. It is the set of cryptographic keys your account will accept, and each row exists because a key was registered against it.
That is why the column telling you whether a device can use biometric sign-in is not stored anywhere as a setting. It is worked out at the moment you open the screen, by asking a single question of each row: does the account still hold a key for this device? If it does, the device shows as trusted. If it does not, it does not. Nothing separate is written down, so nothing can drift out of step with reality.
A useful way to read the screen: every row that shows as trusted is a credential that could sign in right now without a password. Every row that does not is a historical record.
Reading a row
Each device reports its own name and platform when it first binds, and those are what you see. A phone that calls itself something unhelpful will keep calling itself that; the name comes from the handset, not from us.
| What you see | What it means | Worth knowing |
|---|---|---|
| Name and platform | Reported by the device itself when it bound | Truncated if very long. A device that re-binds without sending a name keeps the name it already had rather than going blank |
| Registered | The first time this device was ever seen on the account | Never changes, even if the device is revoked and later bound again |
| Bound | When its current key was issued | This moves. A device that was revoked and re-trusted shows a fresh bound date against its original registered date |
| Last seen | The last time it successfully signed in with its key | Also drives the ordering of the list |
| This device | The handset you are looking at right now | Labeled and outlined in the app so you cannot revoke the wrong one by accident |
| Trusted for biometric | A key is held for this device | Calculated live, not stored |
The list is ordered with active devices first and revoked ones after them, each group newest-seen first. So the top of the list is always what can currently get in, and anything below the break is history.
Enable Biometric pauses; revoking ends
In your settings, Enable Biometric looks like it should be the control that puts a device on or off this list. It is only half of that. The first time it is switched on it generates a keypair on the handset, keeps the private half in the device’s secure storage where it never leaves, and registers the public half against your account — that is what creates a trusted row here.
Switching it off afterwards does not revoke anything. It pauses biometric sign-in and LinxyPass approvals on that handset, and the App asks you to confirm exactly that. The key stays in secure storage, the row stays trusted, and your session on the device continues. Switching it back on asks for your face or fingerprint and resumes with the same key: no new registration, no change to the bound date, nothing new in this list.
The consequence is the part people get backwards. A phone you have lost is not made safe by the switch having been off on it — the key is still there and still trusted. The only thing that ends a device’s access is Revoke on this screen, and that is what the rest of this page is about. The one time the switch does run the full set-up again is when the handset no longer holds a live key, because it was revoked here first.
Revoking a device
Any trusted device can revoke any other, and the current one can revoke itself. The app words the confirmation differently depending on which you have chosen, because the consequences are different: revoking another device is housekeeping, while revoking the one in your hand signs you out of it.
Revocation is recorded as your decision rather than an automatic one, which matters if you later ask us what happened to a device. It takes effect on our side at once. The revoked device is not notified and does not need to be reachable — there is nothing to deliver, because the thing that made it work has been erased from our side rather than switched off on its side.
Revoking is the right first move whenever a device is lost or stolen, and it is safe to do even if you are not sure. The cost of revoking a device you still have is that you sign in on it again. The cost of not revoking one you have lost is unbounded.
One quirk to be aware of: the request reports success whether or not it matched anything. If a device has already been revoked, or the identifier no longer corresponds to a row, you will still be told the device was revoked. Take the confirmation as meaning “that device is certainly not trusted” rather than “something was just changed.” Check the list afterwards if you want to see the result.
Revoked is not banished
Revoking a device does not blacklist it. If you revoke your tablet and then sign in on that same tablet tomorrow, it binds again: the revocation is cleared, a new key is issued, and it becomes your current device.
This is usually what you want — it is what makes revoking safe to do casually. But it means revocation is not a parental control and not a way to permanently retire a handset you are giving away. What actually protects you when you hand a device on is that the private key was destroyed, so the new owner has nothing to sign with; they would need your account credentials to bind it afresh, at which point the device is the least of your problems.
Watches are bound under a stricter rule
A watch cannot be bound to your account unless the watch itself has a passcode or screen lock set. If it has not, binding is refused outright with a message saying so, and no amount of retrying will change it until you set one.
The reasoning is specific and worth understanding, because it is the clearest illustration of what these keys are for. On a phone, each sensitive approval can be confirmed with a fresh fingerprint or face check. A watch cannot do that; what it offers instead is wrist presence — the assurance that it has been on your wrist continuously since you unlocked it. That assurance is produced by the passcode. Remove the passcode and the watch stops being able to tell whether it is on your wrist, at which point tapping approve on it proves only that somebody is holding it.
So the rule is not an arbitrary policy. Without a passcode a watch is a weaker credential than a phone, and it is refused rather than quietly accepted as an equal. This applies to Apple Watch and to Wear OS watches alike.
| Device | What proves it is you at approval time | Requirement to bind |
|---|---|---|
| Phone or tablet | A fresh biometric or device unlock per sensitive action | A valid device key |
| Watch | Wrist presence since unlock, not a per-approval check | A valid device key and a passcode set on the watch |
How signing in with a device key works
You do not need to follow this to use the feature, but it explains several of the messages you might see.
When a trusted device signs in, it does not send anything secret. It asks us for a one-time random challenge, signs that challenge with the private key held on the handset, and sends back the signature. We check the signature against the public half we hold. Nothing that could be replayed ever crosses the network.
Two of the refusals are deliberately worded differently, and the difference is informative. A device we have never held a key for is told it is not enrolled; a device whose key we destroyed is told it was revoked. If you revoked a handset and someone tries to use it, the message they see confirms that the revocation is what stopped them.
What a device key does beyond signing in
The same key is used to prove that a biometric check has just happened, which is a stronger claim than proving you are signed in. Being signed in tells us the session is yours. A fresh check tells us you are physically present right now.
That distinction is used for the actions where presence matters rather than identity: opening a Secure Mark, viewing the details of a connection, and opening a private conversation. Each is proved separately and for that thing specifically, so confirming your presence to open one connection does not silently unlock everything else on the device.
Symptoms, causes and fixes
| Symptom | Cause | Fix |
|---|---|---|
| A device I revoked is still in the list | Revoking erases the key and keeps the record on purpose | Nothing to fix. Check that it no longer shows as trusted |
| “Device revoked” when signing in | That device’s key was destroyed by a revoke from this screen — on this device or another one | Sign in normally once and it will bind again with a new key |
| “Device not enrolled” | No key has ever been registered for this handset | Sign in and turn on biometric to create one |
| A watch will not bind | No passcode or screen lock is set on the watch | Set one on the watch, then bind again |
| Biometric shows off although I did not change it | The column reflects whether a key is held; something revoked it | Turn it on again to issue a fresh key, and check the list for anything you did not do |
| Turning biometric off and on did not fix my problem | The switch only pauses and resumes the same key; it changes nothing on this list | If the device itself is the problem, revoke it here and sign in again to get a fresh key |
| Enable Biometric is off and you did not turn it off | This device was revoked from another device, replaced by a newer binding, or ended by recovery, and the switch was corrected to match | Turn it on. With no live key, the full set-up runs and the device is bound again |
| A registered date is much older than the bound date | The device was revoked and later trusted again | Expected. The record is telling you the handset is not new to the account |
| Adding a new device, and your other phone shows no request | Notifications are off on that phone, so the request did not arrive as a notification | Open the Linxy App on that phone. The request is waiting there; approve it within three minutes. Afterwards, turn on notifications when the app asks |
Things people commonly get wrong
If the app asks you to sign in again
If Linxy no longer accepts the sign-in saved on a device — for example the device was removed from your devices, or it still holds a sign-in from a much older version of the app — the app tells you: “Please sign in again. Your sign-in on this device has ended.” and opens the sign-in screen. Sign in with your email and password, or tap Add this device to my account and approve it from a device that is already signed in. Until you do, that device does not receive your notifications or calls.