Keycloak und Authentik im Enterprise-IAM: Leitfaden für Zero Trust und Entra-ID-Exit

In einer modernisierten Unternehmensarchitektur hat das Identity and Access Management (IAM) längst die Rolle der traditionellen Firewall übernommen. Wenn Mitarbeiter, Partner, Microservices und API-Workloads standortunabhängig auf geschäftskritische Daten zugreifen, entscheidet die Identitätsschicht als zentraler Pfeiler der betrieblichen Netzwerksicherheit über die Integrität der gesamten Wertschöpfungskette.

Über das vergangene Jahrzehnt hinweg haben zahlreiche europäische Mittelständler und Konzerne diese Schlüsselkomponente nahezu vollständig in die Hände US-amerikanischer Cloud-Anbieter wie Microsoft Entra ID (ehemals Azure AD) oder Okta gelegt. Was als bequeme Nebenfunktion im Rahmen von Office-365-Einführungen begann, erweist sich in aktuellen Budget- und Sicherheitsaudits als erhebliches Klumpenrisiko.

Jede Benutzeranmeldung, jeder Token-Austausch zwischen internen Fachanwendungen und jede Rollenzuweisung ist untrennbar an die Verfügbarkeit und Preisgestaltung einer externen SaaS-Kontrollebene gekoppelt. Gleichzeitig zeigen verschärfte Vorgaben zur Prävention schwerwiegender Datenpannen, dass echte Digitale Souveränität bei der Hoheit über kryptografische Identitäten und Signaturschlüssel beginnt.

Mit dem unter dem Dach der Cloud Native Computing Foundation (CNCF) weiterentwickelten Enterprise-Standard Keycloak sowie der containerbasierten Plattform Authentik stehen heute zwei quelloffene IAM-Systeme bereit, die proprietären Cloud-Diensten technisch auf Augenhöhe begegnen. Dieser Leitfaden analysiert die Architektur beider Systeme und liefert das kaufmännische Entscheidungsmodell für CIOs und CISOs.

Die Ökonomie der Sicherheits-Paywall: Warum Entra ID P1/P2 und Okta Budgets sprengen

Um die wirtschaftliche Dynamik im Markt für Identitätsmanagement zu durchdringen, lohnt ein Blick auf die fein abgestufte Lizenzmechanik kommerzieller Identity-as-a-Service-Plattformen (IDaaS). Im Grundtarif (etwa Microsoft Entra ID Free) erhalten Unternehmen lediglich eine einfache Benutzerverwaltung und Basis-Logins, die modernen Compliance-Anforderungen im Enterprise-Umfeld kaum genügen.

Sobald die Informationssicherheit zeitgemäße Zero-Trust-Kontrollen einfordert, greift ein striktes kaufmännisches Feature-Gating. Kontextabhängige Zugriffsrichtlinien (Conditional Access nach Netzwerkzone, Gerätetyp oder Anmelderisiko), dynamische Gruppen und hybride Rückschreibefunktionen setzen zwingend das Upgrade auf Entra ID Plan 1 (rund 5,60 Euro pro Benutzer und Monat) voraus.

Wer darüber hinaus risikobasierte Echtzeit-Erkennung kompromittierter Sitzungen (Identity Protection), zeitgebundene Administrator-Rechtevergabe (Privileged Identity Management) oder regelmäßige Zugriffsrezertifizierungen für NIS-2-Audits benötigt, wird in Entra ID Plan 2 (rund 8,40 Euro monatlich pro Konto) oder vergleichbare Enterprise-Tarife von Okta gedrängt.

Diese Preisstruktur bestraft Unternehmen unmittelbar für die Erhöhung ihres Sicherheitsniveaus. Hinzu kommt ein gravierendes operatives Abhängigkeitsrisiko: Wenn die zentrale Cloud-Authentifizierungsebene durch eine Provider-Störung ausfällt, lassen sich oft selbst lokal im eigenen Rechenzentrum gehostete ERP- oder Produktionssysteme nicht mehr öffnen, weil der Token-Endpunkt im Internet nicht erreichbar ist.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cyber-Resilience im Enterprise-Einsatz, zu NIS-2 Vorstandshaftung im Enterprise-Einsatz sowie zu Cilium eBPF im Enterprise-Einsatz.

Technischer Deep-Dive: CNCF Keycloak (Quarkus-Engine) und Authentik im Architekturvergleich

