Passwort-Manager 2026: Cloud, eigener Server oder Datei

Ein Passwort-Tresor ist der eine Dienst, dessen Betreiber du wirklich kennen solltest: Er hält die Schlüssel zu allen anderen Konten. Die Funktion unterscheidet sich zwischen den drei Betriebsarten kaum - Tresor anlegen, Einträge ausfüllen, Zwei-Faktor belegen. Der Unterschied liegt woanders: Wer hält den Tresor, wer hat die Schlüssel im Ausfallfall, und was passiert, wenn der Betreiber verschwindet oder sperrt.

Drei Betriebsarten: Cloud, eigener Server, lokale Datei

Cloud (mieten) ist der Standardweg: Bitwarden und Proton Pass verschlüsseln den Tresor Ende-zu-Ende, bevor er ihren Server erreicht [1][6]. Der Betreiber speichert nur Chiffretext - er kann deine Einträge technisch nicht lesen, auch nicht auf behördliche Aufforderung hin, weil ihm der Schlüssel fehlt. Dafür ist er der einzige Ausfallpunkt: Geht die Infrastruktur weg oder sperrt dein Konto, sitzt du auf allen Schlüsseln gleichzeitig im Aus. Der Rettungsanker ist der Export [2].

Eigener Server verschiebt genau diese Verantwortung: Vaultwarden ist ein in Rust geschriebener Server, der das Bitwarden-Client-Protokoll vollständig spricht [5]. Deine Clients bemerken keinen Unterschied - dieselben Apps, dieselben Browser-Extensions, aber der Tresor liegt auf deinem VPS oder Homelab. Der Preis ist der Betrieb: Updates, verschlüsselte Datenträger, Offsite-Backups. Ein ungepflegter eigener Server ist ein schlechterer Ort für einen Tresor als ein gepflegter fremder.

Lokale Datei entfernt den Betreiber komplett: KeePassXC verwaltet eine verschlüsselte Datenbankdatei im KDBX-Format [3], einem offenen Standard, den auch andere Apps lesen können [4]. Es gibt keinen Server, der angreifbar wäre, kein Abo, kein Ausfallrisiko - aber auch keinen Sync. Wer die Datei auf mehreren Geräten braucht, löst das mit eigenen Mitteln: Sync-Dienst, USB-Stick, oder einem selbst gewählten Datei-Sync.

Was der Betreiber wirklich sieht

Die E2EE-Aussage der Cloud-Anbieter ist belastbar und trotzdem oft missverstanden. Bitwarden verschlüsselt den Tresor clientseitig, bevor irgendetwas übertragen wird [1]; Proton dokumentiert dieselbe Architektur für Pass [6]. Das bedeutet konkret: Der Server sieht verschlüsselte Blöcke, keine Passwörter, keine URLs, keine Notizen.

Nicht abgedeckt ist, was um den Tresor herum passiert: Der Betreiber weiß, dass du einen Tresor mit X Einträgen führst, wann er sich synchronisiert, von welchen Geräten. Diese Metadaten sind bei jedem gehosteten Modell unvermeidlich - auch bei einem selbst gehosteten, nur sieht sie dann der eigene Server, also du. Für die Bewertung heißt das: Die Frage "was sieht der Betreiber" ist zweistufig - Inhalte niemals, Metadaten immer. Die Fakten-Tabellen auf der Aufgaben-Seite trennen genau diese beiden Aussagen, statt sie in ein Badge zu pressen.

Für die Praxis folgt daraus eine Anmeldungs-Hygiene, die viele überspringen: Der Tresor-Account braucht eine eigene E-Mail-Adresse (nicht die Haupt-Adresse, an die jeder Phishing-Versuch geht), einen eigenen Namen, und 2FA, die nicht im selben Tresor liegt. Das klingt pedantisch, ist aber der Unterschied zwischen einem Tresor und einer Kette, die an der Haupt-Identität hängt.

