Investigate Active Directory accounts with no logon in 90 days

Frame this document as a source-led configuration and assurance check: Investigate Active Directory accounts with no logon in 90 days. Only the official source and traced locations below supply facts. Confirm applicability before acting.

Source fact:

The official Accounts security posture assessments from Microsoft supports the following bounded statements:

• The stale-account recommendation lists Active Directory user accounts that have not logged in during the previous 90 days. The research record locates this support at Stale account recommendation description.
• The page says impacted entities can update within minutes after remediation while assessment scores and statuses update every 24 hours. The research record locates this support at Opening update-cadence note.

These statements are the factual basis for this document. Do not extend them into a broader assurance. Review directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking only where the source and recorded environment align.

What the source does not establish

A 90-day threshold is a detection criterion, not proof that an account lacks a valid owner, seasonal purpose, or recovery dependency. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners before translating the source into an operational decision.

Applicability questions

• For source statement 1 at Stale account recommendation description, which observable configuration, record, or test can confirm applicability here?
• For source statement 2 at Opening update-cadence note, which observable configuration, record, or test can confirm applicability here?
• Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance?
• How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners?
• Who approves the conclusion, exception, test window, and rollback threshold?

DSE recommendation:

DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation.

Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners. Handle credentials, keys, recovery data, and personal information through approved secure channels.

Verification and evidence

Keep the source locations Stale account recommendation description; Opening update-cadence note adjacent to the sanitized artifacts used for comparison. Prefer affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions, with enough identity and timing data for an independent recheck.

Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.

Official references

• Accounts security posture assessments — Microsoft