Der Wechsel auf eine selbst oder in einer europäischen Cloud betriebene Open-Source-Identitätsplattform beseitigt diese künstliche Trennung zwischen Basisfunktion und Enterprise-Sicherheit. Sowohl Keycloak als auch Authentik stellen sämtliche Protokolle, Richtlinien-Engines und Hochverfügbarkeitsmechanismen direkt im quelloffenen Kernsystem bereit, setzen dabei jedoch unterschiedliche architektonische Schwerpunkte.

Keycloak unter Quarkus: Verteilte Infinispan-Caches, Multi-Site-HA und PKCS#11-HSM

Keycloak wurde ursprünglich von Red Hat initiiert und wird heute als herstellerneutrales Inkubationsprojekt der Cloud Native Computing Foundation (CNCF) gepflegt. Mit dem Architekturwechsel von WildFly auf die für Container und Kubernetes optimierte Java-Laufzeitumgebung Quarkus hat Keycloak einen enormen Sprung bei Startzeiten, Speichereffizienz und Transaktionsdurchsatz vollzogen.

Das Herzstück für den hochverfügbaren Großbetrieb bildet die integrierte Infinispan-Caching-Schicht. Während persistente Stammdaten wie Benutzerprofile, Realm-Konfigurationen und Rollenzuweisungen in einem fehlertoleranten PostgreSQL-Cluster (etwa mit Patroni und etcd-Quorum) liegen, hält Infinispan aktive Benutzersitzungen, Offline-Tokens und Login-Fehlerzähler im verteilten Arbeitsspeicher über alle Knoten hinweg synchron.

Über das JGroups-Protokoll (in Kubernetes meist via `DNS_PING` gesteuert) erkennen sich startende Keycloak-Pods automatisch und fügen sich unterbrechungsfrei in den Cluster-Verbund ein. Selbst bei georedundanten Aktiv-Aktiv-Bereitstellungen über zwei getrennte Rechenzentren hinweg stellt die Cross-Site-Replikation sicher, dass ein kompletter Standortausfall keinen angemeldeten Benutzer aus seiner Sitzung wirft.

„Digitale Souveränität entscheidet sich an der Hoheit über den privaten Signaturschlüssel: Wer die Ausstellung seiner OIDC- und SAML-Tokens an eine fremde Public Cloud delegiert, übergibt den Hauptschlüssel seiner gesamten IT-Architektur an Dritte.“

Für regulierte Branchen und KRITIS-Betreiber bietet Keycloak zudem eine tiefgreifende kryptografische Härtung. Über die standardisierte PKCS#11-Schnittstelle lassen sich dedizierte Hardware-Sicherheitsmodule (HSM) direkt im eigenen Rechenzentrum anbinden. Sämtliche RSA- oder ECDSA-Signaturoperationen für JSON Web Tokens (JWT) erfolgen dann ausschließlich im geschützten Krypto-Prozessor, ohne dass der private Schlüssel jemals den HSM-Speicher verlässt.

Authentik und das Outpost-Proxy-Paradigma für Legacy-Applikationen

Während Keycloak seine Stärken vor allem bei großen Mandantenstrukturen (Multi-Tenancy via Realms) und feingranularen OAuth-2.0-Erweiterungen wie User-Managed Access (UMA 2.0) ausspielt, adressiert Authentik ein besonders dringliches Praxisproblem gewachsener IT-Landschaften: die schnelle Absicherung älterer Bestandsanwendungen ohne eigenen Quellcode-Eingriff.

Architektonisch kombiniert Authentik einen in Python geschriebenen Steuerungskern (Server und Worker mit PostgreSQL- und Redis-Backend) mit hochperformanten, in Go implementierten sogenannten Outposts. Diese Outposts fungieren als leichtgewichtige Satelliten-Container, die entweder im zentralen Kubernetes-Cluster oder dezentral in abgetrennten Produktions- und DMZ-Netzsegmenten laufen.

Über den integrierten Reverse- und Forward-Auth-Proxy (koppelbar mit Traefik, NGINX, Envoy oder Caddy) schaltet sich ein Authentik-Outpost schützend vor ältere Webanwendungen, Fertigungssteuerungen oder Administrations-Oberflächen, die selbst weder OpenID Connect noch SAML 2.0 beherrschen. Der Outpost erzwingt vor dem ersten Zugriff eine starke Multi-Faktor-Authentifizierung und übergibt anschließend verifizierte HTTP-Header an das Altsystem.