Die zweite Nuance betrifft die Client-Software: Ein Audit des Servers sagt nichts über die Browser-Extension. Genau deshalb sind die Cure53-Berichte zu Bitwardens Extension bemerkenswert - sie prüfen den Code, der auf deinem Rechner läuft und die Einträge ins Browserformular schreibt, und die Berichte sind öffentlich nachlesbar [7].

Audits: was belegt ist und was es bedeutet

Das Audit-Vokabular ist gestuft, und die Stufen sind nicht gleichwertig. Eine Selbstauskunft ("militärisch sicher") hat keinen Belegwert. Ein Pen-Test ohne publizierten Bericht bleibt ein Versprechen. Öffentliche Berichte nennen Auditor, Umfang und Funde - sie lassen sich nachlesen und in einen Kontext setzen [7]. Die Methodik-Seite stuft die Evidenzklassen aus; für Passwort-Tresore gilt dieselbe Skala wie für Cloud-Speicher.

Die NIST-Guidance zu Authentifikatoren rahmt das technische Umfeld: Länge schlägt Zwangsrotation, ein langsamer KDF (Argon2, PBKDF2 mit hoher Iteration) schützt den Tresor gegen Offline-Brute-Force [8]. Alle drei im Vergleich stehenden Modelle setzen auf diese Bausteine - KDBX 4 unterstützt Argon2 nativ [4], Bitwarden konfiguriert KDF-Iterationen in den Kontoeinstellungen [1].

Ausstieg und Formate: der unterschätzte Faktor

Der Tresorwechsel ist billiger als der E-Mail-Wechsel, und genau deshalb sollte man ihn nicht aufschieben. KDBX ist ein offenes Format mit dokumentierter Spec [4] - KeePassXC, KeePass und diverse Mobile-Apps lesen dieselbe Datei [9]. Bitwarden exportiert in JSON (mit Ordnerstruktur, Anhängen, Notizen) oder verschlüsselt als Container [2]. Vaultwarden übernimmt Bitwarden-Exporte unverändert, weil die Clients identisch funktionieren [5].

Praktisch heißt das: Der Umzug von Bitwarden zu KeePassXC ist ein Export, ein Import, ein Abend. Der Umzug von einem Tresor, der keinen Export anbietet, ist ein Neuaufbau von Hand - hunderte Einträge, manuell. Deshalb steht der Export in der Fakten-Tabelle auf der Aufgaben-Seite und nicht irgendwo im Kleingedruckten.

Mieten oder selbst betreiben: die ehrliche Abwägung

Die Frage "Vaultwarden oder Bitwarden?" ist keine Sicherheitsfrage, sondern eine Betriebsfrage. Der gemietete Tresor hat eine Organisation, die sich um Verfügbarkeit, Backups und Patches kümmert - und ein Audit-Team [1][7]. Der eigene Server hat dich. Wer einen Homelab oder VPS ohnehin betreibt und Updates fährt, bekommt mit Vaultwarden dieselbe Client-Erfahrung ohne fremden Betreiber [5]. Wer keine Server pflegen will, sollte es auch bei seinem Tresor nicht anfangen müssen.

Der betriebspraktische Unterschied zeigt sich erst im Störfall. Beim gemieteten Tresor ist ein Ausfall das Problem des Anbieters, mit Statusseite und Kommunikation; beim eigenen Server ist es dein Problem, um drei Uhr nachts. Dafür entscheidest du bei deinem Server selbst über Aufbewahrung, Logging und den Zeitpunkt, zu dem du die Keys rotierst - und niemand kann dir die Exportrechte ändern. Beide Risiken sind real; die Frage ist, welches Risiko du lieber selbst trägst.

Ein pragmatischer Mittelweg ist die Kombination: KeePassXC für die kritischsten Einträge als lokale Datei, ein Cloud-Tresor für den Alltag. Das klingt nach Doppelpflege, funktioniert in der Praxis aber gut, weil die kritischen Einträge (Banking, Haupt-Mail) ohnehin selten getippt werden. Der Ausstiegsplaner hilft, die Wechselfähigkeit beider Ebenen nüchtern zu bewerten - der Tresor ist der Teil der digitalen Infrastruktur, der sich am billigsten wechseln lässt, bevor man ihn braucht.

