Compliance-Standards für Passwort-Manager: Was 2026 neu ist

2026 bedeutet Compliance für Passwort-Manager, die Kontrolle über Zugangsdaten nachzuweisen. Diese Compliance-Standards für Passwort-Manager überschneiden sich teilweise, ergeben aber keine einheitliche, universell gültige Richtlinie.

Die Anforderungen unterscheiden sich nach Branche, Region, Systemumfang und Abgrenzung des Audits, sodass keine einzelne Zertifizierung jede Organisation gleichermaßen abdeckt. Welche Frameworks gelten, hängt von der Art der Einrichtung, vom System- und Datenumfang, von der Rechtsordnung, von Verträgen und vom Risiko ab. Dieser Leitfaden bietet eine frameworkübergreifende Übersicht der Standards, eine Lösung für den wiederkehrenden Konflikt zwischen NIST und PCI beim Passwortwechsel sowie eine Zuordnung von Passkeys, die Sie beim Verfassen von Richtlinien nutzen können.

Compliance-Standards für Passwort-Manager: Stand 2026

Compliance-Nachweise sind die Gesamtheit aus Richtlinien, Konfigurationsaufzeichnungen, Genehmigungsverläufen, Zugriffsüberprüfungen, Protokollen und Testergebnissen, die zeigen, dass eine Kontrolle wie vorgesehen funktioniert und nicht nur auf dem Papier existiert. Für Passwort-Manager ist die Grundlage im Jahr 2026 ein gesteuerter Lebenszyklus von Zugangsdaten: eindeutige Identitäten, kontrollierter Tresorzugriff, starke Authentifizierung, nachvollziehbare Änderungen, getestete Wiederherstellung und eine frameworkspezifische Richtlinienebene.

Kein einzelnes globales Gesetz hat die Compliance für Passwort-Manager 2026 neu geregelt. Geändert hat sich die Kombination: 

• NIST (das US-amerikanische National Institute of Standards and Technology) Rev. 4 wurde zum aktuellen technischen Maßstab für Authentifikatoren
• PCI DSS (Payment Card Industry Data Security Standard) v4.0.1 ist der geltende PCI-Standard
• DORA (der Digital Operational Resilience Act der EU) gilt seit dem 17. Januar 2025
• NIS2 (die zweite EU-Richtlinie zur Netz- und Informationssicherheit) ist in die nationale Durchsetzung übergegangen
• Zwischen der aktuellen Regelung von HIPAA (Health Insurance Portability and Accountability Act) und der vorgeschlagenen Aktualisierung zur Multi-Faktor-Authentifizierung (MFA) besteht weiterhin eine Lücke

Compliance-Standards für Passwort-Manager nach Framework

Das Credential Governance Overlay (CGO), eine Steuerungsebene für Zugangsdaten, verknüpft jedes Framework mit der geforderten Kontrolle, den Nachweisen, die ein Auditor prüfen kann, und der Funktion des Passwort-Managers, die die Kontrolle operativ umsetzt. Für jedes der folgenden Frameworks wird beschrieben, was es verlangt und was das für die Konfiguration des Tresors bedeutet. Die Tabelle weiter unten fasst zusammen, welche Nachweise jeweils aufzubewahren sind.

NIST SP 800-63B Rev. 4

Für zentral verifizierte Passwörter legt NIST SP 800-63B Rev. 4 bei Ein-Faktor-Authentifizierung eine Mindestlänge von 15 Zeichen fest. Eine Mindestlänge von 8 Zeichen gilt nur, wenn das Passwort ausschließlich als Teil einer MFA verwendet wird. Verifizierer dürfen weder Kompositionsregeln noch regelmäßige Passwortwechsel vorschreiben und müssen neue Passwörter mit bekannten häufigen, erwartbaren oder kompromittierten Werten abgleichen.

