A dormant account is an account with no observed sign-in activity during the period being reviewed. If it remains enabled, an administrator needs to decide whether the access still serves a legitimate purpose. Lack of recent activity is a reason to investigate, not automatic proof that the account should be deleted.
Blue Lantern Security's daily identity scan flags enabled accounts with no sign-in for 90 days, or 30 days for administrators, in a connected Google Workspace or Microsoft Entra directory. Dormant administrators are critical findings because their access warrants closer review.
The practical goal is to turn each finding into a decision: keep the account for a documented reason, reduce its permissions, or remove access through the appropriate process.
1. What does a dormancy finding mean?
Open the latest successful Identity result in the Monitoring Hub. Use the dormancy filter to review the relevant checks, and inspect administrator findings first. The report's CSV export provides a roster you can use for the review; it includes the report's checks, so filter the exported data as needed.
Record the account, its admin status, the reported activity, and the scan time. Check whether the integration is healthy and has the necessary permissions before treating the result as current evidence.
For Microsoft 365, the documented optional identity checks require AuditLog.Read.All with admin consent, and dormancy requires an Entra ID P1 or P2 license. Google uses the directory scope in the existing organization integration. The identity monitoring guide covers setup and scope.
When investigating in the provider's own tools, pay attention to which timestamp you are reading. A last sign-in attempt can include failures and is different from a successful sign-in. Microsoft's inactive-account investigation guide explains the available activity fields and their limitations. Missing data also needs investigation; it should not silently become proof of inactivity.
2. Find the owner and the reason for access
Compare the account with employment, contractor, and system-ownership records. The account name alone may not explain who uses it or which process depends on it.
Ask the owner or manager whether the work still requires access. Common possibilities include:
| Situation | What to establish before acting |
|---|---|
| Former employee or completed contract | Confirm the departure and follow the offboarding process, including necessary information handover |
| Employee on extended leave | Check the approved access arrangement and who can authorize a change |
| Separate administrator account | Confirm the admin role remains necessary and whether privileges can be reduced |
| Emergency-access account | Verify the documented purpose, safeguards, owner, and testing procedure |
| Account supporting an automated process | Identify the process and its credentials or dependencies before disrupting access |
| Unrecognized account | Escalate to the directory owner and investigate its creation and permissions |
These are illustrative review outcomes, not exceptions the scan approves automatically. An emergency account, for example, should not be deleted just to remove a finding, but neither should its name excuse an undocumented access path.
3. What can the account still reach?
Check the permissions that make the account consequential: administrator roles, sensitive groups, shared resources, and connected business applications. If the person still works for the business but no longer needs administrative access, reducing that access may be the appropriate result.
Review application dependencies as well. A user account's lifecycle and an application's granted permissions are related but distinct. The IAM guide explains that distinction, and AI access monitoring helps review detected AI connections in the supported environment.
A directory inactivity scan does not establish that every application account, API credential, or workload identity has been reviewed. Record those as separate tasks where they matter.
4. Make and document the access decision
Have the authorized administrator apply the decision in Google Workspace, Microsoft Entra, or the affected application. Blue Lantern Security reports the finding; it does not automatically disable the account.
For an account that is no longer needed, separate removing access from deleting information. Confirm the required data handover and retention arrangements before deletion. Where supported and appropriate, suspension or disabling can restrict sign-in while the owner completes that work.
Also account for existing sessions and application-specific access. Disabling a directory account is not a universal guarantee that every application session ends immediately. Microsoft's access-revocation guidance explains why applications and their sessions may require additional action.
If there is evidence of compromise, use the incident-response process promptly. Routine dormancy cleanup and an active security incident need different timing and authority.
5. Verify the outcome
Check the change in the authoritative system, then review the next successful daily scan and its timestamp. Reporting delays or an unhealthy integration can affect when a change appears.
For an illustrative completed-contractor account, the review record might say: engagement ended, work transferred to the project owner, sign-in disabled, application access reviewed, and the later directory result checked. That explains the decision without relying on a dashboard status alone.
If the account is retained, record the reason, owner, safeguards, and next review date. Keep that decision in the business's review record; do not assume the monitoring platform provides a dedicated exception workflow.
Make the review repeatable
Act on known departures when they happen rather than waiting for a dormancy threshold. Use recurring scans to catch missed cleanup and periodically revisit retained exceptions. Administrator findings deserve timely review even when the wider account review is scheduled less often.
Include this work in the monthly cybersecurity checklist. Start by opening the latest Blue Lantern Security identity results and assigning an owner to each dormant account whose continued access you cannot explain.