Tipps und Fallstricke

Der Notfallplan fehlt fast immer. Ein Tresor ohne Notfall-Dokumentation ist für Hinterbliebene und für dich selbst nach einem Geräuschverlust verloren. KeePassXC druckt ein Emergency Sheet mit aus [3]; Bitwarden hat einen organisierten Notfallzugriff. Beides einrichten, bevor es nötig ist - und die Notfall-Dokumentation dort aufbewahren, wo der Tresor-Sync sie nicht gleichzeitig verliert.

2FA überall, aber mit Verstand. Zwei-Faktor ist in allen drei Modellen dokumentiert - für den Tresor selbst besonders wichtig, weil er die Master-Schlüssel zu allem anderen hält [1][6]. Aber ein TOTP-Code im selben Tresor wie das Passwort, das er schützt, ist Zirkularität, keine Sicherheit. Die 2FA für den Tresor gehört außerhalb - Hardware-Token, separates Gerät oder zumindest ein zweites Gerät, das nicht denselben Sync-Pfad wie der Tresor nimmt.

Passkeys ändern das Bild, nicht die Antwort. Wo Passkeys angeboten werden, sind sie die stärkere Anmeldung. Aber die Verwaltung von Passkeys läuft ebenfalls über einen Tresor - und die Mehrheit der Dienste verlangt weiterhin klassische Passwörter [8]. Die Wahl des Managers entscheidet also über beides.

Die Browser-Falle. Passwörter im Browserspeicher koppeln den Tresor an den Browser-Anbieter. Für die meisten Anwender ist ein dedizierter Manager der sauberere Weg - und der Wechsel weg vom Browserhersteller ist mit einem Export erledigt [2]. Dasselbe gilt für Handy-Browser mit eingebautem Tresor: Die Kopplung an den Geräte-Hersteller ist komfortabler als an den Browser, aber es bleibt eine Kopplung an einen Konzern, der nichts mit Tresor-Sicherheit zu tun hat.

Einträge leben länger als Dienste. Der Tresor sammelt Zugänge zu Diensten, die längst eingestellt sind - jedes davon ist eine alte Tür, deren Schloss niemand mehr wartet. Ein Jahres-Aufräumen (letzte Nutzung älter als ein Jahr: löschen oder archivieren) hält den Tresor klein und den Notfalldruck niedrig. Der Friedhof listet, wie viele Dienste pro Jahr real eingestellt werden - die Wahrscheinlichkeit, dass ein Teil deiner Einträge tot ist, ist hoch.

Sync der KeePassXC-Datei ist eine Aufgabe, kein Feature. Wer die lokale Datei über einen Cloud-Sync verteilt, wählt einen Cloud-Anbieter für den sensitivsten Datensatz - dann eher mit Ende-zu-Ende-Verschlüsselung, und Sync ist trotzdem kein Backup.

Rang	Anbieter	Betrieb	Open Source	Audit	2FA	Einstieg	Note
1	Proton Mail & Unlimited E2EE ab Werk kein US-Bezug Audit	mieten	Open Source	Audit 2024	ja	9,99 € /mo	7.9	Zum Anbieter
2	Vaultwarden E2EE ab Werk kein US-Bezug Open Source	selbst betreiben	Open Source	–	ja	0,00 €	7.4	Zum Anbieter
3	KeePassXC E2EE ab Werk kein US-Bezug Open Source	selbst betreiben	Open Source	–	ja	0,00 €	7.1	Zum Anbieter
4	Bitwarden E2EE ab Werk Audit	mieten	–	Audit 2025	ja	0,83 € /mo	7	Zum Anbieter

Direktvergleiche in dieser Aufgabe

vs

Bitwarden vs Vaultwarden

vs

Bitwarden vs KeePassXC

vs

Vaultwarden vs KeePassXC

vs

Proton Mail & Unlimited vs Vaultwarden

vs

KeePassXC vs Proton Mail & Unlimited

vs

Bitwarden vs Proton Mail & Unlimited