Self-Hosting Your Identity Provider: Sovereignty and Security Trade-offs (2026)

TL;DR

• A self-hosted identity provider gives you data sovereignty, deep customization, and predictable licensing — at the cost of running, patching, and securing it yourself.
• Keycloak is the incumbent for good reasons: mature, certified, huge ecosystem. Authentik is a lighter, more modern self-host option. Both are excellent classical IdPs.
• The real differentiators in 2026 are not raw feature count: they are post-quantum signing, mandatory hardware attestation, and EU operation — which is where CAI-AUTH is positioned.
• Managed (SaaS) wins when you lack the ops capacity or 24/7 on-call to run an internet-facing root of trust. Be honest about which camp you are in.

What is a self-hosted identity provider?

A self-hosted identity provider is an authentication and single sign-on server that you deploy and operate on infrastructure you control — your own servers, your own cloud tenancy, or an on-prem datacenter — rather than consuming it as a vendor’s SaaS. You own the database, the signing keys, the upgrade cadence, and the security perimeter. In exchange for that control and data sovereignty, you accept the operational responsibility of keeping an internet-facing root of trust patched, monitored, and highly available.

That trade-off — control and sovereignty versus operational burden — is the entire decision. This article walks through it fairly, then puts three self-hostable OIDC providers side by side on a neutral matrix: Keycloak, Authentik, and CAI-AUTH.

Why self-host an IdP at all?

Three motivations dominate, and they are all legitimate:

• Sovereignty and data residency. Your identity provider is your perimeter. Every login, session, and token decision flows through it. Keeping that under your own legal and physical control matters when you are subject to GDPR, NIS2, or DORA, or when you simply do not want a third country’s legal process reaching your authentication data. We cover the legal exposure in depth in EU sovereign identity vs the US CLOUD Act.
• Cost predictability. Per-monthly-active-user (MAU) pricing on managed IdPs scales with your success. Self-hosting converts that into a fixed infrastructure-plus-staff line item. For large user bases the math often favors self-hosting; for small ones it usually does not.
• Customization and integration depth. Self-hosting lets you reach into theming, custom flows, federation quirks, and protocol edge cases that managed tiers gate behind enterprise plans or simply do not expose.

If none of those three apply strongly to you, self-hosting is probably the wrong default — and we say so plainly in the “when managed beats self-host” section.

The hidden operational cost

The brochure version of self-hosting is “download, deploy, done.” The reality is that an IdP is a root of trust, and running one well is closer to running a small bank vault than a stateless web app. The hidden costs:

• 24/7 availability. If the IdP is down, everything federated to it is down. You need redundancy, health checks, and a tested failover story.
• Patching velocity. Auth servers are high-value targets. CVEs in your IdP, its runtime, and its dependencies need fast, tested patch cycles.
• Key management. Signing keys must be generated, rotated, backed up, and protected — ideally in an HSM or a hardware-backed keystore. A leaked signing key is a total compromise.
• Audit and logging. Compliance regimes expect tamper-evident, queryable audit trails of authentication events, not just application logs.
• Upgrade migrations. Major-version upgrades of a stateful IdP (realm/schema migrations) are real projects, not apt upgrade.

How to read this diagram: This decision tree separates the “should I self-host” question from the “which product” question, because conflating them is the most common mistake teams make. It starts by testing whether your motivations (sovereignty, customization, cost) are real, then gates self-hosting behind two hard operational capabilities: round-the-clock availability and disciplined key management plus patching. If you cannot meet those gates, the honest answer is to start managed and build operational maturity before taking custody of a root of trust. Only teams that pass both gates reach the final node — choosing a self-hosted product on the criteria that actually matter in 2026.

Comparison matrix: Keycloak vs Authentik vs CAI-AUTH

Let us be fair about the incumbents first. Keycloak (a Red Hat / CNCF-adjacent project) is the default self-hosted IdP for a reason: it is mature, battle-tested, OpenID-certified, supports a vast protocol surface (OIDC, OAuth 2.x, SAML, LDAP/Kerberos federation), has a deep extension ecosystem, and an enormous community. If your requirement is “a proven, fully featured classical IdP I can run myself,” Keycloak is hard to beat — see the Keycloak documentation. Authentik is a newer, Python-based self-hosted provider with a cleaner admin UX, flexible flow builder, and a lighter footprint; it is an excellent choice for teams who find Keycloak heavy — see the Authentik documentation.

CAI-AUTH does not compete on raw feature count, and we will not pretend otherwise. It is a standalone identity provider written in Rust on the axum framework — not a Keycloak fork, plugin, or distribution. Its differentiators are narrow and specific: post-quantum signing, mandatory hardware attestation, and EU operation. CAI Technology is not a government authority.

