Authentik 2026.8: PAM, geplantes Offboarding und der Rust-Rewrite

Authentik 2026.8 ist am 18. August 2026 erschienen und es ist das erste große Release im neuen Drei-Monats-Zyklus. Entsprechend viel steckt drin: Privileged Access Management mit Antrag und Genehmigung, geplantes Offboarding zu einem festen Zeitpunkt, ein Rust-Rewrite von Server und Proxy Outpost, Connection Pooling für PostgreSQL und mehrere OAuth-2.0-Erweiterungen. Dazu drei Breaking Changes, von denen einer im Betrieb leicht übersehen wird und dann Richtlinien stillschweigend aushebelt. Dieser Beitrag ordnet ein, was neu ist, was davon Enterprise verlangt und was vor dem Upgrade geprüft gehört.

Auch interessant: Authentik-Sicherheitslage im Sommer 2026 · NIS2: MFA und Zugriffskontrolle mit Authentik · Account Lockdown in 2026.5

Inhaltsverzeichnis

• Der Release im Überblick
• Privileged Access Management: der eigentliche Neuzugang
• Geplantes Offboarding
• Der Rust-Rewrite
• Drei Breaking Changes, einer davon heimtückisch
• Was sonst noch drinsteckt
• Upgrade-Reihenfolge
• Was das für authhost-Kunden bedeutet
• Fazit
• Quellen

Der Release im Überblick

Der Tag version/2026.8.0 wurde am 18. August 2026 veröffentlicht [2]. Es ist das erste Release nach der Umstellung auf einen Drei-Monats-Zyklus [4], die wir in der Sicherheitslage im Sommer 2026 beschrieben haben, und die Menge an Neuerungen entspricht diesem Rhythmus.

Die wichtigsten Punkte aus den Release Notes [1]:

Privileged Access Management: der eigentliche Neuzugang

Die inhaltlich größte Erweiterung ist PAM. Nutzer können Zugriff auf Anwendungen und Entitlements beantragen; benannte Genehmiger können freigeben oder ablehnen und dabei festlegen, wann der Zugriff wieder abläuft [1].

Warum das mehr ist als Bequemlichkeit: Der übliche Umgang mit erhöhtem Zugriff ist die dauerhafte Gruppenmitgliedschaft. Jemand braucht einmal Zugriff auf ein System, wird in die Gruppe aufgenommen und bleibt dort, weil niemand einen Anlass hat, ihn wieder zu entfernen. Nach zwei Jahren hat die Gruppe dreißig Mitglieder, von denen zehn den Zugriff nie wieder gebraucht haben.

Befristeter, beantragter Zugriff dreht das um: Der Normalzustand ist kein Zugriff, die Ausnahme wird protokolliert und läuft von selbst aus. Für die Zugriffskontrolle nach NIS2, die wir in einem eigenen Beitrag behandelt haben, ist das der praktisch relevanteste Baustein seit Langem.

Der Haken: PAM ist in den Release Notes als Enterprise gekennzeichnet [3]. Wer die Community Edition betreibt, bekommt die Funktion nicht. Das gehört vor die Planung, nicht danach.

Geplantes Offboarding

Die zweite Neuerung ist unspektakulär und im Alltag vermutlich nützlicher. Administratoren können einen Nutzer für einen bestimmten Zeitpunkt zur Deaktivierung oder Löschung vormerken, wahlweise samt Widerruf der Sitzungen und Tokens. Geplante Offboardings lassen sich vor der Ausführung prüfen und abbrechen [1].

Der Anwendungsfall ist offensichtlich, sobald man ihn einmal gesehen hat: befristete Verträge, Praktika, externe Dienstleister mit Projektende. Das Enddatum ist zum Zeitpunkt der Anlage bekannt. Bisher musste es jemand im Kalender führen und am letzten Tag daran denken. Jetzt wird es beim Anlegen gesetzt.

Diese Funktion trägt keine Enterprise-Kennzeichnung in den Release Notes.

Der Rust-Rewrite

