Repository navigation
Inactive guest identities are disabled or removed from the tenant not reporting correctly #1589
Description
We cleanup our inactive guest accounts monthly for anything older than 90 days.
The latest v2 Assessment is finding 12K+ inactive guest accounts. I skimmed the list provided and they are reporting a current active date.
Checking the lastSignInDateTime, lastNonInteractiveSignInDateTime, and lastSuccessfulSignInDateTime (The timestamp of the last truly successful interactive or non-interactive sign-in) I'm finding the lastSuccessfulSignInDateTime is not accurate for the guest user.
Example:
UserType : Guest
LastSignInDateTime : 1/26/2026 2:41:28 PM
LastNonInteractiveSignInDateTime : 10/6/2026 6:04:18 PM
LastSuccessfulSignInDateTime : 1/26/2026 2:41:31 PM
lastSuccessfulSignInDateTime should be the date of the LastNonInteractiveSignInDateTime but it is not.
For a Member user seems to be working as expected.
UserType : Member
LastSignInDateTime : 10/11/2026 8:39:00 PM
LastNonInteractiveSignInDateTime : 10/12/2026 4:59:46 AM
LastSuccessfulSignInDateTime : 10/12/2026 4:59:46 AM
Activity
astaykov commentedon Oct 12, 2026
I am confused, Is the test failing, or is the test showing wrong data or is the graph returning wrong data? What comparison did you do?
And, is the test result inaccurate in a way?
mgraceffa commentedon Oct 12, 2026
mgraceffa commentedon Oct 12, 2026
astaykov commentedon Oct 13, 2026
No need. I think I understand the issue. I will validate, resp. look at our reference tenant for reproducible evidence and come back if I need more info.
mgraceffa commentedon Oct 13, 2026
astaykov commentedon Oct 16, 2026
Oh, now I see your situation.
And that is actually correct handling of how the test is currently designed to assess inactive guests.
As per signInActivity logging behavior:
Consider a situation where you have a custom application that regularly polls some data on-behalf-of the user using an authorization it obtained years ago. The user never signed in again. The application still keeps polling data and keeps refreshing its own token. You will see updates of the non interactive sign-ins for as long as your app is alive, not as long as the user is actually using the app. Completely unrelated to the user activity. Same is if you have a web app that has endless session. The user might be coming back to the app, but the app will never ask the user to verify their identity again, for example - redirecting the user authenticate again. And while this might be a desired outcome, this is not what Zero Trust principle of verify explicitly recommends.
The Zero Trust Assessment evaluates not against a slight chance of infinite session, but against the Zero Trust Principles.
For what I can say, your quoted logs for the second guest show:
From these events, the only real user identity verification (Zero Trust Principle of verify explicitly) happened back in February. Based on that, Zero Trust assessment tool identifies that the controls you have applied in your tenant (and applications) do not follow the principles of Zero Trust and marks all those users as invalid as per Zero Trust Principles.