Unknown user appears in my tenant: how to verify and remove access

TL;DR — If you see a user you do not recognise in your tenant, treat it as a possible access issue until proven otherwise. The most common causes are a legitimate invite, directory sync (automatic import from your identity provider), or a service account; start by checking the user details and audit log in your provider's dashboard, then suspend/remove the account and rotate affected sessions if the account is real and unexpected. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and you are reviewing users in your admin dashboard before onboarding a new starter. One account jumps out: an email address or display name you do not recognise, and nobody on your team claims to know who it is. You are not sure whether it is a harmless synced account, a contractor who was invited months ago, or someone who should not be there at all. You need to answer two questions quickly: does this account actually have access, and what is the safest way to remove it without breaking anything.

Symptoms

• You see an unfamiliar user in your tenant's Users, Members, or Directory page.
• The account may show statuses such as:
  • Active
  • Invited
  • Pending acceptance
  • Provisioned by SCIM
  • Federated
  • Service account
• Audit logs may show entries like:
  • User invited
  • User created
  • User provisioned
  • Group membership added
  • Role assigned
  • Login successful
• The user may have an email domain you do not expect, such as a personal address or a partner company domain.
• You may see role labels such as:
  • Admin
  • Owner
  • Billing
  • Member
• In some systems, the account appears but has never signed in; in others, you see recent sign-in activity from an unfamiliar IP address (internet address).

Likely causes

Step-by-step diagnosis

1. Open the user's detail page first. In your provider's dashboard, go to Users or Members → click the unfamiliar account.

   • This is your problem if: you can clearly see labels such as Invited by, Created by, Pending acceptance, Provisioned by SCIM, Service account, or Last sign-in: Never.
   • Jump to: the matching fix section below.

2. Check whether the account has ever signed in. On the same user page, look for Last sign-in, Recent activity, or Sessions.

   • This is your problem if: the account is Pending acceptance or Last sign-in: Never. That usually means it was invited or provisioned but not used yet.
   • Jump to: ### Legitimate invite or old contractor account was never removed or ### Directory sync or SCIM provisioning created the account from your identity provider.

3. Review the audit log for who created it. In your provider's dashboard, go to Audit logs or Activity → filter by the user's email address.

   • This is your problem if: you see events like User invited by admin@yourcompany.com, User provisioned by SCIM, or Added to group Everyone.
   • Jump to: the fix section that matches that event.

4. Check the user's roles and group memberships. Go to Users/Members → click the user → Roles and Groups.

   • This is your problem if: the user is getting access from a group such as All Employees, Contractors, MSP Admins, or a role mapping from your identity provider.
   • Jump to: ### Group or role mapping added a real user from a parent company, MSP, or partner domain.

5. Confirm whether it is a service or automation identity. Look for labels like Service account, API client, Token created, or a non-human email naming pattern such as ci-bot@, sync@, or terraform@.

   • This is your problem if: the account owns API tokens, webhooks, or automation jobs, and there is no interactive sign-in history.
   • Jump to: ### Service account, integration user, or automation identity looks like a person.

6. Verify you are in the right tenant/environment. Go to Settings → General, About, or Organization and compare the tenant name, primary domain, and environment label with your expected production tenant.

   • This is your problem if: the tenant is a staging, sandbox, internal, or customer-specific environment where different users are expected.
   • Jump to: ### Wrong tenant or environment confusion (prod vs staging, customer vs internal).

7. If the account is active and unexpected, contain first. In your provider's dashboard, go to Users/Members → click the user → choose Suspend, Block, or Remove sessions.

   • This is your problem if: the account has recent sign-ins you cannot explain, elevated roles, or was created by an admin action nobody can account for.
   • Jump to: ### Actual unauthorized access due to compromised admin credentials or bad invitation controls.

Fixes

Legitimate invite or old contractor account was never removed

If the user was invited by someone on your team, or it is an old employee/contractor account, remove access cleanly.

1. In your provider's dashboard: Users/Members → click the user.
2. If the status is Pending acceptance, click Cancel invitation or Delete invited user.
3. If the status is Active, click Suspend first, then Remove from groups, then Delete if your policy allows it.
4. If the user had admin access, review Audit logs for any changes they made before removal.

If your provider syncs from an identity provider, also disable the person there so they do not come back on the next sync.

Dashboard path: Identity provider admin console → Users → select user → Disable or Remove from assigned app

Verify it worked: the user no longer appears under active members, and a search in Audit logs shows User suspended, Invitation cancelled, or User deleted.

Directory sync or SCIM provisioning created the account from your identity provider

SCIM (System for Cross-domain Identity Management, an automatic user provisioning standard) can create users even if nobody invited them manually.