Für einen Passwort-Manager bedeutet das: lange, eindeutige Zugangsdaten generieren, Autofill zulassen, Einfügen erlauben, wo kein Autofill verfügbar ist, eine Erkennung kompromittierter Passwörter betreiben und die Anmeldung am Tresor mit MFA schützen.

ISO/IEC 27001:2022

ISO 27001 ist der internationale Standard für Informationssicherheits-Managementsysteme. Die Kontrollen A.5.16 (Identitätsmanagement), A.5.18 (Zugriffsrechte), A.8.5 (sichere Authentifizierung) und A.8.24 (Kryptografie) aus Anhang A werden über den Risikobehandlungsplan und die Erklärung zur Anwendbarkeit (Statement of Applicability) umgesetzt, ein Dokument, das festhält, welche Kontrollen gelten und warum. Diese Kontrollen werden im Rahmen der Risikobehandlung ausgewählt; ISO schreibt weder jede Kontrolle aus Anhang A noch ein bestimmtes Passwort-Manager-Produkt vor.

Im Betrieb führt das zu einem Joiner-Mover-Leaver-Workflow, rollenbasierter Zugriffskontrolle (RBAC), MFA, wo das Risiko es erfordert, sowie dokumentierter Verschlüsselung und Schlüsselverwaltung.

SOC 2

SOC 2 ist ein Prüfungsframework für Dienstleistungsorganisationen. Die Trust Services Criteria CC6.1-CC6.8 des AICPA sind ergebnisorientierte Kontrollen für Zugriffsarchitektur, Registrierung und Autorisierung, Zugriffsänderungen, physischen Schutz, sichere Entsorgung, Schutz der Systemgrenzen, autorisierte Übertragung oder Entfernung von Informationen (CC6.7) und Abwehr von Schadsoftware. Auditoren prüfen Nachweise, die der Systemgrenze, den Risiken und den ausgewählten Kontrollen entsprechen.

Behandeln Sie den Tresor als eine Komponente innerhalb der geprüften Systemgrenze. Kontrollieren Sie Administratoren, Exporte, Integrationen und Protokollierung, nicht nur Passwörter.

PCI DSS v4.0.1

PCI DSS schützt Zahlungskartendaten. Anforderung 8 regelt Identifizierung und Authentifizierung für die Umgebung der Karteninhaberdaten (Cardholder Data Environment, CDE), also die Systeme und Personen, die für Zahlungskartendaten im Geltungsbereich liegen. Nach Anforderung 8.3.6 müssen Passwörter oder Passphrasen, die als Authentifizierungsfaktoren dienen, mindestens 12 Zeichen lang sein, oder mindestens 8 Zeichen, wenn das System keine 12 unterstützt.

Ist ein Passwort oder eine Passphrase der einzige Authentifizierungsfaktor für den Benutzerzugriff, verlangt Anforderung 8.3.9 einen Wechsel mindestens alle 90 Tage oder automatische Zugriffsentscheidungen auf Basis einer dynamischen Analyse des Sicherheitsstatus des Kontos. Die Anforderung darf nur dann als nicht anwendbar gekennzeichnet werden, wenn MFA den Zugriff auf alle Systemkomponenten im Geltungsbereich schützt oder wenn Komponente und Zugriffspfad unter die vom PCI SSC definierten Ein-Faktor-Bedingungen fallen. Die MFA-Pflichten selbst werden gesondert in den Anforderungen 8.4.2-8.4.4 geregelt, abhängig vom Zugriffspfad.

Segmentieren Sie Zugangsdaten im PCI-Geltungsbereich, prüfen Sie, ob Anforderung 8.3.9 gilt, bevor Sie vom Gegenteil ausgehen, und klären Sie, welche MFA-Anforderung für den jeweiligen Zugriffspfad gilt.

HIPAA Security Rule

