# How to Detect Dormant Accounts Becoming Active

> Compare each successful sign-in with the previous success before updating history. Flag a gap that meets your inactivity threshold. Missing history or interrupted collection means unknown activity.

By Harvey Singh. Published Oct 19, 2026. Updated Oct 19, 2026.
Source: https://www.enscurex.com/blog/detect-dormant-accounts

## Key points

- Compare successful sign-ins before updating history. Failed attempts leave that history unchanged.
- Missing history or interrupted collection means unknown activity, not proven inactivity.
- Choose an inactivity threshold for the account's purpose. Ninety days is an example policy.
- Investigate the return and review retained access before deciding on containment.

## When does a returning account need an alert?

To detect dormant accounts becoming active, look for successful use after a defined inactivity window. An unused account is a posture concern; its return is a detection signal. Neither proves compromise.

Choose the window by account purpose. A 90-day threshold is an example policy. Seasonal contractors may return after longer breaks; emergency accounts may need alerts on any use. Microsoft's [inactive-account guidance](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-manage-inactive-user-accounts) says to consider legitimate absences, including vacations. Give exceptions an owner and a review date.

## Which timestamp should you use?

Use successful sign-ins, including relevant background access. Failed attempts must not reset the successful-use clock.

Microsoft Graph's [signInActivity reference](https://learn.microsoft.com/en-us/graph/api/resources/signinactivity?view=graph-rest-1.0) distinguishes these fields:

| Field | What it records |
|---|---|
| `lastSignInDateTime` | Latest interactive attempt, successful or failed |
| `lastNonInteractiveSignInDateTime` | Latest client attempt on the user's behalf, successful or failed |
| `lastSuccessfulSignInDateTime` | Latest successful interactive or non-interactive sign-in |

Microsoft does not backfill the successful-sign-in property. A blank value means unknown history. Check collection coverage and the guide's permissions and licensing requirements.

The admin-center sign-in tile can take up to 24 hours to update. For current investigations, follow its **See all sign-ins** link. Latest-value snapshots can miss intervening successes; retain events to reconstruct the sequence.

## How do you detect the gap without erasing it?

Compare the new success with the saved previous success before updating history. This is proposed pipeline logic, not a ready-made product rule.

1. Key history by tenant, source and stable account ID, keeping sources separate.
2. Route failed attempts to attempt monitoring. Leave the successful-use history unchanged.
3. Read the previous success and collection coverage. Missing history or interrupted collection means unknown activity: skip comparison and proceed to step 5.
4. With reliable coverage, compare event times. Alert when `gap >= threshold`; save both timestamps and that threshold.
5. After the decision, advance the saved success only if the event is newer.

![](/images/blog/detect-dormant-accounts/compare-first.jpg "Check history and coverage before comparing successes. Save the new success after the decision.")

Consider an illustrative contractor, Riley Adeyemi. A success on Jul 1, 2026, at 09:00 UTC precedes another on Oct 18 at 09:00 UTC. With continuous collection, the 109-day gap crosses the example 90-day threshold. An Oct 17 failed attempt changes nothing. If collection stopped during August, label the interval unknown until retained records establish coverage.

Process state changes serially per account and ignore duplicate deliveries for alerts. Use event time for gaps and ingestion time for delays.

Order successes within a chosen delay window. For older arrivals, reconstruct neighboring successes and reassess affected alerts. Never move the latest success backward. Disclose any limit that prevents reconstruction.

## What should you check before acting?

Confirm the return through a trusted manager or contact route outside the account under investigation. Check:

- Whether the account still has an owner and a reason to remain enabled.
- Whether the source address and device fit the expected return.
- Changes to roles, authentication methods or OAuth grants around the sign-in.
- What the account accessed afterward and what it can reach now.

Join related events through [correlation](/features/correlation-and-attack-chains). Preserve records and document containment decisions. Inactivity alone does not justify an automatic destructive response.

Before enabling alerts, replay Riley's example, a below-threshold gap and an exact-threshold gap. Test failures, missing history, collection outages, duplicates, late arrivals and simultaneous events. Confirm that renames preserve account IDs and similar names never share history.

## How does EnscureX connect detection with access review?

EnscureX products read and write a shared Identity Graph. Detect correlates related alerts into investigations. Its [guided response](/features/guided-response) supplies triage questions and escalation criteria. A detection does not automatically change your tenant.

Posture checks dormant accounts as standing [risk findings](/features/risk-findings). Govern puts last sign-in and usage beside [access-review decisions](/features/access-reviews). Denials run against the directory when the review closes, with failures reported per account.

Use the timeline to investigate the return, then review whether retained access still has a reason. For the wider model, see [what ITDR watches](/blog/what-is-itdr).

## Frequently asked questions

### Is reactivation the same as re-enabling an account?

No. Reactivation here means successful use after inactivity. Re-enabling changes whether an account can sign in. Track them separately.

### Can an account be dormant in one app but active elsewhere?

Yes. Keep directory authentication and application activity separate. A directory sign-in alone does not prove use of a particular app.

### Can today's last-sign-in value reveal past reactivations?

A latest timestamp cannot show the previous gap. Reconstruct it from retained events or earlier snapshots. Otherwise, begin collecting a baseline.

## Sources

- [Microsoft Graph, signInActivity resource type (updated Jul 5, 2025)](https://learn.microsoft.com/en-us/graph/api/resources/signinactivity?view=graph-rest-1.0)
- [Microsoft Entra, How to manage inactive user accounts](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-manage-inactive-user-accounts)