Inactive and never-redeemed guests: detect, disable, delete
Every project with a partner leaves guest accounts behind. Years later, they still have access to the teams, sites and applications they were added to. Cleaning up guests is simple, provided it becomes a process rather than a one-off exercise.
Why dormant guests are a problem
An inactive guest account keeps its memberships and rights. Its authentication depends on the home tenant or the guest's mailbox, which you do not control: if the partner's employee has left and the account has been taken over, or their personal email is compromised, access to your data follows. Never-redeemed invitations carry another risk: depending on configuration, the invitation link can be used by whoever gets hold of the message.
The available data
Microsoft Graph exposes several useful properties on guest users:
signInActivity: dates of the last interactive sign-in, last non-interactive sign-in and last successful sign-in. Reading it requires audit permissions and an Entra ID P1 licence or higher; check the current Microsoft documentation;externalUserState: whether the invitation is pending acceptance or accepted, with the date of the last state change;createdDateTime: to tell a recent guest who has not yet signed in from an abandoned account;- Sponsors: when set, they identify the internal person responsible for the guest.
Missing data. An empty last sign-in value does not always mean "never signed in": history is not unlimited, and some access does not generate a sign-in in your tenant. Cross-check with the creation date and invitation state before drawing conclusions.
Setting clear rules
Before automating anything, agree thresholds with the business. For example:
| Situation | Proposed action |
|---|---|
| Invitation pending for more than 30 days | Delete the guest |
| No sign-in for 90 days | Notify the sponsor, then disable |
| Account disabled for 30 days with no objection | Delete |
These durations are only examples; adjust them to your project cycles. What matters is that they are written down and applied consistently.
Automating the process
- A scheduled script, for example an automation using a managed identity with read permissions on users and logs, extracts guests and calculates their inactivity;
- Sponsors or owners of the relevant teams receive the list of guests to confirm;
- Unconfirmed accounts are disabled, which is reversible;
- After the grace period, they are deleted. A deleted user can be restored for 30 days;
- Every run is logged for traceability.
If you have Entra ID Governance, access reviews can target guests, including across all Microsoft 365 groups, and automatically apply a deny outcome to guests who are not confirmed. Keep the rights of the identity performing deletions to a minimum: the ability to delete users is sensitive.
Addressing the root cause
Clean-up is pointless if guests pile up again. Pair it with a mandatory sponsor at creation, access packages with expiry where possible, and external collaboration settings that limit who can invite. In the tenants we audit, the share of guests who have never signed in is often the first sign that governance is missing.
What an audit checks
- The number of guests inactive beyond the agreed threshold, and of never-redeemed invitations.
- Dormant guests holding sensitive memberships or directory roles.
- Whether a documented, automated clean-up process exists.
- The presence of sponsors and access reviews for guests.