HIPAA schützt Gesundheitsinformationen in den USA. Der aktuell geltende Abschnitt 45 CFR §164.312 verlangt für Systeme mit elektronischen geschützten Gesundheitsinformationen (ePHI) Zugriffskontrolle, eine eindeutige Benutzeridentifikation, ein Verfahren für den Notfallzugriff und die Authentifizierung von Personen beziehungsweise Einrichtungen. Ein Vorschlag des HHS aus dem Jahr 2025 würde MFA mit begrenzten Ausnahmen ergänzen, doch diese Anforderung ist weiterhin nur ein Vorschlag und kein geltendes Recht.

Nutzen Sie eindeutige Tresorkonten, behalten Sie Verfahren für den Notfallzugriff bei, schränken Sie das Teilen von ePHI-Zugangsdaten ein und überprüfen Sie Zugriffe und Protokolle regelmäßig.

NIS2

NIS2 ist die EU-Richtlinie zur Netz- und Informationssicherheit. Artikel 20 verpflichtet die Leitungsorgane, die Maßnahmen nach Artikel 21 zu billigen und ihre Umsetzung zu überwachen, und ermöglicht eine Haftung nach geltendem nationalem Recht. Artikel 21 verlangt verhältnismäßige Maßnahmen, darunter Richtlinien für die Zugriffskontrolle, Kryptografie, Cyberhygiene sowie MFA oder kontinuierliche Authentifizierung, wo dies angemessen ist. Artikel 34 verpflichtet die Mitgliedstaaten, für wesentliche Einrichtungen Geldbußen mit einem Höchstbetrag von mindestens 10 Millionen Euro oder 2 % des weltweiten Umsatzes festzulegen, je nachdem, welcher Betrag höher ist.

Daraus ergibt sich ein von der Geschäftsleitung genehmigtes Risikomanagementprogramm, das Zugriffsüberprüfungen, Schulungen, Incident Response und die Überwachung von Dienstleistern umfasst.

DORA

DORA regelt das IKT-Risiko für betroffene Finanzunternehmen in der EU und gilt seit dem 17. Januar 2025. Artikel 9 verlangt IKT-Sicherheitsrichtlinien und -kontrollen, darunter Zugriff nach dem Prinzip der geringsten Privilegien, starke Authentifizierung und den Schutz kryptografischer Schlüssel. Artikel 10 behandelt Erkennungsmechanismen; Artikel 11 behandelt IKT-Geschäftsfortführung, Reaktion, Wiederherstellung, Backup und Rücksicherung.

Behandeln Sie den Tresor als IKT-Dienst: Testen Sie die Wiederherstellung, kontrollieren Sie privilegierte Zugriffe, überwachen Sie Anomalien und bewerten Sie das Risiko durch Hosting-Anbieter.

DSGVO

Die DSGVO ist das allgemeine Datenschutzgesetz der EU. Artikel 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Artikel 32 verlangt eine dem Risiko angemessene Sicherheit, einschließlich Vertraulichkeit, Belastbarkeit und getesteter Wiederherstellung. Beide fallen unter den Grundsatz der Rechenschaftspflicht: Die Organisation muss die Einhaltung nachweisen können, statt sie nur zu behaupten.

Erfassen Sie Datenflüsse des Tresors, Zugriffe, Telemetrie, Wiederherstellung, Aufbewahrung sowie Beziehungen zu Auftragsverarbeitern und Unterauftragsverarbeitern.

Ein Unternehmen kann eine einheitliche Basisrichtlinie für den Tresor verwenden, muss aber strengere, auf den Geltungsbereich bezogene Richtlinienebenen ergänzen, wo PCI, Vorschriften für den Finanzsektor, Gesundheitsrecht, nationale NIS2-Gesetze, Verträge oder die interne Risikobereitschaft mehr verlangen. So bleiben die Richtlinien handhabbar, ohne eine allgemeine NIST-Basis so zu behandeln, als würde sie die rechtlichen Vorgaben für Systeme im Geltungsbereich außer Kraft setzen.

Tabelle: Compliance-Kontrollen für Passwort-Manager nach Framework.

