A supply chain director at a mid-market manufacturer recently asked her IT team to stand up a new supplier self-service portal on Power Pages: purchase order visibility, invoice status, a place for vendors to upload compliance documents. Nothing exotic. The kind of project that used to start with a fairly routine question: which identity provider do we wire up for sign-in? For years, the routine answer was Azure AD B2C. It isn’t anymore, and the reason has less to do with Power Pages itself than with a licensing decision Microsoft made about the identity service underneath it.
If your organization is not already an Azure AD B2C customer, you cannot create a new B2C tenant today. That single fact changes the Power Pages authentication provider decision for every external-facing portal currently on a scoping document, and most of the teams building those portals have not caught up to it yet.
What Actually Changed
Microsoft closed Azure AD B2C to new customers on May 1, 2025. Organizations that already had a B2C tenant on that date can keep using it, keep creating additional tenants, and Microsoft has committed to supporting the product through at least May 2030. Organizations that did not already have a B2C relationship lost the option outright. There was a second, quieter cutoff in between: B2C’s P2 tier, the one with the deeper Conditional Access and Identity Protection integration, was discontinued for all customers, existing and new, on March 15, 2026. Existing tenants moved to P1, which is the tier Power Pages sites have generally run on anyway, so that part of the change was less disruptive than it sounds. The tenant-creation cutoff is the one that actually redraws the map.
Microsoft’s stated replacement is Microsoft Entra External ID, which reached general availability for Power Pages on May 1, 2025 after a public preview that started the previous September. It is a real product, not a rebrand: it gives Power Pages a low-code way to add branded sign-in and registration screens, multi-factor authentication, social identity provider sign-in alongside your own directory, and built-in analytics on who is actually using the portal, all configured from the site’s Identity Providers settings rather than through a separate Azure tenant with a manually registered OpenID Connect application. For a straightforward customer or supplier portal, that setup experience is arguably better than what B2C ever offered.
The Power Pages Authentication Provider Choice, in Practice
Here is where the decision actually splits. If your organization already runs an Azure AD B2C tenant for something else, whether it is an older customer portal, a mobile app, or a partner-facing application, you retain the option to keep building on B2C for new Power Pages sites too, including its deeper customization layer. If you do not have that existing relationship, Entra External ID is not one option among several. It is the only Microsoft-native path forward, because the door to B2C is closed regardless of how well External ID happens to fit your requirements.
That asymmetry matters more than it looks like on the surface. A portal built by an existing B2C shop and a functionally identical portal built by a net-new customer are no longer choosing between comparable tools. One team has the full B2C toolkit available if they need it. The other is working within whatever Entra External ID currently supports, full stop.
The Gap Nobody’s Migration Deck Mentions
What Entra External ID currently supports is where the real planning risk sits. Azure AD B2C’s Identity Experience Framework let architects write custom policies: orchestration logic that could federate authentication out to an external identity provider, including something as specific as a legacy on-premises IdentityServer instance, and then auto-provision a user record in the destination system based on claims that came back from that external IdP. That pattern shows up constantly in supplier and partner portals, where the partner organization already has its own identity system and nobody wants to make external users create yet another password.
Entra External ID does not yet replicate that. A Microsoft moderator confirmed this directly in a Microsoft Q&A thread from an organization that ran into exactly this wall: new B2C tenant creation is closed to net-new customers, existing customers are unaffected, and there is no workaround for the federation and custom-policy gap in External ID. The response was candid about the limitation rather than papering over it, which is useful information in itself: this is a known, acknowledged gap, not a configuration mistake on the customer’s part.
There is a second limitation worth flagging for anyone running a multi-organization or B2B-style portal. Entra External ID’s contact-mapping feature, which automatically associates an authenticated user with the right Dataverse contact record based on their email address, does not apply to multitenant endpoints. If your portal is meant to serve users from several different partner organizations authenticating through their own tenants rather than one shared consumer-style sign-up flow, that automatic mapping convenience simply is not there yet, and the provisioning logic has to be built by hand elsewhere in the solution.
Neither gap is disqualifying on its own. Both are the kind of detail that surfaces three weeks into a build rather than during the initial scoping conversation, which is exactly when it is most expensive to discover.
What This Means for a Portal You’re Scoping Right Now
Before signing off on the identity approach for a new Power Pages site, it is worth getting a straight answer to a short list of questions. Does the portal need to authenticate users who already have credentials in a system Microsoft does not control, such as a partner’s own identity provider or an on-premises directory that predates your cloud migration? Does user access depend on custom provisioning logic beyond a standard email-and-password or one-time-passcode sign-up, such as auto-approving users from a specific partner domain or pulling attributes from an external system at the moment of first login? Will the portal ultimately need to serve users authenticating from more than one external tenant rather than one consolidated sign-up pool?
A “yes” to any of those questions is worth checking against your organization’s actual B2C status before the project plan gets locked in. If you already hold a B2C tenant, that route remains open and may be the lower-risk path for a portal with those requirements, with the reassurance of Microsoft’s support commitment running through 2030 to absorb the migration timeline. If you do not, the honest scoping conversation is about designing around Entra External ID’s current boundaries: pushing provisioning and claims logic into Power Automate flows or Dataverse plugins that run after a simpler authentication event, rather than assuming the identity layer itself will do that orchestration for you. Microsoft’s own FAQ on this transition is candid that detailed migration guidance is still being finalized and points customers to their account team for specifics, which is itself a signal that this is an evolving area worth revisiting before a portal design is treated as final.
None of this argues against building on Power Pages. It argues for treating the authentication provider decision as a genuine architecture choice again, the way it was before B2C became the automatic default, rather than a checkbox to clear on the way to the parts of the portal that feel more interesting. We have been walking clients through exactly this calculation at Routeget, both for organizations sitting on legacy B2C configurations deciding whether to keep extending them and for net-new engagements designing around External ID’s current limits rather than building technical debt against a gap Microsoft has acknowledged but not yet closed.
#PowerPages #AzureADB2C #EntraExternalID #IdentityGovernance #PowerPlatform #PartnerPortals