What happens to your access when you move to a different team

TL;DR — When you move to a different team, your access should usually be recalculated from your new role and group memberships, not manually edited app by app. The safest and most common fix is to remove old team group membership, add the new one in your identity provider (the central login system), then let connected apps sync permissions. Reading time: ~7 min

What it is and where it sits

When someone moves to a different team, their access changes because most modern systems do not grant permissions directly to a person one by one. Instead, access is usually attached to a group (a named set of users), a role (a bundle of permissions), or both. Your company's identity provider (IdP, the system that handles login and user identity) is often the source of truth.

In plain terms: your name stays the same, but the labels attached to your account change. Those labels then control what you can open, edit, approve, or administer.

Typical examples:

• Moving from Support to Finance may remove access to customer ticket queues and add access to invoice tools.
• Moving from one client account to another in an agency may remove access to the old client's dashboards, repositories, cloud projects, and shared folders.
• Moving into management may add approval rights but remove some hands-on production access.

Where it sits in the architecture

In a typical setup, the identity provider sits in the middle:

• HR system or admin team records the team change.
• Identity provider updates group membership.
• Apps such as Google Workspace, Microsoft 365, GitHub, Jira, cloud consoles, VPN, and internal tools read those groups.
• Some apps update instantly at next login; others sync every few minutes or hours.

What this replaces: older setups often gave access manually inside each app. That works at small scale, but it creates stale access when people change teams because nobody remembers every system.

A typical flow looks like this:

HR/admin change
      |
      v
Identity Provider (user + groups + roles)
      |
      +--> Email/Docs
      +--> Project tools
      +--> Source code hosting
      +--> Cloud accounts
      +--> VPN / SSO apps

And during sign-in:

User logs in
   |
   v
App redirects to Identity Provider
   |
   v
Identity Provider sends identity + groups/role claims
   |
   v
App maps those claims to permissions

The important point: if access is well designed, the team move is mostly a group membership change in one central place, not a long manual checklist across dozens of tools.

How it actually works

Let's walk one realistic example end to end.

Example: moving from Client A delivery team to Client B delivery team

Assume an agency has these systems:

• An identity provider for single sign-on (SSO, one login used across apps)
• Google Workspace or Microsoft 365 for email and files
• GitHub for code
• Jira for project work
• A cloud provider account for each client
• A VPN or zero-trust access tool for internal systems

The user, Sam, moves from the Client A team to the Client B team.

Step 1: the source of truth is updated

An admin changes Sam's team in the HR system or directly in the identity provider.

In the provider's dashboard, this is usually one of these patterns:

• Directory → Users → Sam → Groups
• Admin console → Users → Sam → Assign groups
• Identity → People → Sam → Memberships

The admin removes:

• client-a-users
• client-a-github
• client-a-cloud-readonly

And adds:

• client-b-users
• client-b-github
• client-b-cloud-readonly

If your organization uses roles instead of groups, the path is similar, but the labels may be called Assignments, Entitlements (access bundles), or App roles.

Step 2: connected apps receive the new identity data

Each connected app handles this in one of three common ways:

1. At next login: the app reads the updated group list when Sam signs in again.
2. On a sync schedule: the app imports changes every 15 minutes, hourly, or nightly.
3. Via provisioning: a user-management standard like SCIM (a common protocol for creating and updating users in apps) pushes the change automatically.

This means Sam may see a short transition period where:

• old access still works until the app refreshes, or
• new access does not appear until Sam signs out and back in.

Step 3: app-level permissions are recalculated

Now each app maps the new group membership to its own permission model.

Examples:

• GitHub team access changes from Client A repositories to Client B repositories.
• Jira project permissions switch from Client A boards to Client B boards.
• Cloud console access changes from one project/account to another.
• Shared drive or SharePoint access changes to the new client folder set.

This is where many people get confused: the identity provider does not always store the final permission itself. It often sends claims like "Sam is in client-b-github," and the app decides what that means.

Step 4: old sessions may still exist

Even after the group change, Sam may still have an active browser session, API token (a secret string used by software to act as the user), SSH key, or cloud CLI login from the old team.

Good access processes handle this by forcing one or more of the following:

• sign out of the app
• revoke active sessions
• revoke personal access tokens
• rotate shared credentials if the old team used any
• remove access from direct app membership lists

This is why a team move is not only "add new access." It is also "cleanly remove old access."

Step 5: verification

