Guest Accounts Need Expiration Dates

Guest accounts are useful because modern work crosses organizational boundaries. A contractor may need one Slack channel. A client may need a project room. A vendor may need a shared document folder. An outside developer may need access to a private GitHub repository. A volunteer moderator may need limited community tooling. The access is often legitimate, but it lives outside the normal employee lifecycle that identity teams understand best.

The control is not to avoid guests. The control is to make guest access temporary by default. Every guest should have a named sponsor, a business purpose, the smallest set of rooms and resources that match that purpose, a strong enough authentication path, an expiration date, a review cadence, and an offboarding checklist. If the work continues, the sponsor can renew it. If the work ends, access should not wait for someone to remember a months-old invitation.

Most access programs are built around employees. HR starts the identity lifecycle, SCIM or directory groups place the user into tools, and offboarding disables the account when employment ends. Guests do not always move through that path. They may authenticate with their own work identity, a personal address, an invited account, or a platform-specific collaborator profile. That flexibility is useful, but it makes ownership easier to lose.

Slack's guest roles are designed for people such as contractors, interns, and clients who need limited access to a workspace. Microsoft Entra B2B collaboration represents external partners as guest users in a tenant while letting them use their own credentials. GitHub outside collaborators are not organization members but can access one or more organization repositories. Those models are different, yet the security question is the same: who owns the continuing decision that this external person still needs access?

A guest should never be an orphaned account. The sponsor is the internal person who can explain why the guest exists, which resources they need, what work is expected, and when the relationship should end. Slack guest profiles can show which owner or admin invited the guest, which channels the guest can access, and whether a time limit is set. Microsoft Entra external collaboration settings let organizations control who can invite external users and can restrict invitations by role or domain.

The sponsor model prevents a common failure: everyone assumes someone else owns the account. A community manager invites a vendor. The vendor changes personnel. The internal project lead leaves. The guest keeps access because no one is clearly accountable. Sponsors should be reviewed in the same workflow as guests. If the sponsor leaves, the guest account should be reassigned or removed.

Expiration is not administrative cleanup. It is a security boundary. Slack lets workspace owners and admins set automatic guest deactivation after a certain amount of time, choose a custom deactivation date, or allow indefinite access. The existence of an indefinite option does not make it a good default. Short projects, support cases, audits, partner reviews, trials, and temporary moderation work should start with an end date.

Microsoft Entra access reviews are built for this problem: periodically confirm whether users, including guests, should retain access to groups, applications, or privileged assignments. Smaller organizations can run a simpler version with spreadsheets or tickets, but the control should be the same. A renewal should require a live sponsor and a current purpose. If no one can defend the access, the guest should be removed.

Guest scope is broader than a single account flag. In Slack, a single-channel guest and a multi-channel guest have different reach, but channel membership is not the whole story. Guests may be able to see message and file history in channels they can access, start direct messages with people in the same channels, use some workflows, or interact with apps depending on workspace policy. Changing a guest's channels may not erase data they already saw.

The same pattern appears outside chat. Google Workspace admins can control external sharing for Drive and Docs, but a shared file link may outlive a project if it is not reviewed. GitHub outside collaborators can be granted repository access, and GitHub warns that when a private repository collaborator is removed, local clones can still exist. Scope decisions should list every surface the work requires: chat rooms, shared drives, repositories, issue trackers, calendars, support queues, dashboards, bots, and workflow tools.

A guest using their own credentials can be safer than a shared internal account, but only if the identity policy is explicit. Entra B2B lets organizations manage collaboration settings, cross-tenant access, domain allowlists or blocks, guest directory visibility, and whether partner MFA or device claims are trusted. GitHub notes that organizations requiring two-factor authentication also require outside collaborators to enable 2FA before accepting repository access.

For lower-friction collaboration tools, teams still need minimum standards. Do not invite throwaway addresses to sensitive rooms. Prefer a partner domain when the relationship is with a company. Require MFA for source code, billing, customer support, incident response, moderation tooling, and private community administration. If a guest cannot meet the identity bar, narrow the scope or use a safer artifact exchange path.

Removing the guest account is necessary but not complete. The guest may have downloaded files, cloned repositories, exported documents, received meeting recordings, copied chat messages, joined direct messages, saved links, or connected an app. GitHub explicitly warns that removed collaborators may retain local clones and are responsible for deleting confidential information or intellectual property. The same practical risk applies to shared documents, chat attachments, exported logs, and vendor ticket systems.

The offboarding checklist should match the type of work. Revoke account access. Remove the guest from channels, repositories, drives, groups, and calendars. Expire shared links. Rotate secrets the guest could see. Close or transfer tickets. Review app authorizations. Ask for return or deletion of regulated material where contracts require it. Archive the approval record so a future incident team can see when the guest had access and when it ended.

Guest access drifts because collaboration feels successful. A contractor stays for another sprint. A vendor joins an additional room. A partner's employee changes roles. A temporary community helper becomes inactive. None of those changes is malicious, but each one can leave sensitive data exposed to someone who no longer needs it.

A workable review cadence is simple: every month for high-risk guests and every quarter for ordinary project guests. Ask the sponsor whether the guest is still needed, whether the channel and repository list is still right, whether the expiration date should change, and whether the guest's company or role has changed. The review should produce a decision, not a report. Renew with a new date, reduce scope, reassign the sponsor, or remove the account.