Zugleich überzeugt Authentik durch eine visuelle Flow-Engine, mit der Sicherheitsarchitekten mehrstufige Anmelde- und Self-Service-Prozesse sowie kontextbasierte Richtlinien deklarativ als Code (Blueprints) versionieren und über GitOps-Pipelines ausrollen können. Neben dem Web-Proxy stellen die Go-Outposts bei Bedarf auch virtuelle LDAP- und RADIUS-Endpunkte für klassische VPN-Gateways und Switches bereit.

Protokoll-Exzellenz: OIDC, OAuth 2.1, SCIM 2.0 und FIDO2/WebAuthn-Passkeys

Eine zukunftssichere Zero-Trust-Architektur steht und fällt mit der konsequenten Einhaltung offener IETF-, W3C- und OpenID-Spezifikationen. Nur wenn Fachanwendungen über herstellerneutrale Protokolle angebunden sind, bleibt die Identitätsschicht dauerhaft portabel und frei von proprietären Lock-in-Effekten.

Im Zentrum moderner API- und Anwendungszugriffe stehen OpenID Connect (OIDC) 1.0 sowie OAuth 2.1. Beide Plattformen erzwingen den Authorization Code Flow mit PKCE (Proof Key for Code Exchange), was das Abgreifen von Autorisierungscodes verhindert. Für Hochsicherheits-Schnittstellen unterstützt Keycloak zudem das Financial-grade API (FAPI)-Profil inklusive Mutual TLS (mTLS) Sender-Constrained Tokens und DPoP.

Um die Angriffsfläche durch Passwortdiebstahl und Echtzeit-Reverse-Proxy-Phishing (etwa durch Evilginx-Frameworks) technisch zu schließen, setzen Keycloak und Authentik nativ auf den W3C-WebAuthn- und FIDO2-Standard. Mitarbeiter und Administratoren registrieren kryptografische Hardware-Token (wie YubiKey 5 oder Nitrokey 3) oder gerätegebundene Passkeys als zweiten Faktor oder für den passwortlosen Login.

Da FIDO2-Signaturen kryptografisch an die exakte Ursprungs-Domain (Origin) des eigenen Identity Providers gebunden sind, läuft jeder Phishing-Versuch über täuschend echte Fake-Domains ins Leere. Ergänzt wird dies durch SCIM 2.0 (System for Cross-domain Identity Management), worüber Benutzerkonten und Gruppen vollautomatisch an Zielsysteme provisioniert und beim Mitarbeiteraustritt binnen Sekunden gesperrt werden.

IdP-Brokering: Der architektonische Hebel zur Entschärfung der Microsoft-Lizenzfalle

In Vorstandspräsentationen taucht regelmäßig die Frage auf, warum ein Unternehmen einen eigenen Identity Provider aufbauen sollte, wenn ohnehin Microsoft 365 für E-Mail und Kollaboration genutzt wird. Genau hier entfaltet das architektonische Muster des Identity Brokerings (IdP-Chaining) seine enorme wirtschaftliche Hebelwirkung.

Ein Unternehmen muss Microsoft 365 keineswegs ablösen, um die Kostenfalle von Entra ID P1 und P2 zu verlassen. Statt Entra ID als oberste Identitätswurzel für das gesamte Unternehmen einzusetzen, wird die Hierarchie umgekehrt: Keycloak oder Authentik fungiert als primärer, souveräner Identity Provider (Root IdP), während der Microsoft-365-Tenant per SAML 2.0 oder WS-Federation als nachgelagerter Dienst angebunden wird.

Öffnet ein Mitarbeiter Outlook oder Teams, verweist Microsoft die Sitzung zur Authentifizierung an den unternehmenseigenen Keycloak-Cluster. Dort finden sämtliche Zero-Trust-Prüfungen statt: die Auswertung der Quell-IP, die Prüfung des Gerätezertifikats und die FIDO2-Passkey-Freigabe. Erst nach bestandener Prüfung übergibt Keycloak ein signiertes SAML-Token, mit dem Microsoft den Zugriff gewährt.

