In vielen Behörden und öffentlichen Einrichtungen wächst der Wunsch, sich technisch und organisatorisch unabhängiger von US-Anbietern aufzustellen. Gründe sind oft weniger „Technik-Nationalismus“ als vielmehr handfeste Punkte: geringerer Vendor-Lock-in, klarere Datenhoheit, bessere Steuerbarkeit in Krisenszenarien, mehr Verhandlungsmacht bei Lizenzen sowie die Möglichkeit, kritische Prozesse langfristig selbst zu kontrollieren.
Wichtig ist dabei ein realistischer Blick: „Souverän“ heißt in der Praxis selten „alles nur aus Deutschland“ oder „Open Source um jeden Preis“. Es heißt vor allem: Wahlfreiheit, Standards, Exit-Fähigkeit und ein Betriebskonzept, das nicht an einem einzelnen Hersteller oder einer proprietären Cloud hängt.
Dieser Artikel bündelt praxistaugliche Alternativen aus Deutschland (und dort, wo es sinnvoll ist: Open-Source-Lösungen mit starker deutscher Anbieter-/Support-Landschaft) für vier zentrale Bereiche:
- Client-Arbeitsplatz (Endgeräte, Management, VDI/Thin Client)
- Cloud-Infrastruktur (IaaS/PaaS) mit Fokus auf deutsche Anbieter und gängige Nachweise
- Office & Collaboration (Dokumente, Files, Groupware, Videokonferenzen)
- Alternativen zu Active Directory (Verzeichnisdienst/IAM, Migrationspfade)
1) Leitplanken: Was „Souveränität“ technisch wirklich bedeutet
Bevor man Produkte vergleicht, lohnt sich ein kurzer Blick auf die Kriterien, die später über Erfolg oder Ärger entscheiden:
- Datenresidenz & Betreiberrolle: Wo liegen Daten und Metadaten? Wer betreibt die Plattform? Welche Subdienstleister sind im Spiel?
- Standards statt Spezial-Schnittstellen: ODF (Dokumente), CalDAV/CardDAV (Kalender/Kontakte), WebDAV/S3 (Files), OIDC/SAML (SSO), LDAP/Kerberos (Verzeichnis/WAN).
- Exit-Strategie: Datenexport, API-Portabilität, Vertragsklauseln, Dokumentation des Betriebs (Infra-as-Code), realistische Migrationspfade.
- Sicherheitsnachweise: Für Cloud-Dienste wird in Deutschland häufig der BSI C5-Kriterienkatalog als Orientierungs- und Prüfrahmen genutzt. Einstieg und Überblick beim BSI:
BSI: Kriterienkatalog C5.
Die aktuelle Version wird vom BSI ebenfalls veröffentlicht:
BSI: C5 aktuelle Version.
Pragmatisch ausgedrückt: Wer heute Standardprotokolle und saubere Identitätsarchitekturen nutzt, kann morgen Anbieter wechseln, ohne dass die Organisation stillsteht.
2) Clients: Der Arbeitsplatz ohne US-Zwang – realistisch und betreibbar
Der Client ist häufig der sichtbarste Teil der IT – und zugleich der Bereich, in dem Souveränität schnell greifbar wird. Trotzdem ist eine komplette „Windows-frei“-Strategie selten der beste erste Schritt. Besser funktioniert eine 3-Klassen-Clientstrategie, bei der jedes Arbeitsprofil die passende Betriebsform bekommt:
2.1 Drei Client-Klassen, die in der Praxis funktionieren
- Browser-First (oft Linux-basiert): Standardarbeitsplätze, die überwiegend in Web-Anwendungen arbeiten (Portale, DMS, Fachverfahren im Browser).
- VDI/Terminalserver/Remote Apps: Für Windows-only-Fachverfahren oder Spezialsoftware, die man zentral betreibt (und damit vom lokalen Gerät entkoppelt).
- Windows als Ausnahme: Für Peripherie, Spezialtreiber, einzelne Fachanwendungen oder Übergangsphasen.
Diese Aufteilung reduziert den Druck, alles gleichzeitig umzubauen, und sie macht Migrationsfortschritte messbar (z. B. „Anteil Browser-First“ wächst, „lokale Windows-Abhängigkeiten“ schrumpfen).
2.2 Deutsche Hersteller/Anbieter rund um den Clientbetrieb
IGEL Technology GmbH (Bremen) ist im Umfeld Thin Client / Endpoint OS / zentral verwaltete Arbeitsplätze etabliert und wird häufig in VDI-Szenarien eingesetzt. Impressum/Standortangaben:
IGEL: Legal Notice.
baramundi software GmbH (Augsburg) bietet Endpoint-/Unified-Endpoint-Management (UEM) und ist besonders in Migrationsphasen hilfreich, weil gemischte Umgebungen strukturiert gemanagt werden können. Standort/Unternehmensangaben:
baramundi: Kontakt und
baramundi: Impressum.
Wer den Client souveräner machen will, sollte zudem früh an Standardisierung denken: feste Browser-Profile, zentrale Zertifikats-/Proxy-Policy, saubere Rollen, automatisiertes Patch- und Softwaremanagement. Die Technik ist selten der Engpass – Prozesse und Governance sind es häufiger.
3) Cloud: Deutsche IaaS/PaaS statt Hyperscaler – mit Blick auf Nachweise und Standorte
Bei „Cloud“ ist eine klare Trennung hilfreich:
- IaaS (Compute/Storage/Netz): virtuelle Maschinen, Netze, Object Storage
- PaaS (Managed Services): Datenbanken, Kubernetes, Message Queues etc.
- SaaS (fertige Anwendungen): Kollaboration, Groupware, Fachanwendungen
Für Behörden ist Cloud selten „alles raus aus dem Rechenzentrum“, sondern meist Hybrid: neue Workloads in die Cloud, Legacy/hochintegrierte Systeme zunächst on-prem, dazu klare Datenklassen und Sicherheitsanforderungen.
3.1 BSI C5 als Orientierungsrahmen (warum das praktisch ist)
Der BSI-Kriterienkatalog C5 beschreibt Mindestanforderungen an sicheres Cloud Computing und wird in Deutschland häufig als Prüf- und Vergleichsrahmen genutzt. Einstieg:
BSI: C5.
Das ersetzt keine eigene Risikoanalyse – aber es macht Angebote vergleichbarer, zwingt zu Dokumentation und hilft bei Beschaffung und Audit.
3.2 Deutsche Cloud-Anbieter: Beispiele für IaaS/PaaS (mit Standorttransparenz)
Hetzner Online GmbH betreibt Datacenter-Parks u. a. in Nürnberg und Falkenstein (Vogtland) und kommuniziert die Standorte öffentlich:
Hetzner: Rechenzentrum sowie Hintergrund:
Hetzner: Über uns.
IONOS Cloud veröffentlicht Informationen zu Datacenter-Standorten/Regionen; ein Beispiel ist Frankfurt am Main:
IONOS Cloud: Data Centers.
Open Telekom Cloud (T-Systems) weist Zertifizierungen und Attestierungen aus; auf der Zertifizierungsseite wird u. a. ein BSI C5 Typ II (ISAE 3000) erwähnt:
Open Telekom Cloud: Certifications.
STACKIT positioniert sich als „souveräne Cloud“ und kommuniziert Hosting in Europa; Produkt-/Angebotsübersicht:
STACKIT.
Zusätzlicher Hintergrund aus der Schwarz Gruppe:
Schwarz Gruppe: STACKIT Story.
Hinweis für die Praxis: Auch deutsche Anbieter können Standorte außerhalb Deutschlands haben oder internationale Komponenten nutzen. Entscheidend ist, ob man Workloads in klar definierten Regionen betreiben kann und wie Vertrags- und Betriebsmodelle (Subdienstleister, Support, Zugriff, Schlüsselmanagement) gestaltet sind.
3.3 Cloud-Migration ohne Bauchlandung: typische „souveräne“ Zielarchitekturen
- Container/Kubernetes für neue Anwendungen, um Portabilität zu erhöhen
- Infrastructure as Code (Terraform/Ansible), damit ein Anbieterwechsel realistisch bleibt
- Standardisierte Observability (Logs/Metriken/Traces) unabhängig vom Provider
- Schlüsselmanagement (BYOK/HYOK wo möglich) und klare Rollenmodelle
Viele Behörden gewinnen am schnellsten, wenn sie zuerst Dev/Test, Webportale, APIs, Containerplattformen und „neu gebaute“ Services in eine deutsche Cloud bringen – und erst später hochintegrierte Kernverfahren.
4) Office & Collaboration: Alternativen zu Microsoft 365 (ohne All-in-One-Zwang)
Im Office-/Collaboration-Bereich ist die größte Falle die Annahme, man brauche zwingend wieder eine einzelne „Mega-Suite“. In der Praxis funktioniert ein modularer Baukasten oft besser: Dokumente standardisiert, Files souverän, Groupware sauber integriert, Videokonferenzen getrennt – verbunden über Standards und SSO.
4.1 Dokumente: ODF-first statt proprietärer Formate
LibreOffice ist für ODF-basierte Arbeitsweisen der Standardkandidat. Für Behörden ist relevant: ODF als Standardformat reduziert langfristig Abhängigkeiten und erhöht Austauschbarkeit zwischen Tools und Dienstleistern.
SoftMaker Software GmbH (Nürnberg) ist eine deutsche Office-Suite-Alternative, die in manchen Umgebungen als Brücke genutzt wird (z. B. wenn Kompatibilität zu bestimmten Dokumentenworkflows wichtig ist). Impressum:
SoftMaker: Impressum.
4.2 Files & Zusammenarbeit: Nextcloud als SharePoint/OneDrive-Baustein
Nextcloud GmbH (Impressum mit Adresse in Stuttgart) ist eine häufig gewählte Plattform für Filesharing, Synchronisation und kollaborative Bausteine (je nach App-Set). Impressum:
Nextcloud: Impressum.
Technisch entscheidend ist weniger „Nextcloud ja/nein“, sondern die organisatorische Umsetzung: Berechtigungskonzepte, Aufbewahrung, Versionierung, Vorlagen, Aktenstrukturen, Mandantenfähigkeit und Integration in Identitäten/SSO.
4.3 Videokonferenzen: deutsche Lösung mit klaren Anbieterangaben
OpenTalk GmbH (Berlin) positioniert sich als Videokonferenzlösung aus Deutschland; Impressum:
OpenTalk: Impressum.
Produktseite:
OpenTalk.
4.4 Groupware/Email: Exchange-Alternative (je nach Bedarf)
Open-Xchange AG betreibt Collaboration-/Groupware-Lösungen und weist in seinem Legal Notice u. a. eine Adresse in Köln aus:
Open-Xchange: Legal notice.
Für Behörden ist Groupware oft auch eine Frage des Betriebsmodells (on-prem, private Cloud, Hosting) und der Integrationen (DMS, Archiv, Fachverfahren). Häufig ist der bessere Schritt zuerst: Standards (CalDAV/CardDAV), saubere Postfachmigrationen, klare Archivierung – und dann die konkrete Plattformwahl.
5) Alternativen zu Active Directory: „AD ersetzen“ ist möglich – aber selten der erste Schritt
Active Directory ist nicht nur ein Verzeichnisdienst. Es ist in vielen Umgebungen der Knotenpunkt für Login, Gruppen/Policies, Geräte-Join, Kerberos/LDAP und zahllose Applikationsintegrationen. Wer AD „frontal“ ersetzen will, riskiert meist lange Projektlaufzeiten und hohe Betriebsrisiken.
In souveränen Migrationsprojekten hat sich deshalb ein Muster bewährt:
- SSO/IAM entkoppeln (OIDC/SAML): Anwendungen sprechen nicht mehr „direkt AD“.
- Geräteverwaltung modernisieren (UEM/Policies), um Clientsteuerung nicht am AD festzuketten.
- AD schrumpfen (nur noch dort, wo Windows/Legacy es wirklich braucht) – oder dann gezielt ablösen.
5.1 Univention als deutscher AD-Alternativ-/Migrationsbaustein
Univention positioniert mit Nubus IAM eine „Alternative zu Microsoft Active Directory“ und beschreibt Betriebsoptionen on-prem, private Cloud oder hybrid:
Univention: Alternative to Microsoft Active Directory.
Für klassische Integrations- und Koexistenzszenarien beschreibt Univention außerdem AD-Integration und Migration:
Univention: AD integration.
Auch im UCS-Kontext wird AD-Integration/AD-Services beschrieben:
Univention: UCS.
Praktisch bedeutet das: Man kann mit Koexistenz starten (Synchronisation/Connector, paralleler Betrieb) und später schrittweise migrieren – statt Big Bang.
5.2 Samba/AD-Kompatibilität als Brücke
In vielen Umgebungen ist ein „AD-kompatibler“ Ansatz als Übergang sinnvoll, um Windows-Clients und Legacy-Anwendungen weiter zu bedienen, während die Landschaft bereits entkoppelt wird (SSO, Files, Collaboration, Cloud).
Die zentrale Frage dabei ist nicht „AD ja/nein“, sondern: Wie klein und entkoppelt kann AD werden? Je weniger neue Systeme AD zwingend voraussetzen, desto leichter wird eine spätere Ablösung.
6) Ein realistischer Migrationspfad in 5 Etappen (ohne Big Bang)
Die folgende Roadmap ist bewusst pragmatisch. Sie funktioniert sowohl für Kommunen als auch für größere Landes-/Verwaltungseinheiten – und sie ist so aufgebaut, dass jeder Schritt für sich einen Nutzen bringt.
Etappe 1: Souveränitäts-Basics (4–8 Wochen)
- Applikationslandkarte: welche Systeme hängen hart an AD/M365/Windows?
- Standards beschließen (ODF, OIDC/SAML, CalDAV/CardDAV, WebDAV/S3)
- Datenklassen und Cloud-Leitplanken definieren (inkl. Sicherheitsnachweise wie BSI C5)
- Pilotteams auswählen (ein Amt, ein Fachverfahren, ein Querschnittsteam)
Etappe 2: Collaboration entkoppeln (2–4 Monate)
- Files/Sharing: Nextcloud als zentraler Baustein einführen
- Videokonferenzen: OpenTalk pilotieren und ausrollen
- Dokumente: ODF-first einführen (LibreOffice), Sonderfälle separat behandeln
Etappe 3: Identitäten modernisieren (3–6 Monate)
- SSO-Strategie (OIDC/SAML) umsetzen: neue Anwendungen nur noch per SSO
- Bestehende Websysteme nachrüsten (IdP/Proxy/Connector)
- Koexistenz zu AD aufbauen, damit AD an Bedeutung verliert
Etappe 4: Clientstrategie differenzieren (6–18 Monate, laufend)
- Browser-First dort, wo möglich (oft Linux-basiert)
- VDI/Thin Client für Windows-only-Fachverfahren (z. B. mit IGEL im Endpoint-Konzept)
- Windows nur noch als Ausnahme, nicht als Standard
- Zentrales Endpoint-Management (z. B. baramundi) zur Stabilisierung in der Übergangsphase
Etappe 5: AD schrumpfen oder ablösen (6–24 Monate)
- AD auf Legacy reduzieren (nur noch Windows/Restanwendungen)
- Gezielte Migration von Domänen/Objekten, wo möglich
- Langfristig: Ablösungsszenario etablieren (z. B. mit Univention-basierten IAM/Directory-Ansätzen)
7) Typische Stolperfallen (und wie man sie entschärft)
- „Kompatibilität“ wird unterschätzt: Makros, Vorlagen, Fachverfahren-Exports. Lösung: Sonderfälle früh identifizieren, separat behandeln, klare Regeln für Austauschformate.
- Identity wird zu spät angefasst: Ohne SSO/Standards bleiben Abhängigkeiten hart. Lösung: Etappe 3 früh priorisieren.
- Governance fehlt: Ohne Rollen-/Berechtigungsmodell werden neue Plattformen schnell so chaotisch wie alte Fileshares. Lösung: klare Ownership, Namenskonventionen, Lebenszyklusregeln.
- Cloud ohne Exit: Wer nur Provider-spezifische Dienste nutzt, zahlt später mit Lock-in. Lösung: Portabilität (Container, IaC, standardisierte Observability), Exit-Klauseln und Test-Migrationen.
8) Souverän wird man durch Architektur – nicht durch eine Einkaufsliste
Deutsche Alternativen gibt es heute in allen relevanten Schichten: vom Endpoint- und Clientbetrieb über IaaS/PaaS bis zu Collaboration und Identitätsmanagement. Der entscheidende Punkt ist die Reihenfolge: Wer zuerst Collaboration und Standards etabliert, dann Identitäten (SSO/IAM) entkoppelt, und erst danach die tiefen Plattformen (AD/Clients) umbaut, erreicht Souveränität schneller und mit deutlich weniger Betriebsrisiko.
Am Ende ist digitale Souveränität kein „Produkt“, sondern ein Zustand: Die Organisation kann Anbieter wechseln, ohne dass Betrieb, Sicherheit und Fachlichkeit kollabieren. Genau das ist der Kern – und genau darauf sollten Architektur, Beschaffung und Betrieb ausgerichtet werden.
