All insights
ProtectMicrosoft 365Explainer

Your tenant has a thousand forgotten guests: building a guest-expiry workflow that has exceptions

External-collaboration sprawl leaves SMBs with hundreds of guests who never lost access; a default auto-expiry with a ticket-based override cleans it up without cutting off real partners.

Wired CIOMay 18, 2026
The short version
  • Every external file share creates a guest account that almost nobody ever removes, so over years a tenant accumulates hundreds or thousands of stale external identities.
  • Set guest access to expire automatically after a fixed window, such as 180 days, and add a simple ticket that resets the clock when access is still legitimately needed.
  • Use Microsoft's sign-in logs to flag guests inactive for 30, 60, or 180 days, since anyone removed by mistake can simply be re-invited.
  • Share by named invitation rather than 'anyone with the link,' and build domain allow-lists so blocking consumer domains like Gmail doesn't break legitimate nonprofit collaboration.
Bottom line: A default-expire policy with a ticket-based exception turns years of guest sprawl into a self-maintaining cleanup that still keeps your real partners in.

Last month, while auditing a 550-person environmental-services firm, we found a familiar mess: hundreds of external guests with standing access to company files, some invited years ago and never seen since. As the IT lead put it, "I'm sure some of these were invited ten years ago and haven't accessed it in ten years."

External-collaboration sprawl is one of the quietest security gaps in a growing company, and it's very fixable.

Why it piles up

Every time someone shares a file with an outside partner, a vendor, or a client, a guest account gets created. Almost nobody ever removes them. Over years, that becomes hundreds or thousands of external identities, most of which haven't touched anything in ages, all still technically holding the keys to whatever they were given.

Default-deny, with an escape hatch

The fix isn't to nuke every guest, because a handful are real, long-term partners you collaborate with constantly. The fix is a policy with an exception built in:

  • Set guest access to expire automatically after a set window, say 180 days.
  • Build a simple ticket that resets the clock when access is still legitimately needed.

Now cleanup happens on its own, and the small set of partners who should stay, do.

Use evidence, not guesswork

Tie the cleanup to evidence, not guesswork. Microsoft's sign-in logs let you flag guests who haven't logged in for 30, 60, or 180 days and remove them after six months. Anyone removed by mistake can simply be re-invited, so the downside of being aggressive is tiny.

A few supporting moves

Blocking sharing to consumer domains (like personal Gmail) is good practice, but it needs exceptions, because a firm like this one legitimately shares with shoestring nonprofits running on Gmail. Build the allow-list so the policy doesn't break real work. It also helps to take away end users' ability to spin up new sites and guests at will, routing that through IT, which slows the sprawl at the source. And always share by named invitation rather than "anyone with the link," so every external party is an identity you can see and expire, not an anonymous door.

If you've been collaborating externally for years and never cleaned house, odds are your guest list is a lot longer than you'd guess. We can audit it and put a self-maintaining expiry process in place. Let's talk it through.

Filed under
Explainer
Read more insights
Free strategy session

See where you stand. Then move forward.

Book a free intro call. We'll talk through where you are today and map a strategic plan for growth, protection, automation, and alignment.

A 30-minute discovery call, no obligationA full team of specialists at a fraction of in-house costA clear next step before you spend a dollar
Loading scheduler…