Der kaufmännische Effekt ist durchschlagend: Da Conditional Access, Multi-Faktor-Authentifizierung, Passwort-Self-Service und Single Sign-On für alle übrigen 50 oder 200 Unternehmensanwendungen vollständig auf dem eigenen Open-Source-Cluster laufen, genügt auf Seiten von Microsoft die kostenfreie Basisschicht. Zudem bleiben sämtliche internen Fachsysteme selbst bei einem Komplettausfall der Microsoft-Cloud lokal erreichbar.

Architektur- und Lizenzvergleich: Entra ID / Okta versus CNCF Keycloak und Authentik

Für eine belastbare Entscheidungsvorlage im Architektur- und Einkaufsgremium müssen Lizenzmechanik, Betriebsresilienz und Protokollreife im direkten Vergleich bewertet werden. Die folgende Bloomberg-Radar-Matrix stellt kommerzielle IDaaS-Angebote (Microsoft Entra ID P2 / Okta) dem souveränen Enterprise-Stack aus CNCF Keycloak und Authentik gegenüber:

In der architektonischen Praxis gilt eine klare Empfehlung: CNCF Keycloak ist die erste Wahl für Organisationen mit 2.500 bis über 500.000 Identitäten, komplexen föderierten B2B-Partnerportalen, strengen PKCS#11-HSM-Vorgaben und Bedarf an kommerziellen Enterprise-SLAs (etwa über Red Hat build of Keycloak oder spezialisierte europäische Systemhäuser).

Authentik spielt seine Trümpfe vor allem dort aus, wo Infrastruktur-Teams eine moderne, deklarative Verwaltungsoberfläche suchen und über die Go-Outposts zahlreiche heterogene Bestandsanwendungen, interne Dashboards und Netzwerkinfrastrukturen ohne aufwendige Programmierung unter einem einheitlichen Zero-Trust-Portal zusammenführen wollen.

Vollkostenrechnung über 60 Monate: Entra ID P2 versus souveräner Enterprise-IAM-Cluster

Um die finanziellen Auswirkungen für den CFO präzise zu beziffern, betrachten wir ein repräsentatives mittelständisches Unternehmen mit 3.500 aktiven Identitäten (davon 2.000 Büroarbeitsplätze, 1.000 gewerbliche Schicht- und Produktionsmitarbeiter sowie 500 externe Partner-Accounts mit Portalzugriff).

Sollen im Rahmen einer konsequenten Zero-Trust- und NIS-2-Umsetzung alle 3.500 Konten durch risikobasierten Conditional Access, FIDO2-Hardware-Richtlinien und Access-Reviews geschützt werden, fallen unter Microsoft Entra ID P2 (oder vergleichbaren Okta-Plänen) monatlich rund 8,00 Euro pro Nutzer an. Dies summiert sich auf 336.000 Euro pro Jahr bzw. 1,68 Millionen Euro über fünf Jahre (60 Monate).

Demgegenüber erfordert der Aufbau eines georedundanten Keycloak- oder Authentik-Clusters (verteilt über zwei Brandabschnitte inklusive PostgreSQL-HA-Cluster) im ersten Jahr ein einmaliges Projektbudget von rund 55.000 Euro für Architektur-Design, IdP-Föderation und FIDO2-Rollout. Die laufenden Jahreskosten für Infrastruktur, Enterprise-Support und Betriebsführung betragen rund 38.000 Euro.

Über 60 Monate belaufen sich die Gesamtkosten der souveränen Architektur damit auf lediglich 245.000 Euro. Das Unternehmen erzielt eine Netto-Einsparung von über 1,4 Millionen Euro (rund 85 Prozent TCO-Reduktion) und erreicht den Break-even bereits nach vier Monaten. Weiterführende Berechnungen bietet unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und Compliance nach NIS-2 und BSI ORP.4

Da der zentrale Identity Provider zu den kritischsten Tier-0-Diensten eines Unternehmens zählt, muss das Bereitstellungsmodell exakt zur vorhandenen Plattform- und Sicherheitskompetenz der internen IT-Organisation passen. In der europäischen Unternehmenspraxis haben sich drei klar abgegrenzte Betriebsmodelle bewährt.

Erstens (Eigenbetrieb auf Kubernetes): Organisationen mit einem erfahrenen DevOps- und Linux-Team betreiben Keycloak oder Authentik über offizielle Kubernetes-Operatoren auf ihrer eigenen Virtualisierungs- oder Container-Plattform. Die Konfiguration wird deklarativ über OpenTofu verwaltet, ergänzt durch einen Support-Rahmenvertrag mit einem spezialisierten Open-Source-Systemhaus.