A manager or admin should verify both sides:

• Sam can access what the new team needs.
• Sam cannot access what the old team no longer allows.

The simplest test is practical:

• Sign in to the main portal.
• Open the new team's tools.
• Try one old-team resource that should now be blocked.

If the old resource still opens, the usual cause is direct access left behind inside that app.

When to use it (and when not to)

The right model is usually role- or group-based access. Direct per-user permissions should be the exception.

You probably don't need this if...

• You only have one or two systems and changes are rare.
• No app supports SSO, group sync, or centralized user management.
• Every person already has completely unique permissions for valid business reasons.

Even then, you still need a move checklist. Otherwise old access tends to linger.

Trade-offs

Every access model is a trade.

• Benefit: faster team changes
  Cost: you must design groups and roles carefully up front.

• Benefit: fewer forgotten permissions
  Cost: apps may sync at different times, so changes are not always instant.

• Benefit: easier audits (proof of who should access what)
  Cost: someone must own periodic review of group definitions.

• Benefit: less manual work in each app
  Cost: you become more dependent on the identity provider and its mappings.

• Benefit: safer offboarding and transfers
  Cost: you must also manage sessions, tokens, and direct app grants, not just SSO groups.

• Benefit: consistent customer/account separation
  Cost: stricter separation can frustrate staff who move often and need temporary overlap.

The biggest hidden cost is cleanup. Many organizations set up new access correctly but forget old local permissions inside GitHub, cloud IAM (identity and access management), shared drives, or databases.

In practice

Below are two practical examples you can adapt. The first shows what an access mapping often looks like in configuration. The second shows how to verify a team change in a common cloud setup.

Example 1: simple group-to-app mapping

{
  "groups": {
    "client-a-users": {
      "apps": {
        "jira": ["project-client-a-user"],
        "github": ["team-client-a-read"],
        "cloud": ["client-a-viewer"]
      }
    },
    "client-b-users": {
      "apps": {
        "jira": ["project-client-b-user"],
        "github": ["team-client-b-read"],
        "cloud": ["client-b-viewer"]
      }
    }
  }
}

This is a conceptual example of the mapping many organizations maintain, whether in a dashboard or in code. The gotcha: if someone is left in both client-a-users and client-b-users, they may keep access to both clients.

Example 2: verify cloud access after a team move with AWS CLI

⚠️ If you remove or change the wrong IAM role or policy in a production cloud account, you can lock people out of systems they need to operate. Test with a non-admin user first and keep a break-glass admin account (an emergency account used only for recovery).

aws sts get-caller-identity
aws iam list-attached-role-policies --role-name ClientBReadOnly
aws s3 ls s3://client-b-reports
aws s3 ls s3://client-a-reports

This checks who you are logged in as, what policies are attached to the expected role, and whether access works for the new client bucket while failing for the old one. The gotcha: a cached old session can make it look like access still exists, so sign out and sign back in before testing.

Example 3: remove old direct repository access in GitHub CLI

⚠️ Removing the wrong collaborator or team from a repository can block active project work. Export the current permission list before changing anything.

gh repo view agency/client-a-app --json collaborators,teams
gh api -X DELETE repos/agency/client-a-app/collaborators/sam@example.com

This first shows current direct collaborators and team assignments, then removes a direct collaborator grant that may have survived the team move. The gotcha: if access comes from a team rather than direct collaboration, deleting the collaborator entry will not remove access; you must update the team membership in the identity provider or GitHub team.

Dashboard-first verification checklist

If you are not using CLI tools, use this sequence in your provider dashboards:

1. In your identity provider, open Users → [person] → Groups/Roles and confirm the old team is removed and the new team is added.
2. In each critical app, open the user's profile or access page and look for direct assignments separate from SSO groups.
3. In your cloud provider's dashboard, open IAM/Access management → Roles/Users and confirm the old client account or project is no longer assigned.
4. Ask the user to sign out everywhere, then sign back in.
5. Test one allowed resource and one now-forbidden resource.

That last step matters. A successful team move is not just "new access works." It is also "old access is gone."

Further reading

• NIST SP 800-162, "Guide to Attribute Based Access Control"
• NIST SP 800-53, "Access Control" family
• SCIM 2.0 specification
• The "Authorization" section of the OWASP Cheat Sheet Series
• Microsoft Entra or Okta documentation on group-based application assignment

This article was written by an AI system and published pending human review. Verify anything you intend to act on.