NIST-PCI-Konflikt beim Passwortwechsel über den Geltungsbereich lösen

Entscheiden Sie sich nicht pauschal zwischen NIST und PCI. Wenden Sie jeden Standard auf die Konten und Systeme an, die er regelt. Der Geltungsbereich (Scope) umfasst die Personen, Systeme, Daten und Prozesse, für die eine bestimmte Anforderung tatsächlich gilt, und ein falsch bestimmter Geltungsbereich ist eine häufige Ursache für widersprüchliche Passwortrichtlinien innerhalb einer Organisation.

NIST Rev. 4 legt fest, dass Verifizierer keinen regelmäßigen Passwortwechsel verlangen dürfen. Anforderung 8.3.9 von PCI DSS v4.0.1 schafft eine andere Regel, wenn ein Passwort oder eine Passphrase der einzige Authentifizierungsfaktor für den Benutzerzugriff ist: Wechsel mindestens alle 90 Tage oder Zugriffsentscheidung auf Basis einer dynamischen Analyse des Sicherheitsstatus. Die Regel gilt möglicherweise nicht, wenn MFA den Zugriff auf alle Komponenten im Geltungsbereich schützt, vorbehaltlich der Anwendbarkeitshinweise von PCI und der Leitlinien des PCI SSC. Die beiden Standards widersprechen sich daher nur bei den betroffenen Passwortkonten im PCI-Geltungsbereich mit nur einem Faktor. Sie sollten nicht als universeller Richtlinienkonflikt behandelt werden.

Gehen Sie nach dieser Lösung in drei Schritten vor:

• Führen Sie ein gekennzeichnetes Inventar von Anwendungen und Konten, einschließlich der Angabe, ob sich das jeweilige Element in der CDE befindet und ob es ein Passwort als einzigen Faktor nutzt.
• Prüfen Sie bei Konten im PCI-Geltungsbereich mit nur einem Faktor, ob MFA alle Komponenten im Geltungsbereich abdeckt, bevor Sie davon ausgehen, dass Anforderung 8.3.9 nicht gilt. Wo sie gilt, setzen Sie den Wechsel nach 90 Tagen oder die zulässige Ausnahme über die dynamische Analyse durch.
• Wenden Sie das NIST-Modell aus Länge, Sperrlisten, Verzicht auf Kompositionsregeln und Wechsel bei Kompromittierung auf Systeme außerhalb von PCI an, für die NIST die maßgebliche Grundlage ist.

Stimmen Sie den endgültigen Geltungsbereich und die Zuordnung der Ausnahmen mit dem PCI-Assessor Ihrer Organisation ab, bevor Sie die Richtlinie für ein Konto im Geltungsbereich ändern.

Passkeys den Zielen der Frameworks zuordnen, nicht Compliance-Labels

Ein Passkey ist ein Public-Key-Credential nach FIDO2/WebAuthn, das eine Challenge für eine bestimmte Website signiert, statt ein wiederverwendbares Passwort zu übertragen. Ein synchronisierter Passkey steht über einen Synchronisierungsdienst auf allen Geräten eines Benutzers zur Verfügung. Ein gerätegebundener Authentifikator speichert den Schlüssel auf einem einzigen Authentifikator. Dieser Unterschied ist relevant für die Authentication Assurance Levels von NIST (AALs), die das Vertrauen in einen Authentifizierungsvorgang messen.

NIST definiert drei Stufen. AAL1 verlangt nur eine Ein-Faktor-Authentifizierung und erlaubt ein herkömmliches Passwort. Erst bei AAL2 und AAL3 verändert die Wahl des Passkeys tatsächlich, was Sie geltend machen können.

Wann ein Passkey AAL2 unterstützt

AAL2 verlangt zwei unterschiedliche Authentifizierungsfaktoren oder einen geeigneten Multi-Faktor-Authentifikator, und Anwendungen müssen eine Phishing-resistente Option anbieten. Ein Passkey kann AAL2 unterstützen, wenn die Bereitstellung diese Bedingungen erfüllt.

