In Microsoft Entra ID, every user object carries a userType value of Member or Guest. This setting expresses the account’s relationship to your tenant and defines conservative defaults for directory visibility and self‑service actions. It does not replace role assignments, group‑based access, or Conditional Access. You can always override the defaults with explicit roles and app assignments, but choosing the right type at creation time keeps governance clean and reduces exceptions.
What actually differs
Members are treated as internal identities. By default they can read most directory objects that are not explicitly protected, subject to tenant‑wide policies such as “Users can read other users.” They can create or register resources like applications and security groups if your user settings allow it, and they typically authenticate in your tenant or through its federated identity provider. Their UPN follows your organization’s domains, for example email@yourdomaain.com.
Guests are provisioned for external collaboration. Their directory visibility is intentionally narrow, so they cannot freely enumerate users, groups, or devices. A guest authenticates with the home identity provider that owns the credentials, not with your tenant. In your directory they often appear with a guest‑style identifier such as user_gmail.com#EXT#@tenant.onmicrosoft.com. That string is a local identifier only; it does not change where the user signs in. Because a guest’s password and primary security info live with the home provider, your tenant cannot reset that password. Your Conditional Access policies can still require MFA or other controls at sign‑in, and Entra will prompt accordingly.
Why the distinction matters
Using the correct type enforces least‑privilege defaults and reduces accidental disclosure through directory enumeration. It also aligns lifecycle operations such as access reviews and entitlement management. Licensing is affected as well. Members generally consume your organization’s licenses once assigned to apps and features. Guests usually fall under External ID entitlements for B2B collaboration. Promoting a guest to member can therefore increase license usage and should be planned.
Converting a guest to a member in the portal
Open the Microsoft Entra admin center, navigate to Identity → Users → All users, open the target user, then choose Edit properties. On the Identity tab set User type to Member and save. The change updates defaults only. It does not grant access on its own. Add the user to the correct groups, assign the necessary app roles, and verify that Conditional Access policies and access reviews cover the user as intended. If you want a standard internal UPN rather than the #EXT# format, update userPrincipalName and mailNickname separately after you switch the type.
PowerShell and Microsoft Graph
# Requires appropriate permissions; delegated example
Connect-MgGraph -Scopes “User.ReadWrite.All”
Select-MgProfile -Name “v1.0”# Convert a single user by object ID or UPN
Update-MgUser -UserId “<objectId-or-upn>” -UserType “Member”# Optional: normalize UPN and alias after conversion
Update-MgUser -UserId “<objectId>” `
-UserPrincipalName “firstname.lastname@contoso.com” `
-MailNickname “firstname.lastname”
Replace `<ObjectId>` with the user’s object ID. This approach is ideal when you need to convert many accounts at once.
For bulk changes, import a CSV of object IDs and loop through Update-MgUser. Keep audit logs and change records, and confirm that license assignment, group membership, and app entitlements are applied as part of the same change window.
Practical guidance
Convert a guest to member when the person effectively functions as internal staff and needs member‑level defaults but will continue to authenticate with their home identity provider. Create a new member account instead if you require a fully tenant‑managed identity with your credential policies and joiner‑mover‑leaver processes. If the relationship is short‑term or visibility must remain minimal, keep the identity as a guest.
Key points: userType sets defaults for visibility and self‑service; it does not move authentication into your tenant and it does not grant access. After any change, review licenses, groups, app roles, and Conditional Access so the account’s effective permissions match your intent.
