Find inactive users in Entra by last sign-in (and what it saves)

Inactive accounts are a double problem: they cost money in licenses and they widen your attack surface. The good news is that Entra ID records exactly when someone last signed in. That lives in the signInActivity field. This article shows how to find inactive users, where the catches are, and what it saves.

TL;DR

• Entra ID records each user's last sign-in in signInActivity.
• With it you find accounts that have not signed in for 60, 90, or 180 days.
• Note: the field requires Microsoft Entra ID P1 and has up to roughly 24 hours of delay.
• Inactive accounts are both a license cost and a security risk.
• For 500 users with 12 percent inactive, you are quickly looking at tens of thousands of euros per year.

Why inactive accounts matter

An account that has not been used for months falls into two categories, and both cost you something.

It costs money. If the account holds a paid license, you are paying for a seat nobody uses. At larger numbers that adds up fast.

It is a risk. A forgotten account with valid rights is an ideal target. Nobody watches it, so a misused account goes unnoticed for a long time. Fewer dormant accounts means fewer places where an attacker can get in without anyone noticing.

What signInActivity records

The signInActivity object in Entra ID contains several dates per user. The three you need:

Field	Meaning
lastSignInDateTime	Last interactive sign-in (the user does something themselves)
lastNonInteractiveSignInDateTime	Last sign-in on behalf of the user, for example a token refresh
lastSuccessfulSignInDateTime	Last successful sign-in

To find genuinely inactive accounts you look at the most recent of these dates. An account that is quiet interactively but still refreshing tokens non-interactively is probably still using a service, so it is not truly inactive.

Two catches

Before you build on this, two things people often overlook.

You need P1. The signInActivity property through Microsoft Graph requires a Microsoft Entra ID P1 license in your tenant. Without P1, Graph does not return the field and the column stays empty. Check your licenses before you start; P1 ships with many Microsoft 365 plans.

The data is not real time. Microsoft documents a delay of up to roughly 24 hours before a sign-in becomes visible in this field. For finding accounts that have been quiet for 90 days, that makes no difference. But do not expect a sign-in from this morning to be in there yet.

The approach

A workable order:

1. Pull all users through Graph, including signInActivity.
2. Set your threshold: 60, 90, or 180 days, depending on how strict you want to be.
3. Filter for accounts whose most recent sign-in is older than the threshold.
4. Exclude service accounts and intentionally dormant accounts on an exception list.
5. Split the list: accounts with a paid license (license win) and accounts without (mostly a security cleanup).
6. Review the list with the manager or HR contact before you disable anything.

Which threshold? 90 days is a good default: long enough to cover leave and sabbaticals, short enough to see quick results. For a stricter security cleanup you can go to 60 days, for a cautious one to 180.

What it saves

Finding inactive accounts has two kinds of payoff.

The license payoff is directly calculable. As an illustration, say 500 users on E3 (roughly 420 euros per user per year at current list pricing), with 12 percent inactive. That is 60 accounts. If you reclaim those licenses or do not renew them, that saves around 25,000 euros per year. Your own inactive share and per-seat price will differ, so treat this as a worked example, not a promise.

The security payoff is harder to put in money but at least as important. Every disabled dormant account is one fewer target and one fewer place where old rights linger.

From finding to cleaning up

A found inactive account does not automatically mean delete. The chain:

• Account with a license and genuinely no longer needed: reclaim or downgrade the license, disable the account per your process.
• Account without a license but with rights: disable it to shrink the attack surface.
• Borderline case: check with the manager before you do anything.

The actual license change happens in Microsoft. ServiceChanger reads the sign-in activity, compares it against your assigned seats and contracts, and provides the list plus the recommendation. You keep the decision.

FAQ

Do I really need P1 to do this? For the signInActivity property through Graph, yes. Many organizations already have P1 through their Microsoft 365 subscription. Check your license overview before you treat this as a blocker.

How do I handle service accounts? Put them on a fixed exception list. Service accounts often do not sign in interactively and would otherwise show up as inactive incorrectly.

Does ServiceChanger disable the accounts automatically? No. ServiceChanger finds the inactive accounts and reports what you can reclaim or clean up. The actual change stays a deliberate action in Microsoft.

How often should I run this? Finding them monthly works well. That keeps you close to your real situation without searching by hand every week.

Inactive accounts are often the first step toward lower license costs. For how to turn that into a standing policy, read Reclaim unused Microsoft 365 licenses with Entra sign-in activity. For broader license management there is Manage Microsoft 365 licenses.

Next step

Want to know which accounts in your tenant have been quiet for months, and what that costs in licenses? ServiceChanger reads the real sign-in activity from Entra ID and turns it into a concrete list. Book a demo or read the license docs.