Ein US-Gericht kann einen Anbieter, der der US-Gerichtsbarkeit unterliegt, unter bestimmten Umständen dazu verpflichten, Daten zu Konten eines europäischen Unternehmens herauszugeben – selbst wenn dessen Server in Frankfurt oder Paris stehen. Das bedeutet nicht, dass ein Gerichtsbeschluss unmittelbar Zugriff auf Passwörter im Klartext ermöglicht: Der CLOUD Act erlaubt US-Behörden, die Herausgabe von Daten anzuordnen, die sich im Besitz, in der Verwahrung oder unter der Kontrolle eines Anbieters befinden. Was tatsächlich herausgegeben werden kann, hängt jedoch von der Art der rechtlichen Anordnung, dem technischen Zugriff des Anbieters auf die Daten und davon ab, ob der Passworttresor tatsächlich nach dem Zero-Knowledge-Prinzip verschlüsselt ist. Das Interesse an europäischen Passwortmanagern wächst, weil Einkauf und Compliance belastbare Antworten auf Fragen zu Datenstandort und rechtlicher Exponierung benötigen – nicht weil Verschlüsselung allein unzureichend wäre, sondern weil der Rechtsraum ein eigenständiger zusätzlicher Faktor ist, den Verschlüsselung nicht von selbst klärt.
Europäische Passwortmanager: Entscheidungsrahmen für Compliance-orientierte Teams
Einleitung – die Compliance-Lücke bei der Verwaltung von Zugangsdaten
Ein Wechsel des Passwortmanagers steht bei kleinen Unternehmen selten auf der IT-Roadmap – bis ein Kundenvertrag, eine Prüfung des NIS2-Anwendungsbereichs oder ein Fragebogen zur Cyberversicherung plötzlich einen Nachweis darüber verlangt, wo Zugangsdaten gespeichert werden und wer ihre Herausgabe anordnen kann. Weitverbreitete Tools wie 1Password, LastPass und Dashlane werden häufig als weltweit konform vermarktet. Doch die Vertragspartei, beteiligte Unterauftragsverarbeiter und verfügbare Datenregionen können je nach Tarif und Region variieren. Diese Angaben sollten deshalb in den aktuellen Rechtshinweisen und der Liste der Unterauftragsverarbeiter des jeweiligen Anbieters geprüft werden, statt sie aus der Herkunft der Marke abzuleiten. Für ein überwiegend in der EU tätiges Unternehmen wird das relevant, sobald Einkauf, Audit oder Versicherung konkret nachfragen und sich nicht mit einer allgemeinen Compliance-Aussage zufriedengeben.
In der Praxis dominieren meist wenige konkrete Auslöser: eine Prüfung, ob NIS2 anwendbar ist (NIS2 erweitert den Kreis der erfassten Einrichtungen gegenüber der vorherigen Richtlinie deutlich, wobei die genaue Betroffenheit von Branche und Größenklasse abhängt), eine B2B-Vertragsklausel, die eine ausschließliche Datenverarbeitung in der EU verlangt, oder die Verlängerung einer Cyberversicherung, für die Standorte von Unterauftragsverarbeitern dokumentiert werden müssen. Dahinter steht keine Vorliebe für „europäische Software“ an sich, sondern ein konkretes Dokument oder eine Klausel, deren Anforderungen erfüllt werden müssen. Serverstandort, Unternehmenssitz und Verschlüsselungsarchitektur beantworten jeweils einen anderen Teil dieser Frage; keiner dieser Faktoren ist allein entscheidend. Ein Anbieter mit einer passenden Hosting-Region kann zu einer Unternehmensstruktur gehören, aus der andere rechtliche Risiken entstehen. Umgekehrt ist ein Anbieter mit europäischem Rechtssitz nicht automatisch sicherer oder besser geprüft. Europäische Alternativen können diese Lücke adressieren – sofern Funktionen wie SSO, gemeinsame Nutzung und Audit-Protokolle tatsächlich vergleichbar sind.
Warum Rechtsraum und Hosting-Standort wichtig sind – aber allein keine vollständige Antwort liefern
Zero-Knowledge-Verschlüsselung begrenzt, welche Inhalte eines Passworttresors ein Anbieter technisch herausgeben kann. Sie nimmt den Rechtsraum jedoch nicht vollständig aus der Gleichung. Metadaten wie Anmeldezeitpunkte, IP-Adressen, Ordnerstrukturen und Teamzugehörigkeiten sowie Backup-Infrastruktur und Prozesse zur Reaktion auf Sicherheitsvorfälle liegen häufig außerhalb der Zero-Knowledge-Grenze. Sie können für den Anbieter zugänglich bleiben und damit potenziell einer rechtlichen Anordnung in seinem Rechtsraum unterliegen. Ein Anbieter kann die Inhalte des Passworttresors Ende-zu-Ende verschlüsseln und dennoch aufgrund einer wirksamen Anordnung zur Herausgabe zugehöriger Kontometadaten verpflichtet sein.
Der praktische Unterschied zwischen „Server in der EU“ und „Unternehmen mit Hauptsitz in der EU“ ist vor allem rechtlicher und nicht rein technischer Natur. Es geht dabei um Abstufungen, nicht um eine absolute Garantie. Ein US-Unternehmen, das Daten in einem EU-Rechenzentrum hostet, bleibt eine US-amerikanische juristische Person. Im Rahmen des anwendbaren US-Rechts kann es verpflichtet werden, Daten herauszugeben, die sich in seinem Besitz oder unter seiner Kontrolle befinden – unabhängig vom physischen Speicherort. Ein in einem EU-Mitgliedstaat gegründetes Unternehmen mit dortigem Hauptsitz unterliegt in erster Linie dem EU-Recht und dem jeweiligen nationalen Recht. Der Zugriff der US-Justiz erfolgt bei einem solchen Unternehmen üblicherweise über langsamere und stärker begrenzte Wege, etwa Rechtshilfeabkommen. Das reduziert bestimmte Risiken, beseitigt aber weder sämtliche grenzüberschreitenden Rechtsrisiken noch sagt es etwas über die Sicherheitspraktiken des Anbieters aus. Hinzu kommt die Eigentümerstruktur: Einige als „europäisch“ vermarktete Anbieter haben Investoren außerhalb der EU. Das schafft für sich genommen keine direkte rechtliche Exponierung, kann aber langfristige Entscheidungen zur Daten-Governance beeinflussen, insbesondere bei Übernahmen.
| Faktor | DSGVO-Konformität (Frage der Datenverarbeitung) | Rechtsraum (Frage der rechtlichen Exponierung) |
|---|---|---|
| Grundlage | Ein verbindlicher Auftragsverarbeitungsvertrag sowie die tatsächlichen Verarbeitungs- und Sicherheitspraktiken | Rechtlicher Unternehmenssitz, Konzernstruktur und Kontrolle über die Daten |
| Anwendbarkeit des CLOUD Act | Wird durch einen Auftragsverarbeitungsvertrag nicht unmittelbar geregelt | Hängt davon ab, ob eine beteiligte Gesellschaft der US-Gerichtsbarkeit unterliegt, welche rechtliche Anordnung vorliegt und auf welche Daten tatsächlich zugegriffen werden kann |
| Was wird abgedeckt? | Vertragliche und operative Datenschutzpflichten | Welche Behörden grundsätzlich eine Herausgabe anordnen können |
| Prüfaufwand | Auftragsverarbeitungsvertrag, Liste der Unterauftragsverarbeiter und Sicherheitsdokumentation prüfen | Handelsregistereinträge, offengelegte Eigentumsverhältnisse und Vertragspartei prüfen |
| Relevanz für Audits | Häufig notwendiger Bestandteil der Due Diligence, allein jedoch nicht ausreichend | Wird häufig ergänzend zur DSGVO-Dokumentation geprüft, nicht als deren Ersatz |
DSGVO-Konformität und Rechtsraum beantworten unterschiedliche Fragen. Sie sollten gemeinsam bewertet und nicht als austauschbare Nachweise für „Compliance“ behandelt werden. Weder ein unterzeichneter Auftragsverarbeitungsvertrag noch ein Rechtssitz in der EU reicht für sich allein aus. Einkaufsteams sollten beide Dimensionen zusammen mit Vertragspartei, Unterauftragsverarbeitern, Datenregionen und Verschlüsselungsgrenzen prüfen.
[INTERNAL LINK: EU AI Act software compliance evaluation]
Vergleichskriterien – was kleine Unternehmen vor einem Wechsel prüfen sollten
Für ein Unternehmen mit 10 bis 50 Beschäftigten sind weniger Kriterien entscheidend als die vollständigen Funktionsmatrizen der Anbieter vermuten lassen. Der folgende Rahmen konzentriert sich auf Punkte, die bei einer Compliance-Prüfung oder Beschaffungsentscheidung typischerweise relevant sind, sowie auf grundlegende Sicherheitsfunktionen, die unabhängig vom Rechtsraum geprüft werden sollten.
| Kriterium | Warum es für ein Team mit 10 bis 50 Personen wichtig ist |
|---|---|
| Unternehmenssitz / Rechtssitz | Beeinflusst den anwendbaren Rechtsraum unabhängig vom Hosting-Standort |
| Server- / Datenregion | Relevant für vertragliche Vorgaben zum Datenstandort |
| Verschlüsselungs- und Schlüsselableitungsmodell | Bestimmt, ob der Anbieter technisch auf die Inhalte des Passworttresors zugreifen kann |
| MFA- / Passkey-Unterstützung und Kontowiederherstellung | Ein schwacher Wiederherstellungsprozess kann starke Verschlüsselung untergraben – unabhängig vom Standort des Anbieters |
| Unabhängige Sicherheitstests und Umgang mit Schwachstellen | Liefert eine externe Validierung über die Aussagen des Anbieters hinaus |
| SSO- / SCIM-Unterstützung | Beeinflusst mit wachsender Teamgröße den Aufwand für Onboarding und Offboarding |
| Audit-Protokollierung sowie sicherer Export und sichere Löschung | Wird häufig bei NIS2- oder versicherungsbezogenen Prüfungen verlangt; die konkreten Anforderungen hängen jedoch vom jeweiligen Anwendungsbereich ab |
| Teampreise (grober Richtwert: etwa 3–8 € pro Benutzer und Monat) | Die Kosten steigen bei mehr als 20 Lizenzen schnell; als Planungswert, nicht als Angebot verstehen |
| Open-Source-Status | Ermöglicht eine unabhängige Codeprüfung, statt sich ausschließlich auf Aussagen des Anbieters zu verlassen |
Diese Tabelle ist ein Bewertungsrahmen und keine Rangliste einzelner Anbieter. Die Preisspanne dient lediglich der Planung und sollte vor einer Entscheidung beim jeweiligen Anbieter bestätigt werden.
Europäische Passwortmanager-Alternativen im Vergleich
„Europäisch“ ist eine geografische Bezeichnung und keine einheitliche Rechtskategorie. Der Begriff sollte nicht mit „EU“, „EWR“ oder einer konkreten Beschaffungsanforderung gleichgesetzt werden. Die Schweiz liegt beispielsweise in Europa, gehört aber weder zur EU noch zum EWR. Ein Anbieter mit Hauptsitz in der Schweiz erfüllt daher möglicherweise keine Klausel, die ausdrücklich einen in der EU oder im EWR niedergelassenen Anbieter verlangt – auch wenn er einer allgemeineren Präferenz für „europäische“ Anbieter entspricht. Bei der Vorauswahl hilft es, vier Fragen getrennt zu betrachten: Wo ist der Anbieter eingetragen? Welche Gesellschaft unterzeichnet den Kundenvertrag? Wo befinden sich Daten und Unterauftragsverarbeiter? Und steht Self-Hosting als Alternative zu den übrigen Optionen zur Verfügung?
| Anbieter | Hauptsitz / Rechtssitz | Bereitstellungsmodell | Open Source |
|---|---|---|---|
| Proton Pass | Schweiz – aktuelle Rechtshinweise prüfen | SaaS, Hosting-Optionen in der EU / im EWR | Client-Apps sind Open Source |
| NordPass | Litauen – aktuelle Rechtshinweise prüfen | SaaS | Nein |
| Passbolt | Luxemburg – aktuelle Rechtshinweise prüfen | Self-Hosting oder SaaS | Ja |
| Psono | Deutschland – aktuelle Rechtshinweise prüfen | Vorwiegend Self-Hosting | Ja |
| Bitwarden | USA (EU-Hosting und Self-Hosting verfügbar) | SaaS oder Self-Hosting | Ja |
Hinweis: Hauptsitz, Eigentümerstruktur, Hosting-Regionen und Preise können sich ändern. Bevor du dich bei einer Beschaffungsentscheidung auf die Angaben oben stützt, prüfe sie anhand der aktuellen Rechtshinweise, des Auftragsverarbeitungsvertrags, der Liste der Unterauftragsverarbeiter und der offiziellen Quellcode-Repositorys des jeweiligen Anbieters. Das Herkunftsland einer Marke ist kein verlässlicher Indikator für die Vertragspartei oder die tatsächlichen Hosting-Standorte.
Passbolt und Psono stehen für das Self-Hosting-Ende des Spektrums. Self-Hosting kann den Zugriff des Softwareanbieters auf die Daten im Passworttresor erheblich reduzieren und dem Kunden mehr Kontrolle über Speicherung, Backups und Betrieb geben. Die Beteiligung Dritter und rechtliche Risiken entfallen dadurch jedoch nicht automatisch: Auch der zugrunde liegende Hosting-Anbieter, die Identitätsplattform, Backup-Dienste, zugriffsberechtigte Administratoren und der Rechtsraum des Kunden müssen geprüft werden. In der Praxis verlagert Self-Hosting die Verantwortung für Updates, Backups und Verfügbarkeit auf die interne IT, statt die Abhängigkeit von Dritten vollständig zu beseitigen. Proton Pass und NordPass ähneln eher einem direkt einsetzbaren SaaS-Ersatz und verfügen über europäische Rechtssitze, bringen aber weiterhin eine gewisse Anbieterabhängigkeit mit sich. Bitwarden ist der strukturelle Sonderfall: Das Unternehmen wurde in den USA gegründet und hat damit keinen Hauptsitz in der EU, ist jedoch Open Source und innerhalb einer EU-Infrastruktur selbst hostbar. Diese Kombination kann einige Ziele technischer Souveränität erfüllen, genügt aber nicht zwingend einer strikten Beschaffungsklausel, die ausschließlich eine juristische Person in der EU zulässt.
Eine Frage wird in bestehenden Vergleichen nur selten direkt behandelt: Was passiert, wenn ein Anbieter mit Hauptsitz in der EU von einem Unternehmen außerhalb der EU übernommen wird? Nach einer Übernahme können sich Rechtssitz und anwendbarer Rechtsraum ändern. Verträge mit Passwortmanager-Anbietern, die aus Compliance-Gründen eingesetzt werden, sollten deshalb idealerweise eine Informationspflicht bei einem Kontrollwechsel enthalten – nicht nur eine Momentaufnahme des aktuellen Compliance-Status.
[INTERNAL LINK: European CRM alternatives for GDPR-conscious B2B teams]
Wann ist ein europäischer Passwortmanager für ein kleines Unternehmen sinnvoll – und wann nicht?
Ein Wechsel lässt sich am leichtesten begründen, wenn mindestens eine konkrete Bedingung erfüllt ist: Das Unternehmen fällt in den Anwendungsbereich von NIS2 und die daraus folgende Risikobewertung zeigt eine Lücke bei der Verwaltung von Zugangsdaten; ein Vertrag mit einem Kunden oder einer öffentlichen Stelle enthält eine ausdrückliche Vorgabe zum Datenstandort in der EU; oder das Unternehmen benötigt die Prüfbarkeit von Open-Source-Code, die ein proprietärer Wettbewerber nicht bietet. Wichtig ist: NIS2 schreibt im Allgemeinen weder einen Passwortmanager mit Hauptsitz in der EU noch eine ausschließlich in der EU erfolgende Speicherung von Zugangsdaten vor. Gefordert werden dem Risiko angemessene technische und organisatorische Maßnahmen; die konkreten Kontrollen hängen von Branche, Größe und nationaler Umsetzung ab. Eine NIS2-Prüfung kann also eine genauere Bewertung der Zugangsdatenverwaltung auslösen, ohne eine bestimmte Anbieterkategorie vorzugeben.
Ein Wechsel ist schwieriger zu rechtfertigen, wenn das bestehende Tool tief in eine etablierte SSO- oder Verzeichnisumgebung integriert ist, die ein kleinerer europäischer Anbieter nur teilweise unterstützt, oder wenn intern keine Kapazitäten für den Betrieb einer selbst gehosteten Lösung vorhanden sind. Der Self-Hosting-Aufwand hängt weit stärker von Architektur, Automatisierung, Backup- und Wiederherstellungsanforderungen sowie der Verzeichnisintegration ab als allein von der Beschäftigtenzahl. Für ein kleines Team kann er von einer überschaubaren wöchentlichen Wartungsaufgabe bis zu einer erheblichen laufenden Verantwortung reichen. Deshalb sollte der Aufwand anhand des konkreten Bereitstellungsplans ermittelt und nicht aus einer pauschalen Stundenzahl abgeleitet werden.
Das Migrationsrisiko konzentriert sich meist auf drei Punkte: vorübergehend fehlender Zugriff auf gemeinsam genutzte Zugangsdaten während der Umstellung, unvollständig importierte benutzerdefinierte Felder oder Anhänge zwischen unterschiedlichen Tresorformaten und eine Phase des Parallelbetriebs, in der Beschäftigte aus Gewohnheit weiterhin das alte Tool verwenden. Keines dieser Risiken verhindert einen Wechsel, doch sie werden leicht unterschätzt, wenn die Migration als einfacher Austausch einer SaaS-Lösung gegen eine andere betrachtet wird.
Bevor der Rechtsraum als Filter für die Vorauswahl dient, sollte zunächst ein Sicherheitsniveau bestätigt werden: starke MFA- oder Passkey-Unterstützung, ein dokumentiertes Verschlüsselungs- und Schlüsselableitungsmodell, zuverlässige Administrations- und Wiederherstellungskontrollen, Nachweise unabhängiger Sicherheitstests sowie sichere Export- und Löschfunktionen. Ein Anbieter mit Hauptsitz in der EU, aber schwacher Kontowiederherstellung oder ungeprüfter Kryptografie ist nicht zwangsläufig sicherer als eine gut auditierte Alternative aus einem anderen Land. Vor einem Wechsel helfen folgende Fragen: Verlangt ein bestimmter Vertrag, ein Audit oder eine Vorschrift ausdrücklich einen EU-Rechtsraum – und nicht nur Hosting in der EU? Kann das Unternehmen eine selbst gehostete Lösung betreiben, falls dieser Weg gewählt wird? Falls nicht: Gibt es stattdessen einen Managed Service in der EU oder im EWR? Lässt sich die bestehende SSO- oder Verzeichnisintegration beim Zielanbieter in ausreichendem Umfang nachbilden? Wo keine formale Vorgabe zum Rechtsraum besteht, sollten Sicherheitsniveau, operative Eignung und Gesamtkosten in der Regel stärker gewichtet werden als der Hauptsitz allein.
Was Teams beim Anbieterwechsel beachten sollten
Die Dauer einer Migration hängt stark von Teamgröße, Komplexität des Passworttresors und internen Freigabeprozessen ab. Bei einem Team mit 20 bis 50 Benutzern kann sie von wenigen Tagen bis zu mehreren Wochen reichen. Die folgenden Schritte beschreiben daher einen strukturierten Ablauf und keinen festen Zeitplan:
- Inhalte des bestehenden Passworttresors in einer kontrollierten, verschlüsselten Arbeitsumgebung exportieren und prüfen — behandle CSV-Dateien und andere unverschlüsselte Exportformate wie Passwörter im Klartext. Versende sie nicht per E-Mail und speichere sie nicht in gemeinsam genutzten Ordnern. Beschränke den Zugriff auf das Migrationsteam und lösche alle temporären Kopien sicher, sobald der Import geprüft wurde. Trenne gemeinsam genutzte Team-Zugangsdaten von persönlichen Einträgen, bevor du beide Gruppen migrierst.
- Pilotprojekt mit einer kleinen Gruppe durchführen vor dem vollständigen Rollout, damit Importfehler oder fehlende Felder früh auffallen.
- SSO- / SCIM-Anforderungen mit der tatsächlichen Unterstützung des neuen Anbieters abgleichen — prüfe, ob Bereitstellung und Deaktivierung wie erwartet funktionieren, statt dich nur darauf zu verlassen, dass SSO in der Funktionsliste steht.
- Einen klar definierten Parallelbetrieb statt einer sofortigen Umstellung einplanen, und den neuen Passworttresor ausdrücklich als zentrale und verbindliche Datenquelle festlegen, sobald der stabile Produktivbetrieb bestätigt ist.
- Ansprechpartner und Ablauf für Sicherheitsvorfälle beim neuen Anbieter dokumentieren — diese Angaben werden Teil des Audit-Trails für NIS2- oder versicherungsbezogene Dokumentationen.
- Einen festen Abschalttermin für das alte Tool festlegen , sobald Pilotphase und vollständiger Rollout stabil laufen, damit kein dauerhafter Mehraufwand durch zwei parallel genutzte Tools entsteht.
Das Überspringen der Pilotphase führt in der Praxis häufig zu Verzögerungen. Probleme bei der Feldzuordnung – etwa bei benutzerdefinierten Notizen, Anhängen oder TOTP-Seeds – zeigen sich meist erst im Arbeitsalltag echter Benutzer und nicht allein bei Tests durch Administratoren.
So unterstützt euroboxx bei der Bewertung
Unternehmenssitze, Eigentümerstrukturen, Hosting-Regionen und Preise ändern sich im Laufe der Zeit. Ein einzelner Vergleichsartikel kann deshalb nur als Ausgangspunkt und nicht als endgültige Quelle für eine Beschaffungsentscheidung dienen. Mit dem euroboxx-Verzeichnis lässt sich anhand der in diesem Artikel beschriebenen Kriterien eine erste Auswahlliste europäischer Softwarealternativen einschließlich Passwortmanagern erstellen.
Vor einer endgültigen Entscheidung sollte jeder Anbieter in der engeren Auswahl anhand seiner aktuellen Rechtshinweise, seines Auftragsverarbeitungsvertrags, seiner Liste der Unterauftragsverarbeiter, seiner Hosting-Dokumentation und eines schriftlichen Angebots geprüft werden. Teams, die Self-Hosting-Anforderungen mit den verfügbaren internen IT-Kapazitäten abgleichen oder einen konkreten Compliance-Auslöser genauer untersuchen möchten, können sich über euroboxx eine zweite Einschätzung einholen – als eine von mehreren Möglichkeiten und ohne Verpflichtung.