Der authentik-Server als Eingangspunkt für Anfragen und der Proxy Outpost waren zuvor in Go geschrieben und sind jetzt in Rust umgesetzt; das Projekt beschreibt die Umsetzung als 1:1-Entsprechung zum vorherigen Code [1].

Für Betreiber ist das erst einmal unsichtbar. Es ist eine Grundlagenänderung, kein Funktionsgewinn, und in den Release Notes steht keine versprochene Verbesserung bei Durchsatz oder Speicherverbrauch, die man zitieren könnte.

Trotzdem gehört der Punkt auf den Prüfplan, und zwar aus einem einfachen Grund: Diese Komponente steht an der Stelle, an der jede Anfrage vorbeikommt. Eine als 1:1 beschriebene Neuimplementierung ist ein sorgfältiger Anspruch, aber sie ersetzt keinen Testlauf mit der eigenen Konfiguration. Wer eigene Header, ungewöhnliche Proxy-Ketten oder ausgefallene Outpost-Konfigurationen fährt, sollte das vor dem Produktivbetrieb einmal durchspielen.

Drei Breaking Changes, einer davon heimtückisch

Die Release Notes nennen drei Änderungen mit Bruchpotenzial [1].

1. hash_password nimmt kein Positionsargument mehr. Der Management-Befehl akzeptiert das Passwort nicht mehr als Argument auf der Kommandozeile. Wer das in einem Skript nutzt, muss es umstellen. Der Grund ist ohnehin einleuchtend: Passwörter auf der Kommandozeile landen in der Shell-History und in der Prozessliste.

2. „Prevent duplicate devices" ist weg. Die Option der WebAuthn-Authenticator-Setup-Stage wurde entfernt. Die Begründung ist bemerkenswert offen: Sie verglich Attestierungszertifikate, die Hersteller bewusst über ganze Produktionschargen hinweg teilen [1]. Die Funktion konnte also nie zuverlässig leisten, was ihr Name versprach. Wer sich darauf verlassen hat, hat sich auf etwas verlassen, das nicht funktionierte.

3. Forwarded-Header nur noch von vertrauenswürdigen Proxys. Das ist der Punkt, der im Betrieb Ärger macht. authentik verwendet weitergereichte Anfrage-Header nur noch, wenn die Verbindung aus einem vertrauenswürdigen Proxy-Netz kommt [1]. Vor dem Upgrade ist zu prüfen, ob der Reverse Proxy die erforderlichen Header setzt und ob jede Adresse und jedes Netz, von dem aus er direkt zu authentik verbindet, in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS eingetragen ist [1].

Wird das übersehen, fällt der Fehler nicht sofort auf. authentik läuft weiter, sieht aber die IP des Proxys statt die des Clients. Geo-Richtlinien, IP-Allow-Lists und Anomalie-Erkennung bewerten dann alle Anfragen gleich, weil sie alle aus demselben Netz zu kommen scheinen. Das ist eine stille Verschlechterung der Sicherheitslage, kein Ausfall.

Was sonst noch drinsteckt

Kürzer, aber erwähnenswert [1]:

• Objekt-Attribute: eigene Text-, Zahl- und Boolean-Felder für Nutzer, Gruppen und weitere Objekte, mit Validierung.
• Verschachtelte LDAP-Gruppen: LDAP-Quellen können die Gruppenhierarchie des Quellverzeichnisses erhalten, statt sie flach zu ziehen. Wer aus einem Active Directory synchronisiert, kennt das Problem.
• OAuth-2.0-Erweiterungen: Token Exchange, On-behalf-of-Delegation, dynamische Client-Registrierung und Key Binding für ID-Tokens.
• Selbst gehostete Event-Karte: Die Ereigniskarte nutzt jetzt eine mitgelieferte Basiskarte und stellt standardmäßig keine externen Anfragen mehr. Ein kleiner, aber sauberer Datenschutzgewinn: Bisher verließ jede Kartendarstellung im Admin-Bereich die eigene Installation.
• Connection Pooling: Unterstützung für einen PostgreSQL-Pooler im Transaction-Mode neben einer separaten direkten Verbindung für Operationen, die eine stabile Sitzung brauchen.