1. In your provider's dashboard, confirm the user shows Provisioned by SCIM, Synced, or similar.
2. Open your identity provider admin console and search for the same email.
3. Remove the app assignment, group membership, or provisioning scope that is creating the account.

Typical path in an identity provider:

Identity provider admin console → Applications/Enterprise apps → your app → Provisioning or Assignments → remove user or remove source group

1. Run a manual provisioning sync if your provider offers it, or wait for the next sync cycle.
2. Back in the target tenant, suspend or delete the user if they should not exist there.

Verify it worked: after the next sync, the user does not reappear, and the audit log no longer shows new User provisioned events for that email.

Service account, integration user, or automation identity looks like a person

Do not delete this account until you know what it does; it may break integrations.

⚠️ Deleting a service account can stop deployments, backups, sync jobs, or API integrations immediately.

1. In your provider's dashboard, open the user and check for API tokens, owned integrations, last token use, or service account labels.
2. Search your internal password manager, documentation, or integration list for the same email/name.
3. If the naming is unclear, rename it to something explicit and reduce its permissions.

Example naming convention to apply in your records:

svc-ci-deploy@yourcompany.com
svc-hr-sync@yourcompany.com
svc-backup-exports@yourcompany.com

1. If the account is unnecessary, create a replacement service account with least privilege (minimum required access), move the integration to it, test, then disable the old one.

Verify it worked: the integration still functions, and the account is either clearly labeled as a service identity or removed without errors in connected systems.

Group or role mapping added a real user from a parent company, MSP, or partner domain

The user may be inheriting access from a synced group or role mapping rather than a direct invite.

1. In your provider's dashboard, open the user's Groups and Roles.
2. Identify the source group that granted access.
3. In your identity provider admin console, remove the user from that source group or change the app assignment rule.

Typical path:

Identity provider admin console → Groups → select source group → Members → remove user

1. If the group is valid but too broad, create a narrower group and assign only approved users.
2. Re-sync the application if needed.

Verify it worked: the user's role disappears or the account is deprovisioned after sync, and the audit log shows the group membership removal.

Wrong tenant or environment confusion (prod vs staging, customer vs internal)

Sometimes the account is valid, but you are looking at the wrong place.

1. In your provider's dashboard, go to Settings → General/About/Organization.
2. Record the tenant name, primary domain, and any environment label.
3. Compare those details with your internal inventory or the URL/bookmark you expected to use.
4. Rename the tenant or add a visible environment label if your provider supports it.

Example environment naming to standardize internally:

acme-prod
acme-staging
acme-internal

Verify it worked: you can clearly distinguish environments, and the user is expected in that specific tenant after checking your records.

Actual unauthorized access due to compromised admin credentials or bad invitation controls

Treat this as a security incident.

⚠️ The next steps may sign out admins and interrupt normal work. Do them in a planned order so you do not lock out the wrong people.

1. Contain the user immediately: Users/Members → click the user → Suspend/Block and Revoke sessions.
2. In Audit logs, identify who invited or created the account and what roles were assigned.
3. For the admin account that performed the action, force a password reset and revoke sessions.
4. Enforce MFA (multi-factor authentication, an extra sign-in check) for all admins if it is not already required.
5. Review invitation settings and restrict who can invite users.

Typical actions in a provider dashboard:

Settings → Security → Authentication → Require MFA for admins
Settings → Members/Invitations → Limit invitations to admins only
Users → select admin account → Revoke sessions / Reset password

1. Review recent changes for persistence: new API tokens, new OAuth apps, new admin users, changed domains, changed SSO settings.
2. If regulated data may have been exposed, preserve audit logs and follow your incident response process.

Verify it worked: the unknown user is blocked, affected admin sessions are revoked, MFA is enforced for admins, and no new suspicious audit events appear after containment.

Prevention

• Restrict who can invite users. In your provider's dashboard, set invitations to admins only.

Settings → Members/Invitations → Allowed inviters → Admins only

• Require MFA for all admins and billing roles. This is the single best control against unauthorized user creation from a compromised admin account.

Settings → Security → Authentication → Require MFA for roles: Admin, Owner, Billing

• Review provisioning scope in your identity provider. Assign the app only to explicit groups, not broad groups like All Employees.

Identity provider admin console → Applications → your app → Assignments → Assigned groups only

• Create a monthly access review checklist. Export users and compare against HR or your vendor list.

email,display_name,role,last_sign_in,source

• Use clear service account naming. Reserve prefixes such as svc- or bot- so non-human accounts are obvious at a glance.

svc-backup@yourcompany.com
bot-release@yourcompany.com

• Alert on high-risk audit events. If your provider can send logs to email, SIEM (security log platform), or webhook, alert on these events: User invited, Admin role assigned, MFA disabled, SSO changed, API token created.

{"alert_on":["user.invited","role.admin_assigned","mfa.disabled","sso.updated","api_token.created"]}

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