Just-in-time is half a lifecycle

Claude’s Team plan supports single sign-on and just-in-time provisioning. A new employee is assigned to the Claude application in Okta, Entra or Google, logs in once, and a member appears in the organization with a seat attached. That is the joiner side of the lifecycle handled cleanly, and it is where many Team setups stop.

SCIM handles the other direction automatically, but SCIM is an Enterprise feature. On Team, JIT never removes a member. Unassign the person from the Claude application in the identity provider and they can no longer authenticate, but their Claude membership remains and their seat stays occupied until an administrator removes them.

Two halves, one automated

Unassigning a leaver from the Claude application does close the first control that matters: they cannot authenticate to the organization through SSO. But that is not deprovisioning, and Anthropic documents JIT removal as manual on Team. What the identity provider reaches, and what it leaves standing, are two different lists.

The member remains in the organization until an administrator removes them, and the seat remains consumed. Removing the member releases the seat. Their previous chats, projects and skills are not simply destroyed: project accessibility to other members depends on how each project was shared, the removed member’s data remains available through an organization data export run by the Primary Owner, and re-adding the same email to the same organization restores previous chats, projects and skills.

Connector authorization deserves its own line on the checklist. The ordinary connector model uses individual authentication after an Owner has enabled the connector for the organization. Unassigning the Claude SSO application does not mean every separately authorized third-party session should be assumed revoked. Disconnect or revoke those connections as part of offboarding.

There is an important exception to that pattern. Anthropic now supports Enterprise-managed authentication for a current set of MCP connectors on both Team and Enterprise plans. Where a connector is using managed authentication through the identity provider, deprovisioning the person in the IdP removes their connector access as part of that managed lifecycle. Record which model each connector uses rather than treating every connector token the same way.

Why removing them in Claude is not enough

The permanent JIT removal procedure has two mandatory identity actions. Remove the member from Claude, and unassign them from the Claude application in the identity provider.

Anthropic is explicit about the consequence of doing only one. If the person is merely unassigned from the IdP, their Claude membership and seat remain. If they are merely removed from Claude while their IdP assignment still allows them to authenticate, JIT creates the membership again the next time they log in.

That pair belongs in one offboarding task, owned by one process.

The step people forget

1. 01 Unassign

   Remove the Claude application assignment in the identity provider.

   Outcome SSO access stops. Membership and seat are untouched.

2. 02 Remove

   Remove the member from Claude.

   Outcome The seat is released. Retained data remains subject to the organization’s data lifecycle and to a Primary Owner export.

3. 03 Close connectors

   For individually authorized connectors, disconnect or revoke the user’s third-party authorization. For managed-auth connectors, verify that IdP deprovisioning removed connector access.

   Outcome Authentication, membership and connector authorization are three different states, and offboarding is complete only when the states that apply to that user are closed.

The first two actions are easy to place on a normal HR leaver checklist. The third is easier to miss because the authorization may live partly in Claude and partly in the connected service or identity platform. A fourth check belongs beside them and sits on a different path entirely: whether the employee also has a personal Claude account associated with the work domain.

Do not hard-code fragile Google Admin or Entra click paths into a procedure. Admin console navigation changes. The operating requirement is the durable part: identify every Claude-related authorization the leaver held, determine whether it was individually authorized or centrally managed, and revoke it through the appropriate control plane.

Because Team does not have SCIM deprovisioning, somebody has to own this process. I train the client’s internal team to do it rather than keeping the task with me, because it needs to happen on the day the person leaves, regardless of whether an outside consultant is available.

Personal accounts are a different lifecycle

A personal Claude account is not the same problem as a stale organization membership.

On an SSO-enabled organization, invite links and organization discovery are not available. Provisioning is controlled by the identity provider. That closes two common join paths automatically.

Member-to-member invitation behavior should still be reviewed as part of the tenant configuration, but do not confuse invitation control with the pre-existing personal account problem.

Verify the corporate domain and enable the setting that restricts new organization creation on that verified domain. On Team, that can prevent new personal Claude accounts from being created on the work domain from that point forward.

It does not give Team administrators the Enterprise domain-claiming workflow. Administrative domain claiming, where existing personal accounts on the verified domain are discovered and moved into the Enterprise organization under an enforced migration process, is Enterprise-only. On Team, an employee can voluntarily migrate a personal account into the Team organization, but the administrator cannot force the migration through domain claiming.

Voluntary migration is useful because chats, projects, files and memory can move into the organization, while sign-ins to connected apps are revoked and have to be connected again from the organization account. But it still depends on the employee taking the migration action.

The remaining Team risk is therefore not imaginary: an existing personal account can continue to sit outside the organization’s retention and administrative boundary.

When this becomes the reason to upgrade

For a company with stable headcount, a functioning HR handoff and an IT owner who actually completes the checklist, manual JIT offboarding can work.

For a company with frequent leavers, rotating contractors or a history of delayed offboarding, missing SCIM is no longer a feature-table difference. It is a specific lifecycle control the Team plan does not automate.

The same is true when existing personal accounts on the company domain need administrative consolidation rather than voluntary migration.

Those are better reasons to price Enterprise than saying that Enterprise simply has more features. Each upgrade maps to an identifiable failure mode and an operational cost.

Until then, Team’s lifecycle is deliberately asymmetric. JIT automates arrival. The organization has to own departure.

Product note. Product features change frequently, so always check current features and documentation before acting on this note. It reflects behavior as reviewed in September 2026 and is a starting point rather than a configuration reference.

Explore this expertise: AI Platform Governance

All technical notes