Upgrade-Reihenfolge

1. Release Notes lesen, insbesondere den Abschnitt zu den Breaking Changes [1].
2. AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS setzen, bevor aktualisiert wird, nicht danach.
3. Skripte prüfen, die hash_password mit Positionsargument aufrufen.
4. Auf einer Kopie testen, mit besonderem Blick auf Proxy-Ketten, Outposts und eigene Header. Der Rust-Rewrite betrifft genau diesen Pfad.
5. Prüfen, ob Geo- oder IP-basierte Richtlinien nach dem Upgrade noch die Client-IP sehen. Ein Blick in die Ereignisse genügt.
6. Erst dann produktiv fahren.

Was das für authhost-Kunden bedeutet

Wir betreiben Authentik als dedizierte Instanz und fahren Versionswechsel mit Ankündigung und Wartungsfenster. Für 2026.8 heißt das konkret: Die Trusted-Proxy-Konfiguration ist bei uns Teil des Upgrades, nicht Ihre Hausaufgabe, und der Rust-Rewrite wird vorher auf einer Kopie gefahren.

Der Preis ergibt sich aus Instanzgröße und Support-Stufe. In der Region Deutschland kostet die Größe S 99,90 € im Monat netto mit 2 vCPU, 4 GB RAM und 80 GB NVMe, M 149,90 € und L 249,90 €. Die Support-Stufe Business kostet 100 € Aufschlag, Priority 150 € und Enterprise 350 €. Die Instanz ist dediziert, Nutzer werden nicht nach Stückzahl abgerechnet.

Zur Ehrlichkeit gehört: PAM und Agent Accounts sind Enterprise-Funktionen von authentik selbst [3]. Managed Hosting ändert daran nichts, das ist eine Lizenzfrage zwischen Ihnen und Authentik Security. Wir sagen Ihnen aber vorher, was in Ihrer Edition enthalten ist, statt Sie das nach dem Upgrade herausfinden zu lassen.

Der Test läuft 7 Tage. Für die Anmeldung ist eine Kreditkarte erforderlich, und nach Ablauf geht der Test automatisch in das gewählte kostenpflichtige Abo über.

Preise ansehen · Managed Authentik ansehen

Fazit

2026.8 ist ein Release, das sich lohnt. PAM schließt eine echte Lücke in der Zugriffskontrolle, geplantes Offboarding beseitigt eine der zuverlässigsten Fehlerquellen im Nutzer-Lebenszyklus, und die selbst gehostete Event-Karte ist ein kleiner, aber richtiger Schritt.

Zwei Dinge gehören dazu. PAM und Agent Accounts sind Enterprise, das entscheidet für viele Installationen, ob der Release überhaupt bringt, was ihn interessant macht. Und die Trusted-Proxy-Änderung ist genau die Sorte Breaking Change, die nicht laut ausfällt, sondern leise die Wirkung von Richtlinien aufhebt. Wer sie vor dem Upgrade setzt, hat ein ruhiges Wartungsfenster.

authhost ist ein unabhängiger Managed-Hosting-Anbieter und steht in keiner Verbindung zu Authentik Security, Inc. „authentik" ist eine Marke der jeweiligen Rechteinhaber. Angaben zu Editionen und Funktionsumfang folgen der offiziellen Dokumentation und können sich mit neuen Versionen ändern; maßgeblich ist die Dokumentation des Projekts. Dieser Beitrag ersetzt keine Rechtsberatung.

Quellen

• [[1]] authentik Release Notes 2026.8 – PAM, Agent Accounts, geplantes Offboarding, Konten-Wechsel, Objekt-Attribute, verschachtelte LDAP-Gruppen, Rust-Rewrite, Connection Pooling, Breaking Changes
• [[2]] goauthentik/authentik · Release version/2026.8.0 auf GitHub (veröffentlicht 18.08.2026)
• [[3]] authentik Release Notes 2026.8 – Enterprise-Kennzeichnung von Privileged Access Management und Agent Accounts
• [[4]] authentik Dokumentation – Übersicht der Releases
• authhost.de – Managed Authentik Hosting