Implementation of Microsoft Entra External ID — Microsoft's customer identity platform (CIAM) and the successor to Azure AD B2C — for your customer-facing applications. IT Partner sets up the external tenant, builds the sign-up and sign-in user flows, applies your branding, configures multi-factor authentication and identity protections, integrates your web, single-page, or native applications, and — where you are coming from Azure AD B2C — assesses and executes the migration, including an honest feature-parity verdict before you commit. From $4,950, scoped by the number of applications and user flows; the final quote is fixed, in writing, before work begins.
If your product has a customer login, Microsoft has already made your platform decision for you: Azure AD B2C stopped being available to new customers on May 1, 2025, and all of Microsoft's customer-identity investment now goes into Microsoft Entra External ID. Greenfield projects land on External ID by default. Existing B2C estates keep working — Microsoft has committed to supporting them until at least May 2030 — but new capabilities ship to External ID only, so every B2C owner now carries a migration decision with a deadline measured in years, not weeks. Both situations are what this service is for. For a new implementation, we set up the external tenant and build the experience end to end: sign-up and sign-in user flows with the methods your users expect (email with password or one-time passcode, and social sign-in such as Google, Facebook, and Apple, plus custom OIDC or SAML/WS-Fed federation where a partner IdP is involved), your branding on every screen, multi-factor authentication, and the identity protections available under your chosen External ID tier. Application integration covers web apps, single-page apps, and native mobile clients over standard OpenID Connect and OAuth 2.0, with guidance for your developers on the Microsoft-supported authentication libraries. Where your flows need logic — enriching tokens with claims from your systems, validating sign-up attributes against a CRM, blocking disposable email domains — we implement custom authentication extensions rather than pretending configuration alone will do it. For a B2C migration, we start with a feature-parity assessment and give you the verdict in writing before anything moves: B2C custom policies do not port to External ID as-is, and while most journeys rebuild cleanly on user flows plus custom authentication extensions, some advanced journeys need redesign — you deserve to know which yours are before committing. User migration is planned around a hard platform fact: password hashes cannot be exported from B2C, so accounts move either with a reset at first sign-in or through a staged pattern that validates against the old directory and migrates users transparently as they sign in. We recommend based on your user base and tell you the trade-offs of each. One boundary: this service is customer-facing identity. Workforce sign-on for your employees is a different discipline — see our Entra SSO implementation for third-party applications.
Applications, user journeys, identity providers, attributes, and compliance constraints are mapped. For B2C migrations this includes the policy inventory and the written feature-parity assessment. Output: the design document and the fixed quote confirmation.
External tenant creation, billing linkage, custom domain where scoped, user flows with the agreed sign-in methods, and branding.
App registrations, redirect URIs, token and claims configuration, and integration of each in-scope application with your developers — including test environments before production.
MFA enforcement, identity protections available under your tier, and token/session policies matched to your risk profile.
User migration under the agreed password strategy — bulk with first-sign-in reset, or staged just-in-time validation against the existing directory — followed by application cutover and a monitored coexistence window.
Every flow exercised end to end on desktop and mobile, edge cases documented, and the runbook walked through with your team.
Microsoft stopped selling Azure AD B2C to new customers on May 1, 2025, and has committed to supporting existing B2C tenants until at least May 2030. New feature development goes to Microsoft Entra External ID. So: not switched off tomorrow, but the platform's direction is settled — every new customer-identity project lands on External ID, and every B2C estate owns a migration decision.
No, and we will not manufacture urgency. With Microsoft support committed until at least May 2030, a working B2C estate has runway. The honest reasons to move earlier: features you need that only ship to External ID, consolidation of identity platforms, or a product rebuild that touches auth anyway. The parity assessment is how you make that call with facts — and if the answer is 'wait', we will say so.
The floor covers a greenfield implementation with a single application and standard sign-up/sign-in flows: tenant, flows, branding, MFA, one app integration, testing, and the runbook. More applications, additional or complex user flows, custom authentication extensions, and B2C migration scope move the number. After discovery you receive one fixed quote in writing — that number is the number, and you pay after you approve delivery.
Password hashes cannot be exported from Azure AD B2C — Microsoft does not expose them, to us or anyone. That leaves two honest options: bulk-migrate accounts with a password reset at first sign-in, or a staged just-in-time pattern where the new platform validates each user's first login against the old directory and migrates them transparently. The right choice depends on your user count, activity, and tolerance for support tickets; we present the trade-offs and you decide.
Email with password or one-time passcode, social sign-in with providers such as Google, Facebook, and Apple, and federation with custom OIDC or SAML/WS-Fed identity providers for partner scenarios. The exact matrix is confirmed against Microsoft's current documentation during design, because External ID's capabilities are still expanding — what we commit to in the design document is what is supported the day we design it.
Microsoft bills it per monthly active user into your Azure subscription — a user who never signs in during a month costs nothing that month. As of this writing, Microsoft's published pricing includes a free core tier covering the first 50,000 monthly active users, with premium capabilities as paid add-ons. We model your expected MAU cost during design so there are no billing surprises, but the meter and the price list are Microsoft's — verify current figures at contracting.
No — and mixing them up is expensive. Workforce identity (your staff signing in to Microsoft 365 and SaaS tools) lives in your regular Entra ID tenant and is covered by our separate SSO implementation services. External ID is for your customers: self-service sign-up, social login, consumer-scale MFA, and per-MAU billing. This service builds the customer side; if you need both, they are scoped as two engagements because they are two systems.
Yes. External ID speaks standard OpenID Connect and OAuth 2.0, and we integrate web apps, SPAs, and native mobile clients using Microsoft's supported authentication libraries, with the appropriate flow for each client type. Your developers make the app-side changes with our guidance — auth code belongs in your repo, reviewed by your team, not delivered as a black box.
Yes — that is what custom authentication extensions are for. External ID can call your APIs at defined points in the flow: enriching tokens with claims from your systems, validating attributes at sign-up, or gating registration on business rules. We implement the extensions, and we also flag the operational truth: your API becomes part of your login path, so it needs the availability to match. The runbook covers that dependency explicitly.
We configure the protections the platform offers under your chosen tier — MFA on risky actions, identity protection signals where licensed, and flow design that resists cheap abuse (verified email, throttling behavior, sensible defaults). No identity platform stops all fraud, and we will not claim otherwise; what you get is the platform's current controls configured deliberately and documented, plus honest notes on residual risk.
The typical engagement is about three weeks: design in the first, build and integration in the second, testing, migration, and handoff in the third. Multi-app estates and large B2C migrations run longer, and the timeline is stated in the same written quote as the price.
You do, with the runbook: user management, sign-in monitoring, flow changes, and the sharp edges we found on the way. Microsoft owns the platform and its billing; your developers own the app side; the design document and runbook make the whole thing maintainable without us. If you would rather we stay involved, ongoing support is available — separately, with no obligation.