Entscheidend ist hier die Benutzerverifizierung: Ein WebAuthn-Credential ohne Benutzerverifizierung ist eine kryptografische Ein-Faktor-Authentifizierung und nicht automatisch AAL2. Für einen synchronisierten Passkey verlangt AAL2 zusätzlich die Schutzmaßnahmen aus Appendix B sowie eine MFA auf AAL2-Niveau für den Zugriff auf die Synchronisierungsinfrastruktur.

Warum synchronisierte Passkeys AAL3 nicht erreichen können

AAL3 verlangt einen Phishing-resistenten Authentifikator mit einem nicht exportierbaren Schlüssel und zwei unterschiedliche Faktoren. Die maßgebliche Richtung ist hier ein gerätegebundener, nicht exportierbarer Authentifikator. Durch die Synchronisierung wird der Authentifizierungsschlüssel exportierbar, daher kann ein synchronisierter Authentifikator die Anforderung der Nichtexportierbarkeit von AAL3 nicht erfüllen, unabhängig davon, wie gut er bei AAL2 abschneidet.

Wie sich Passkeys auf die übrigen Frameworks auswirken

Bei ISO 27001, SOC 2, NIS2, DORA, HIPAA und DSGVO können Passkeys eine sichere Authentifizierung unterstützen und die Phishing-Gefährdung verringern, ersetzen aber keine Zugriffsüberprüfungen, kein RBAC, keine Wiederherstellungskontrollen, keine Protokollierung und keine Prüfung von Dienstleistern. Bei PCI DSS kann eine Phishing-resistente Authentifizierung beeinflussen, welche MFA-Anforderung für einen bestimmten Zugriffspfad gilt, sie ist aber keine pauschale PCI-Ausnahme. Stimmen Sie die genaue Zuordnung mit Ihrem Assessor ab.

Ein Passkey stärkt die Authentifizierung, doch die Compliance hängt weiterhin davon ab, wer ihn registrieren kann, wie Zugriffe entzogen werden, wie die Wiederherstellung funktioniert und welche Nachweise Sie aufbewahren. Ein synchronisierter Passkey für ein internes Tool mit geringem Risiko und ein gerätegebundener Passkey, der ein Administratorkonto im PCI-Geltungsbereich schützt, erfüllen sehr unterschiedliche Richtlinienanforderungen, auch wenn beide „Passkeys“ heißen.

Das Credential Governance Overlay umsetzen

Das CGO überträgt die Übersicht der Standards in fünf operative Ebenen, jede mit eigenen Maßnahmen und einem eigenen Nachweispfad. Ein häufiges Problem bei Audits besteht darin, dass sich der Lebenszyklus der Zugangsdaten nicht belegen lässt.

• Identitätslebenszyklus. Verbinden Sie den Tresor mit einer maßgeblichen Identitätsquelle. Genehmigen Sie Zugriffe vor der Vergabe, passen Sie sie bei einem Rollenwechsel an und entziehen Sie sie beim Offboarding. Der Tresorzugriff eines ausscheidenden externen Mitarbeiters sollte am Tag des Vertragsendes entzogen werden, nicht erst im nächsten Abrechnungszyklus. Bewahren Sie Genehmigungs- und Deprovisionierungsnachweise auf.
• Richtlinie für Authentifikatoren. Trennen Sie Ein-Faktor-, MFA- und Phishing-resistente Pfade. Erlauben Sie lange generierte Passwörter und Autofill, prüfen Sie neue Passwörter auf Kompromittierung und wenden Sie eine eigene Richtlinie für privilegierte Konten und Konten im PCI-Geltungsbereich an, etwa für ein Administratorkonto innerhalb der CDE. Bewahren Sie Richtlinienkonfigurationen und Prüfergebnisse auf.
• Tresorzugriff. Nutzen Sie individuelle Konten, Rollen nach dem Prinzip der geringsten Privilegien, segmentierte Tresore und zeitlich begrenzten Zugriff für Dritte. Bewahren Sie Zugriffsmatrizen, Überprüfungsnachweise sowie Export- und Freigabeereignisse auf.
• Nachweise und Monitoring. Leiten Sie Zugriffsereignisse auf Zugangsdaten an ein überprüfbares Log oder an ein System für Security Information and Event Management (SIEM) weiter. Überprüfen Sie Anomalien, Exporte und Rollenänderungen. Bewahren Sie Untersuchungsnachweise auf, nicht nur Rohprotokolle.
• Resilienz und Datenschutz. Testen Sie die Verfahren für die Wiederherstellung des Tresors, Backup, Notfallzugriff und Schlüsselverwaltung. Bewahren Sie Testergebnisse, Wiederherstellungsfreigaben und Risikoentscheidungen auf.

