diff --git a/README.md b/README.md
index 1136a9f..fe353c2 100644
--- a/README.md
+++ b/README.md
@@ -99,7 +99,7 @@ A certificate expiring is a slow problem measured in days. A missing application
 → [docs/secret-distribution.md](docs/secret-distribution.md)
 
 ### 🪪 SSO & Identity
-The identity provider's own LDAP layer flatly refuses to authenticate superuser accounts — a hard vendor limitation, not a bug to file a ticket against. The fix wasn't a workaround bolted onto LDAP; it was routing that one case through a completely different authentication path instead, one zone boundary away from where the app itself actually lives.
+Authentik, self-hosted, fronts single sign-on for every app in the fleet that supports it — a dozen-plus apps on native OIDC where the upstream software allows it, everything else behind proxy-based forward-auth so apps that were never built with SSO in mind still get it. Every app registers twice, once per reverse-proxy zone, because authentication always happens on the internal zone even when the app itself lives on the browser-facing one. Git automation follows the same least-privilege instinct: a scoped bot account with write access replaces routing CI through an admin identity, so a leaked automation credential is never an admin credential.
 → [docs/sso-and-identity.md](docs/sso-and-identity.md)
 
 ### 🧱 Firewall & Network Segmentation
diff --git a/docs/sso-and-identity.md b/docs/sso-and-identity.md
index cf2bf24..7b9c683 100644
--- a/docs/sso-and-identity.md
+++ b/docs/sso-and-identity.md
@@ -34,11 +34,6 @@ This split matters more than it looks: the browser-facing zone enforces mutual T
 
 Every app-specific setting beyond this shape (token lifetime, scopes, flow type) is deliberately **not** generalized across apps — each app's own OIDC documentation gets read fresh rather than copying another app's provider config, since the details genuinely differ per vendor and copying blind is how subtle auth bugs get introduced.
 
-## A real platform limitation, worked around rather than ignored
-
-> [!WARNING]
-> Authentik's own LDAP outpost **hides superuser accounts from LDAP directory search** — so any app requiring a search-then-bind LDAP flow (a media server's user-management plugin, for instance) can never authenticate the fleet's primary superuser account through LDAP, full stop. Two workarounds were on the table: create a second, non-admin account just for LDAP-dependent apps, or demote the primary account from superuser entirely. Both were rejected — a second account fragments identity across the fleet in a way that undermines the whole point of centralized SSO, and demoting the primary account breaks unrelated admin workflows that depend on superuser rights. **Header-based forward-auth is used instead** for any app in this situation: Authentik's proxy layer authenticates the user and passes identity via HTTP headers, sidestepping the LDAP search-then-bind requirement entirely rather than working around Authentik's own limitation inside LDAP itself.
-
 ## Git access: least privilege, not the admin account
 
 ```mermaid