Auditing forgotten guest accounts

Guest accounts rarely arrive as a project. They accumulate one invitation at a time: a partner, a consultant, an acquisition, a temporary collaborator. The uncomfortable question is not whether guests are useful. It is whether you can name the external people still represented in a tenant, explain why each relationship remains open, and identify the person responsible for it.

Start with an inventory, not a deletion job. A reporting view lets an IT admin or MSP see every external identity before changing a single account. GraphPaaS reports that view per tenant; it does not write back to the tenant.

What counts as a guest in the first place?

A defensible list starts with the directory’s userType property, not with a display name, email suffix, or a guest-looking UPN. Microsoft defines the values as Member and Guest; the property must be explicitly selected and supports an eq filter.

GET /users?$select=displayName,companyName,userType,creationType,externalUserState,externalUserStateChangeDateTime,signInActivity&$filter=userType eq 'Guest'

Use companyName, creationType, and externalUserState to make the list useful. companyName can describe where a guest comes from; creationType distinguishes routes such as an invitation or self-service creation; and invitation-created guests can show PendingAcceptance or Accepted. Self-service sign-up through user flows can create guest accounts too.

For the “invited by whom?” question, add an invite-owner column from the invitation or audit context your team trusts. Do not fill it from a guess based on the guest’s name. The directory identifies the external identity; your process must identify the business relationship.

Can I just sort by last sign-in?

No. signInActivity is a useful signal, but not an all-purpose verdict. It requires Microsoft Entra ID P1 or P2 and AuditLog.Read.All; it is not returned for a user who never signed in or whose last sign-in was before April 2020. Treat an empty value as something to classify, not proof that an account is safe to remove.

Diagram · interpreting an empty sign-in activity value

Why is a guest easy to forget?

Because a guest can be absent from the places people casually look. Microsoft notes that guest objects are not visible in the Exchange global address list by default. “I cannot find them in the address book” is therefore not evidence that the identity has gone away.

Keep identity existence, invitation state, relationship ownership, and resource access as separate questions. A guest inventory establishes the population. It does not itself prove that every file, team, project, or administrative relationship is still justified. That separation is how you spot access creep instead of merely counting old names.

Who can create the next forgotten account?

By default, all users in an organization, including existing B2B guests, can invite external users. The external collaboration settings can narrow this to member users or specified administrative roles, or turn guest invitations off. They can also apply domain allow or block rules.

Audit the feeder paths alongside the old list: who may invite, which partner domains are expected, and whether self-service sign-up belongs in the tenant’s collaboration model. Otherwise, cleanup becomes a recurring exercise in emptying a bucket while the tap stays open.

Does a restricted guest setting cure access creep?

No. It is a directory-exposure choice, not a business decision about every relationship. Microsoft provides three guest permission levels: the same permissions as members, limited access by default, and restricted access. The limited setting still allows guests to see membership of non-hidden groups; restricted access limits them to their own profile and removes group-membership visibility.

Use that setting deliberately, but do not mistake it for recertification. The useful audit question remains: which internal person is prepared to say this external relationship should continue? If nobody can answer, the guest belongs in a review queue regardless of how much directory information they can browse.

Should I automate cleanup before I count?

Not before you have a usable inventory. Microsoft’s inactive guest guidance uses a 90-day default inactivity threshold that can be changed. For a guest who never signed in, inactivity is calculated from creation date; the window also avoids treating a brand-new guest as stale before they had a chance to sign in. Its access-review pattern can block a user for 30 days and then remove them from the tenant.

Diagram · guest lifecycle and stale-account cleanup

The licensing boundary matters. Automated guest governance is not just a clever Graph query: the cleanup feature requires Entra ID Governance or Entra Suite, and guest governance licensing requires a linked Azure subscription and the Governance for guests add-on. Microsoft says enforcement began in January 2026 and billing is per reviewed guest, with no free tier; its example scans 10,000 guests but bills for the 240 found inactive.

That is precisely why the reporting layer still matters. GraphPaaS can give an MSP or IT team a tenant-by-tenant list to discuss now, including pending invitations and available sign-in signals, without writing changes. Visibility is valuable before remediation is licensed, approved, or automated.