Managing external identities to enable secure access for partners, customers, and other non-employees
Do not rely on New user → Invite external user (Preview) guest accounts in an external tenant for customer application access; that preview capability is documented for administrative users only and is not compatible with CIAM user flows.^1^
What the successful tests mean
The users’ successful sign-ins do not change the documented scope of that preview feature. The current feature matrix states that external-tenant invited guests using Microsoft Entra accounts, Microsoft accounts, email one-time passcodes, or SAML/WS-Fed are supported via a directory role—for example, as administrators—and for administrative purposes only. It explicitly says this feature cannot be used to invite customers to applications.^1^
External tenants and workforce tenants also use different identity models:
- External tenant: customer or business-customer identities accessing applications published through External ID.
- Workforce tenant: B2B guests collaborating in enterprise applications and organizational resources.^2^
Consequently, UserType=Guest by itself does not establish that the account was created through a supported customer-app onboarding path.
Supported invitation-only configuration
Microsoft now documents a separate external-tenant invitation workflow for consumers and business customers. This workflow supports invitation-only app access, but it is not simply the preview Invite external user administrative flow. It requires:
- An application registered in the external tenant.
- A sign-up/sign-in user flow associated with that application.
- A configured external identity provider (IdP).
- An invitation created through Microsoft Graph or the admin center.
- An application authorization request that routes initial redemption to the IdP, normally through
domain_hint.^3^
For invitation-only access:
- Associate a sign-up/sign-in user flow with each environment’s app registration.
- Optionally disable self-service sign-up in that user flow.
- Configure the required external IdP, such as Microsoft Entra ID, custom OIDC, or SAML/WS-Fed.
- Create the invitation without sending Microsoft’s default invitation email.
- Send a custom app link that starts authorization with the IdP’s
domain_hint. - Keep application authorization separate—the invitation and
domain_hintroute authentication but do not themselves grant access.^3^
During first sign-in, the user authenticates at that IdP, the invitation becomes accepted, and a federated identity is added to the user. Subsequent sign-ins no longer require domain_hint.^3^
Which model to use
- Customers accessing applications registered in the external tenants: use customer accounts created through self-service sign-up, or implement the documented invitation-plus-IdP-routing workflow above.
- Partners accessing an application controlled by the workforce tenant: keep the app and authorization in the workforce tenant and invite them there as B2B guests. Workforce B2B supports Microsoft Entra work/school accounts, personal Microsoft accounts, and email one-time passcodes.^4^
- Administrators managing an external tenant: the preview guest invitation capability is applicable, provided the user is assigned the necessary directory role.^1^
There is an apparent documentation overlap: the newer invitation article supports invited customer access when the full user-flow and IdP-routing pattern is used, while the feature matrix still restricts the generic preview guest capability to administration. Treat these as separate scenarios rather than assuming the preview guest UI now provides general B2B-style app access.
No public roadmap commitment in these documents says that ordinary external-tenant preview guest accounts will become a supported replacement for customer/member identities. For production, use one of the documented models above rather than depending on the behavior observed during preview.
References