Low-Budget Identity Provider: Build vs. Buy

1. Problem Statement

Clients in regulated, non-hyperscale industries — mid-size financial institutions, tech companies, pharma, aerospace, and (German/DACH) public or state agencies — need a production-grade identity provider (IdP) as part of a solution package, but cannot or will not absorb the cost profile of a full enterprise IAM estate built for hundreds of millions of identities (the customer-IAM/e-commerce case is explicitly out of scope here).

Two credible options exist at opposite ends of the build-vs-buy spectrum:

• Buy: Microsoft Entra ID, consumed as a managed cloud service, licensed per user/month.
• Build: Keycloak, self-hosted (ideally as the Red Hat build, for a supportable compliance posture), consumed as an open-source platform plus operational effort.

The strategic question this document answers: which of these two representative options should anchor a low-budget IdP solution package for a given client, and why — evaluated on compliance posture and on cost/licensing transparency, since for Microsoft specifically the two are inseparable.

Excluded from scope: a large enterprise standing up its own private "Azure-like" stack; a very cost-sensitive legal entity trying to resell Keycloak-based cloud offerings commercially. Both are real but are separate business models, not IdP selection questions.

2. Requirements

2.1 Functional

• Standards-based authentication: OIDC and SAML 2.0 support at minimum
• Single sign-on across a heterogeneous application landscape (cloud + on-prem)
• Multi-factor authentication (MFA), ideally with FIDO2/passkey support
• Role/group mapping into the client's existing authorization model
• Federation with existing directories (LDAP/Active Directory) where present

2.2 Compliance & Regulatory

• Demonstrable cryptographic assurance (FIPS 140-2 or equivalent) where the industry demands it (finance, pharma, aerospace, government)
• Auditable change control, patch SLAs, and CVE response process
• Data residency and jurisdictional control — explicit answer to "which country's courts can compel access to this data"
• For DACH public-sector clients specifically: alignment with the political/regulatory push for digital sovereignty (GWB procurement reform, BSI C3A framework, "Public Money, Public Code")

2.3 Cost & Licensing

• Total cost of ownership must be traceable by a single person without a licensing specialist
• No dependency on the client already owning a broader vendor suite to make the economics work
• Cost model must scale predictably with headcount/usage, not with bundling decisions made years earlier
• Budget must explicitly account for whatever is needed to reach the compliance bar in 2.2 — "free" is not a valid answer on its own

2.4 Operational

• Clear ownership of HA, backup, upgrade, and incident-response responsibilities
• A realistic support path (commercial SLA or in-house capability) for 2am failures
• Exit path / portability — avoid re-creating the lock-in this package is meant to price out

3. Comparison at a Glance

4. Recommendation Heuristic

1. Default to Entra ID only when the client's existing license estate already includes the required P-tier — otherwise the "low budget" premise breaks immediately.
2. Default to Keycloak (Red Hat build) when:
   • the client is a DACH public/state agency, or otherwise politically or contractually sensitive to US-vendor jurisdiction;
   • the client has no pre-existing Microsoft entitlement to lean on;
   • predictable, headcount-independent cost is a stated requirement of the package itself.
3. In both cases, budget explicitly for the compliance layer — Red Hat subscription and FIPS-enabled hosts on the Keycloak side; the correct P-tier and governance add-ons (not just "Entra ID") on the Microsoft side. Neither option is "free" once the compliance bar in Section 2.2 is taken seriously.