Zweitens (Managed-IAM im EU-Cluster): Mittelständler, die keine eigene 24/7-Rufbereitschaft für Datenbank-Failover und Infinispan-Clustering vorhalten möchten, beziehen eine dedizierte Keycloak- oder Authentik-Instanz bei einem zertifizierten europäischen Cloud-Anbieter auf Basis des Sovereign Cloud Stack (SCS). Der Betreiber garantiert 99,99 Prozent Verfügbarkeit nach ISO 27001 und BSI C5 unter deutscher Gerichtsbarkeit.

Drittens (Hybride IdP-Föderation): Konzerne mit gewachsenen Active-Directory-Domänen und mehrjährigen Lizenzverträgen starten mit einer vorgeschalteten Broker-Architektur. Keycloak synchronisiert die bestehenden AD-Konten über LDAPS/Kerberos, übernimmt sofort das Single Sign-On für alle neuen Fachanwendungen und löst proprietäre Cloud-Zusatzlizenzen schrittweise zum Vertragsende ab.

Gleichzeitig erfüllt diese Architektur zentrale gesetzliche Sorgfaltspflichten: Artikel 21 Absatz 2 Buchstabe j der NIS-2-Richtlinie (EU 2022/2555) verlangt zwingend den Einsatz starker Multi-Faktor-Authentifizierung, während der BSI IT-Grundschutz-Baustein ORP.4 eine lückenlose Nachvollziehbarkeit sämtlicher Rechtevergaben ohne Drittland-Telemetrieabfluss vorschreibt.

Der 4-Phasen-Umsetzungsfahrplan: Unterbrechungsfreie Migration zum souveränen IAM

Der Umbau der Identitätsarchitektur darf niemals im riskanten Stichtagsverfahren erfolgen. Ein strukturierter Vier-Phasen-Fahrplan über sechs Monate stellt sicher, dass sich für Endanwender der gewohnte Anmeldeablauf kaum verändert, während im Hintergrund die technologische Souveränität aufgebaut wird.

Phase 1 (Monat 1): Identitäts-Inventur, Protokoll-Audit und Realm-Architektur

Zu Beginn erfasst das Projektteam sämtliche angebundenen Applikationen, Active-Directory-Gruppenstrukturen, Service-Konten und bestehenden SAML-2.0- oder OIDC-Vertrauensstellungen. Darauf aufbauend wird das logische Datenmodell (Realm-Aufteilung, Token-Lebensdauern und Rollen-Claims) verbindlich als Infrastructure-as-Code spezifiziert.

Phase 2 (Monat 2): Hochverfügbarer Cluster-Aufbau und Verzeichnis-Föderation

Auf der Zielplattform wird der redundante Keycloak- oder Authentik-Cluster inklusive PostgreSQL-Patroni-Datenbank, Infinispan-Session-Replikation und SIEM-Log-Streaming in Betrieb genommen. Anschließend erfolgt die schreibgeschützte oder bidirektionale Kopplung mit dem bestehenden Active Directory über gesicherte LDAPS-Kanäle ohne Passwort-Reset.

Phase 3 (Monat 3 bis 4): App-Onboarding, Outpost-Rollout und FIDO2-Passkey-Einführung

In wöchentlichen Wellen werden zunächst interne Fachanwendungen, Entwicklungsplattformen und VPN-Gateways auf den neuen OIDC-Endpunkt umgestellt, während ältere Web-Applikationen über Authentik-Outposts geschützt werden. Parallel registrieren Administratoren und Pilotabteilungen ihre FIDO2-Hardware-Sicherheitsschlüssel und Passkeys im Self-Service-Portal.

Phase 4 (Monat 5 bis 6): IdP-Brokering für M365, SCIM-Automatisierung und Lizenz-Downgrade

Im letzten Schritt wird der Microsoft-365-Tenant per Föderation als nachgelagerter Dienst an den souveränen Haupt-IdP gekoppelt und das automatisierte Provisioning über SCIM 2.0 aktiviert. Sobald alle Conditional-Access-Richtlinien stabil auf dem eigenen Cluster laufen, werden die teuren Entra-ID-P1/P2-Zusatzlizenzen fristgerecht abbestellt.

Fünf Kontrollfragen für Vorstand, CISO und Enterprise-Architekten

1. Bleiben unsere internen Kernanwendungen arbeitsfähig, wenn die Internetverbindung zur US-Cloud ausfällt?