Der aussagekräftigste Audit-Nachweis eines Passwort-Managers belegt den Lebenszyklus von Zugangsdaten: genehmigt, ausgegeben, verwendet, überprüft, entzogen und unter kontrollierten Bedingungen wiederherstellbar.

Kontrollen mit Passwork in belastbare Nachweise im Betrieb überführen

Ein Produkt sollte an diesem Nachweismodell gemessen werden, nicht an einem Compliance-Siegel. Die Funktionen zur Zugriffsverwaltung von Passwork können helfen, mehrere CGO-Ebenen operativ umzusetzen, auch wenn kein einzelnes Tool ein Framework allein erfüllt: gruppenbasierte Berechtigungen über Active Directory (AD) und LDAP, granulare Berechtigungen auf Ebene von Tresoren, Ordnern und Passwörtern, SAML-basiertes Single Sign-On, Zwei-Faktor-Authentifizierung mit YubiKey-Unterstützung sowie Audit-Logs für Lese-, Schreib-, Freigabe- und Exportaktivitäten.

Zuordnung zum CGO: Die AD/LDAP-Integration und RBAC unterstützen den Identitätslebenszyklus, segmentierte Tresorberechtigungen unterstützen das Prinzip der geringsten Privilegien. Audit-Logs unterstützen die Nachweisebene. Die Wahl zwischen selbst gehosteter Bereitstellung und Cloud-Bereitstellung unterstützt Entscheidungen zur Datenresidenz, die für Ihren Geltungsbereich spezifisch sind.

Nichts davon macht eine Organisation von sich aus regelkonform. Es liefert einem Sicherheitsteam die Konfiguration und die Aufzeichnungen, um diese Arbeit zu unterstützen, die weiterhin auf den eigenen Geltungsbereich und die eigenen Richtlinien der Organisation abgebildet werden muss.

Diese Compliance-Standards für Passwort-Manager in der Praxis umsetzen

Compliance für Passwort-Manager läuft 2026 auf vier Schritte hinaus: 

• Inventarisieren Sie Ihre Konten und Systeme 
• Kennzeichnen Sie, unter welchen regulatorischen Geltungsbereich sie jeweils fallen
• Ordnen Sie das Credential Governance Overlay der strengsten anwendbaren Kontrolle zu
• Testen Sie, ob Ihr Nachweispfad einer Prüfung standhält 

Diese Compliance-Standards für Passwort-Manager stimmen bei den Ergebnissen überein, nicht bei einer einzelnen Produktanforderung.

Nutzen Sie ein Programm zur Passwortverwaltung, um die Richtlinie für Zugangsdaten in eine Kontrolle zu überführen, die Ihr Sicherheitsteam betreiben und Ihre Auditoren prüfen können. Beginnen Sie noch diese Woche mit dem Kontoinventar und lesen Sie als nächsten Schritt den Leitfaden zur Nutzung eines Passwort-Managers.

Häufig gestellte Fragen