Respond to a lost device

An employee reports that they left their laptop on the train; it has a personal key in Excel and an Access application with the ODBC driver set up. They still have their phone with the authenticator app. Access from this laptop should end immediately, the rest of their work shouldn't.

Depending on what's lost, you withdraw more or less. Everything takes effect with the next request, without a restart.

1. Find the device's key: PersonalKeys with $filter=Person eq 'Erika Muster'; the label (for example “Private laptop”) and “last used” with its origin show which one it is.
2. Revoke: PATCH /admin/v1/odata/PersonalKeys('k…') with { "Revoked": true } and the version read in If-Match. A revocation can't be lifted.
3. End sessions: read SessionTokens with $filter=Person eq 'Erika Muster' and Revoked eq false and set { "Revoked": true } on each session. This also ends a code still valid on the laptop.
4. Phone lost: reset-totp with { "person": "Erika Muster" }; the person sets up the factor again at the next sign-in.
5. Check: An attempt with the revoked key appears in SignInEvents with Outcome = refused and Reason = revoked. If it comes from an unknown origin, that's a hint of misuse.

Result: The laptop reaches nothing anymore; the company PC and the person's other keys keep working.

• Data on the device—an Excel file, an Access database with copies—is beyond the service's reach. Whether it's encrypted is up to device management.
• One key per device keeps this case small: you revoke one key instead of all.
• Every step is in the change log with actor and time.

• Admit private devices
• Check sign-in patterns and origins
• Zero Trust and private devices