How to read this diagram: This matrix lines up the three providers across the five criteria that drive a 2026 self-host decision, so you can see exactly where each one leads and trails. Keycloak and Authentik are both strong, permissively-or-openly licensed classical IdPs that you can run on any infrastructure, including EU soil — their gap is post-quantum signing, which neither ships today. CAI-AUTH trails on breadth and ecosystem maturity but leads on the three narrow axes it was built for: post-quantum-signed tokens (composite CAI-PQ-HYBRID-87-Ed25519), attestation that is mandatory rather than optional, and operation inside the EU by design. The point of the matrix is not to declare a winner but to make the trade-off legible: choose feature breadth and ecosystem, or choose forward-looking cryptography and EU sovereignty, depending on what your threat model and regulators demand.

A few honest clarifications on that matrix:

• PQ signing. CAI-AUTH issues OIDC tokens signed with a composite ML-DSA-87 + Ed25519 signature (alg id CAI-PQ-HYBRID-87-Ed25519), following draft-ietf-lamps-pq-composite-sigs. Keycloak and Authentik are excellent classical IdPs but do not ship post-quantum token signing today. If “harvest now, forge later” is in your threat model, that gap matters; if it is not yet, it does not.
• Hardware attestation. Authentik and Keycloak support WebAuthn/FIDO2, which is hardware-backed but not always attested. CAI-AUTH makes hardware attestation (Android StrongBox / TEE) mandatory, rejecting rooted or emulated devices outright. The distinction between hardware-backed and attestation-enforced is the whole point of phishing-resistant MFA — without attestation, “passwordless” still trusts a possibly-compromised device.
• Certification. When you evaluate any IdP, check whether it appears on the OpenID certification list for the profiles you need. Certification is a real, verifiable trust signal.

Security considerations when you self-host

Whichever product you pick, self-hosting moves these responsibilities onto your team. Hold your deployment to a recognized baseline — the OWASP Application Security Verification Standard (ASVS) is the right yardstick — and pay particular attention to:

• Signing-key custody. Store keys in an HSM or hardware-backed keystore; never on the application filesystem in plaintext. Define rotation and revocation procedures before you go live.
• Tamper-evident audit. Application logs are not an audit trail. Look for append-only, cryptographically chained event logging (CAI-AUTH uses a BLAKE3 Merkle chain) so that a compromise of the host cannot silently rewrite history.
• Supply-chain integrity. Verify build provenance (SLSA attestations, signed releases) so the binary you run is the one that was built from reviewed source.
• Network exposure. An IdP should expose the minimum surface: discovery, token, JWKS, and authorize endpoints — admin and introspection planes should be segregated.

When managed beats self-host

Self-hosting is not a virtue in itself. Choose a managed provider when:

• You do not have 24/7 on-call and cannot guarantee fast incident response on an internet-facing root of trust.
• Your user base is small enough that per-MAU pricing is cheaper than the fully-loaded cost of staff plus infrastructure plus risk.
• You lack the in-house skill to do HSM-grade key management and tested upgrade migrations.
• You need to ship this quarter and cannot absorb a multi-week IdP deployment project.

A reasonable middle path exists: an EU-operated managed offering of a self-hostable product, which gives you sovereignty and a clean migration path to self-hosting later without re-platforming your relying parties. If you are weighing this against US incumbents, the decision-stage comparison in Okta and Auth0 alternatives for EU companies maps the field.

You can inspect CAI-AUTH’s live OIDC surface at auth.caitech.ro or grab the self-host build from the download page to evaluate it on your own infrastructure.

FAQ

What is the best self-hosted identity provider?

There is no single “best” — it depends on your priorities. Keycloak is the most mature and broadly certified choice for classical, full-feature SSO. Authentik suits teams wanting a lighter, modern alternative. CAI-AUTH fits teams whose priorities are post-quantum signing, mandatory hardware attestation, and EU operation rather than maximum feature breadth.

Is Keycloak the only option?

No. Keycloak is the incumbent and an excellent default, but it is one of several self-hostable identity providers. Authentik offers a lighter, more modern alternative, and CAI-AUTH offers a post-quantum, EU-operated option. The right pick depends on whether you optimize for feature breadth and ecosystem, or for forward-looking cryptography and sovereignty.

Can a self-hosted IdP be post-quantum?

Yes. A self-hosted provider can sign its OIDC tokens with post-quantum algorithms. CAI-AUTH does this today using a composite ML-DSA-87 plus Ed25519 signature following the IETF composite-signatures draft, so tokens remain verifiable against classical primitives during the transition while gaining post-quantum protection for the signing root of trust.

Does self-hosting an IdP improve data sovereignty?

It can, but hosting location alone is not sovereignty. Sovereignty depends on who can legally compel access to your data and operations, not just where the servers sit. Self-hosting on infrastructure you control inside your own jurisdiction, with an EU-operated provider, is the strongest combination — covered in detail in our CLOUD Act analysis.

Ready to compare on your own terms? Explore the live post-quantum OIDC discovery document at auth.caitech.ro, or download the self-host build and run it against your own relying parties.

Legal entity: CAI TECHNOLOGY SRL, CUI 50512457.