Skip to main content

Recent sign-ins

Applies to: directory 0.27 · Checked: 26.09.2026

Recent sign-ins​

In the /me portal, the Security tab has a Recent sign-ins card: this account's sign-ins over the last 30 days, at most 50 entries. For each one it shows:

  • when;
  • how: password, password and code, recovery code, passkey (with or without PIN or biometric verification), company sign-in (ADFS or another provider), LDAP directory password, an LDAP bind from an application, an app password for mail;
  • into what: the application signed into, or the messenger, mail, LDAP;
  • from: the address the sign-in came from;
  • result: signed in, refused with a reason (wrong password, wrong code, account locked, address blocked and so on) or failed (directory unavailable).

The list is read from directory's security event log — the same one exported to the SIEM. A person sees only their own sign-ins. Error texts and secrets never reach the portal, only the class of the reason.

Next to the Sign out everywhere button it says: "Not you? Sign out everywhere and change your password."

The address is shown when whoever checks the sign-in passes it on: directory's sign-in page and LDAP server know it themselves, the coordinator passes it with a password check, mail with an app-password check.

A sign-in from a new device​

When the account signs in from a device it has not used in 90 days, the person gets a notice on their devices: "New sign-in to [application] from network 203.0.113.0/24 (Firefox on Windows) via password at [time] — not you? End sessions and change your password", with a link to the portal's Security tab. No city is named: no GeoIP database ships with the product, so the network is given instead.

A "device" is the combination of the application, the network (a /24 for IPv4, a /48 for IPv6) and the browser family when it is known. No cookies are used for it and no addresses are kept for it. There is no notice:

  • on the account's very first sign-in, or the first after 90 days without one — there is nothing to compare with;
  • on a sign-in from a known device;
  • more than once a day for the same device;
  • on a failed or unfinished sign-in (the password accepted, the code not yet entered).

Such a sign-in's row in Recent sign-ins is marked new device, with a This wasn't me button beside it: it ends every session and refresh token of the account, marks the device as not the person's and takes them to change the password. In the console, under Users → People, the same marker shows on the Sign-ins tab of the person's page.

An administrator turns the notices off in the console under Policies → Sign-in requirements → Tell a person about a sign-in from a new device, or with signin_alerts: off in the credential policy. They are on by default: only the person receives the notice, nothing about signing in changes, and after an upgrade each account's first sign-in only records its devices. The marker in the sign-in list stays when the notices are off.

LDAP binds and app-password sign-ins do not raise notices.

When applications lose access​

Since directory 0.44, an access token directory issued to an application (the /me portal, the console, company applications connected over OIDC) stops working at once, not when it expires (an hour by default), if after it was issued:

  • the person pressed Sign out everywhere or This wasn't me — except the portal's token they did it from: with it they change the password right away;
  • the help desk ended every session of the person, or an administrator pressed Sign out everyone — then none is left;
  • the person reset the password through Forgot password?, or the account was disabled or deleted.

The portal, the console and /oauth/userinfo check this themselves. An application that verifies a token by its signature alone (JWKS) does not see it until the token expires; to see it, it asks directory: POST /oauth/introspect (RFC 7662) with token=<the token>, the client authenticated as at /oauth/token (client_secret_basic or client_secret_post). Only a confidential client may ask, and only about its own tokens: for anybody else's, an unknown, a revoked or an expired one the answer is the same, {"active": false}. Discovery names the address as introspection_endpoint.

A person's addresses and the notices about them​

Since directory 0.45 the portal's Profile tab has a Your addresses card: the primary address (the account's), the organisation's other addresses (aliases — mail to them arrives in the same mailbox) and the personal address for sign-in codes with its state. GET /v1/me/addresses gives the same list for the settings screen in the apps.

When an address is added or removed, the person gets a notice in SimpleTwo on the devices they are signed in on — in their language, with the address masked and a link to the portal:

  • the organisation added or removed an alias;
  • the personal address for sign-in codes was confirmed or removed. While an address waits for its confirmation code there is no notice: it is not the person's address yet.

A notice, not a letter: a letter to the new address would be read by whoever added it. The audit log stays the record (alias.put, alias.delete, email_factor.verify, email_factor.remove).

Who may act for a person​

Directory grants no access to another person's mailbox or calendar. Mail and the calendar decide that themselves: access to a mailbox or a calendar is given to people and groups in their own settings.