Prüfen Sie im Rahmen einer Notfallübung, welche lokalen Produktions-, ERP- oder Dokumentensysteme heute zwingend einen Token-Austausch mit Microsoft Entra ID oder Okta im Internet voraussetzen. Nur ein lokal oder im europäischen Rechenzentrum erreichbarer Identity-Cluster garantiert, dass ein globaler Cloud-Ausfall nicht zum sofortigen Betriebs-Stillstand im eigenen Werk führt.

2. Wie hoch ist der reale Fünfjahres-Aufpreis für Conditional Access und FIDO2 über alle Mitarbeiter- und Schichtkonten?

Lassen Sie sich vom Einkauf ausrechnen, welche Gesamtkosten entstehen, wenn im Zuge der NIS-2-Umsetzung auch gewerbliche Mitarbeitende, Zeitarbeitskräfte und externe Lieferanten mit P1- oder P2-Lizenzen ausgestattet werden müssen. In fast allen Fällen übersteigen bereits zwei Jahresgebühren dieser Zusatzlizenzen die kompletten Aufbau- und Betriebskosten eines hochverfügbaren Open-Source-IAM-Clusters.

3. Wer besitzt die physische und rechtliche Gewalt über die privaten Token-Signaturschlüssel?

Klären Sie mit Ihrem Informationssicherheitsbeauftragten, ob Ihre OIDC- und SAML-Signaturschlüssel in einer geteilten Public-Cloud-Infrastruktur liegen oder durch eigene Hardware-Sicherheitsmodule (PKCS#11-HSM) unter europäischer Hoheit geschützt werden. Wer den Signaturschlüssel kontrolliert, kann technisch jedes beliebige Administrator-Token für Ihre gesamte Infrastruktur ausstellen.

4. Sind unsere Fachanwendungen über offene Standards oder über proprietäre Hersteller-APIs angebunden?

Verpflichten Sie Software-Lieferanten und interne Entwicklungsteams konsequent auf die Nutzung von standardkonformem OpenID Connect 1.0, OAuth 2.1 und SCIM 2.0 statt proprietärer Graph-APIs. Für ältere Bestandssoftware ohne moderne Schnittstellen sollten standardisierte Forward-Auth-Outposts wie in Authentik eingeplant werden, um Code-Abhängigkeiten dauerhaft zu vermeiden.

5. Ist unsere MFA-Strategie gegen moderne Echtzeit-Reverse-Proxy-Phishing-Angriffe gewappnet?

Herkömmliche sechsstellige Einmalpasswörter (SMS, E-Mail oder einfache TOTP-Apps) sowie ungeschützte Push-Benachrichtigungen werden heute von Angreifern automatisiert in Echtzeit abgefangen und weitergeleitet. Stellen Sie sicher, dass Ihr Identity Provider für alle privilegierten Konten und Fernzugriffe zwingend kryptografisch origin-gebundene FIDO2/WebAuthn-Passkeys oder Hardware-Tokens durchsetzt.

Strategisches Fazit: Identitätshoheit als Fundament echter Zero-Trust-Architekturen

Das Identity and Access Management ist weit mehr als ein austauschbares Verzeichniswerkzeug; es bildet den kryptografischen Vertrauensanker jeder modernen IT-Infrastruktur. Unternehmen, die ihre gesamte Zugriffssteuerung an proprietäre US-Cloud-Dienste knüpfen, begeben sich nicht nur in eine permanente Preisspirale aus P1- und P2-Zusatzlizenzen, sondern akzeptieren zugleich einen strukturellen Single Point of Failure außerhalb ihres eigenen Rechtsraums.

Mit CNCF Keycloak und Authentik stehen zwei technisch ausgereifte, im Großbetrieb bewährte Open-Source-Plattformen bereit, die durch IdP-Brokering eine sanfte, risikofreie Entkopplung ermöglichen. Wer diesen Architekturwechsel jetzt strukturiert einleitet, senkt seine laufenden Lizenzkosten um über 75 Prozent, härtet seine Organisation mit FIDO2-Passkeys und HSM-Kryptografie gegen Phishing ab und erfüllt die strengen Nachweispflichten von NIS-2 und BSI IT-Grundschutz aus eigener souveräner Kraft.

Häufig gestellte Fragen (FAQ) zu Keycloak, Authentik und Enterprise-IAM