NIST-Passwortrichtlinien 2026: Was SP 800-63B-4 verlangt

Die NIST-Passwortrichtlinien in SP 800-63B-4 verlangen, dass Passwörter, die als einziger Authentifizierungsfaktor dienen, mindestens 15 Zeichen lang sind. Viele Zusammenfassungen beschreiben diesen Wert als Empfehlung, Abschnitt 3.1.1.2 formuliert ihn jedoch als Anforderung.

Die NIST-Passwortrichtlinien in SP 800-63B-4 (seit Juli 2025 final) legen 15 Zeichen als Mindestlänge für die reine Passwortanmeldung fest und 8 Zeichen, wenn das Passwort ein Faktor einer Multi-Faktor-Authentifizierung ist. Sie verbieten Kompositionsregeln und regelmäßigen Passwortwechsel und verpflichten die prüfenden Systeme (Verifier), kompromittierte, gängige und kontextspezifische Passwörter zu sperren.

Dieser Leitfaden ordnet jede Passwortanforderung mit Abschnittsnummer in SHALL, SHOULD und MAY ein, zeigt, was sich gegenüber Rev 3 geändert hat, korrigiert sechs verbreitete Fehlinterpretationen und schließt mit einer Checkliste für die Einführung.

NIST-Passwortrichtlinien: Was SP 800-63B-4 ist und für wen es gilt

NIST SP 800-63B-4 ist der Authentifizierungsband der Digital Identity Guidelines (SP 800-63-4) des NIST. NIST hat die finale Fassung im Juli 2025 veröffentlicht, und sie ersetzt SP 800-63B vom März 2020. Da der Standard für Informationssysteme der US-Regierung geschrieben ist, ist er für Organisationen in Europa und anderswo eine freiwillige Leitlinie und ein Bezugspunkt für Ihre eigene Richtlinie.

SP 800-63-4 umfasst vier Bände: das Kerndokument, die Identitätsprüfung (63A), die Authentifizierung (63B) und die Föderation (63C). Laut der SP-800-63-4-Seite des NIST dauerte die Überarbeitung fast vier Jahre, mit zwei öffentlichen Entwürfen und fast 6.000 öffentlichen Kommentaren.

Der Geltungsbereich steht im Abstract. Die Richtlinie „konzentriert sich auf die Authentifizierung von Subjekten, die mit Informationssystemen der Regierung interagieren“, und ist „nicht dazu gedacht, die Entwicklung oder Nutzung von Standards außerhalb dieses Zwecks einzuschränken“. Für US-Bundesbehörden und ihre Credential Service Provider sind die Anforderungen verbindlich.

Das NIST verwendet ein eigenes Vokabular, das von der Sprache der Anbieter abweicht:

NIST-Passwortanforderungen: Die SHALL-, SHOULD- und MAY-Übersicht

NIST-Passwortanforderungen gibt es in drei Verbindlichkeitsstufen. SHALL und SHALL NOT kennzeichnen verpflichtende Konformitätsregeln des Standards selbst, SHOULD kennzeichnet eine Empfehlung, deren Nichtbeachtung begründet werden muss, und MAY kennzeichnet eine zulässige Option. In SP 800-63B-4 sind die Mindestlängen, die Verbote von Kompositionsregeln und regelmäßigem Wechsel, die Sperrlistenprüfung, das Rate Limiting (Begrenzung von Fehlversuchen) und das gesalzene Hashing durchweg SHALL.

Nutzen Sie die SHALL-First-Passwortrichtlinie als Arbeitsmethode: Setzen Sie jede verpflichtende Anforderung um, bevor Sie eine empfohlene angehen. Stufe 1 ist die SHALL-Basis, Stufe 2 die SHOULD-Härtung und Stufe 3 sind die MAY-Spielräume, die Sie nur übernehmen, wenn sie zu Ihren Benutzern passen. Die folgende Tabelle ordnet jede Passwortanforderung diesen Stufen zu, mit dem Abschnitt, in dem das NIST sie formuliert.

Bauen Sie die Richtlinie zuerst aus den SHALL-Zeilen auf. Jede SHOULD-Zeile, die Sie auslassen, braucht eine dokumentierte Begründung, und die MAY-Zeilen sind Optionen, die Sie nutzen können oder nicht.

Was sich von SP 800-63B Rev 3 zu Rev 4 geändert hat

Rev 4 erhöht die Mindestlänge für Passwörter als einzigen Faktor auf 15 Zeichen (bisher 8) und stuft zwei Empfehlungen aus Rev 3 (keine Kompositionsregeln, kein regelmäßiger Wechsel) von SHOULD NOT auf SHALL NOT hoch. Laut FAQ des NIST waren beide bisher unerwünscht, aber erlaubt. Sperrlistenprüfung, die Verbote von Passworthinweisen und KBA, gesalzenes Hashing und Rate Limiting waren bereits in Rev 3 verpflichtend.

Die Implementierungs-FAQ des NIST listet die neuen Passwortanforderungen auf, und SP 800-63B Rev 3 (2020) bestätigt den früheren Wortlaut. Die Tabelle vergleicht beide Texte.

Rev 4 ergänzt außerdem Anforderungen an synchronisierbare Authentifikatoren wie synchronisierte Passkeys (Anhang B) und eine Definition phishing-resistenter Authentifikatoren (Abschnitt 3.2.5); beides steht im Änderungsprotokoll des NIST (Anhang E). Bei einer Richtlinie, die auf Rev 3 basiert, sind Mindestlänge, Kompositionsregeln und Ablaufeinstellungen als Erstes anzupassen.

Sechs verbreitete Fehlinterpretationen der NIST-Passwortregeln

In Zusammenfassungen von SP 800-63B-4 kursieren sechs Fehler: 15 Zeichen als optional zu behandeln, 8 als allgemeine Mindestlänge anzugeben, die Grenzwerte von 100 und 10 Versuchen zu verwechseln, SMS als verboten zu bezeichnen, Einfügen statt Passwort-Manager zu fordern und die Sperrlistenprüfung als neu darzustellen. Jede Zeile nennt die tatsächliche Anforderung und den Abschnitt, der sie festlegt.

Länge, Zeichen und Sperrlisten: Was Verifier prüfen müssen

Verifier müssen für die reine Passwortanmeldung 15 Zeichen verlangen, jeden Unicode-Codepunkt als ein Zeichen zählen, auf Kompositionsregeln verzichten und jedes neue Passwort vollständig mit einer Sperrliste kompromittierter, gängiger und kontextspezifischer Werte abgleichen. Wird ein Passwort abgelehnt, muss der Verifier den Grund nennen und Hinweise zur Wahl eines sicheren Passworts geben.

Die Längenregel hat zwei Stufen. Ein Passwort, das als einziger Faktor dient, braucht 15 Zeichen. Ein Passwort, das nur als Teil einer Multi-Faktor-Authentifizierung dient, darf kürzer als 15 Zeichen sein, braucht aber mindestens 8 (Abschnitt 3.1.1.2). Sie können für alle Anmeldewege eine einheitliche Untergrenze von 15 festlegen, denn das NIST erlaubt das, und die Hinweise für Benutzer beschränken sich dann auf eine einzige Zahl.

Über die Untergrenze hinaus sollten Verifier mindestens 64 Zeichen akzeptieren und müssen das gesamte Passwort ohne Kürzung prüfen. Jeder Unicode-Codepunkt zählt als ein Zeichen. Wenn Unicode akzeptiert wird, sollte vor dem Hashing eine NFC-Normalisierung erfolgen, denn das NIST warnt, dass manche Endpunkte bestimmte Zeichen unterschiedlich darstellen, was die Authentifizierung scheitern lassen kann.

Die Zeichensätze sind offen: Verifier sollten alle druckbaren ASCII-Zeichen, das Leerzeichen und Unicode akzeptieren. Sie dürfen keine anderen Kompositionsregeln vorschreiben, etwa eine Mischung verschiedener Zeichentypen (Abschnitte 3.1.1.1 und 3.1.1.2). Anhang A nennt den Grund: Benutzer „reagieren sehr vorhersehbar auf die Anforderungen von Kompositionsregeln“, sodass aus password zuerst Password1 und dann Password1! wird. Der Artikel darüber, warum Kompositionsregeln in der Praxis scheitern, behandelt dieses Verhalten und die Entropie-Berechnung.

Wenn ein Benutzer ein Passwort festlegt oder ändert, muss der Verifier es mit einer Sperrliste gängiger, erwartbarer oder kompromittierter Werte abgleichen. Der Abgleich betrifft das gesamte Passwort, nicht Teilzeichenfolgen oder darin enthaltene Wörter. Die Liste kann aus drei Quellen gespeist werden:

• Passwörter aus Sammlungen früherer Datenlecks
• Wörterbuchwörter
• kontextspezifische Wörter wie der Name des Dienstes, der Benutzername und davon abgeleitete Formen

Steht das Passwort auf der Liste, muss der Verifier ein anderes verlangen, den Ablehnungsgrund nennen und Hinweise zur Wahl eines sicheren Passworts geben. Diese Hinweise sind nach einer Ablehnung am wichtigsten, weil sie davon abhalten, ein gelistetes Passwort nur geringfügig abzuwandeln.

Die Größe hat eine Grenze. Das NIST stellt fest: „Übermäßig große Sperrlisten bringen kaum zusätzlichen Sicherheitsgewinn, da die Sperrliste vor Online-Angriffen schützt, die bereits durch die Drosselungsanforderungen begrenzt sind.“ Ziel ist eine Liste, die groß genug ist, um Passwörter zu stoppen, die ein Angreifer vor Erreichen des Versuchslimits erraten würde (SHOULD).

Bei der Wahl eines Passworts sind zwei Abfragen verboten. Verifier dürfen einem Subscriber nicht erlauben, einen Hinweis zu speichern, den ein nicht authentifizierter Claimant sehen kann, und dürfen keine wissensbasierte Authentifizierung (KBA) oder Sicherheitsfragen abfragen.

Passwortwechsel, Rate Limiting und Speicherung

Verifier dürfen keinen regelmäßigen Passwortwechsel verlangen, müssen aber bei Hinweisen auf eine Kompromittierung einen Wechsel erzwingen. Aufeinanderfolgende Fehlversuche sind auf 100 pro Authentifikator begrenzt, und gespeicherte Passwörter müssen mit einem Salt von mindestens 32 Bit gesalzen und gehasht werden. Diese Regeln stehen in Abschnitt 3.1.1.2 und Abschnitt 3.2.2.

Passwortwechsel. Kalenderbasierter Ablauf entfällt, und laut FAQ des NIST war ein routinemäßiger regelmäßiger Wechsel in Rev 3 „bisher unerwünscht, aber erlaubt“. Ein erzwungener Wechsel ist erforderlich, wenn es Hinweise darauf gibt, dass der Authentifikator kompromittiert wurde. Das NIST definiert diese Hinweise nicht, also muss Ihre Richtlinie das tun. Eine Meldung des Subscribers und ein Treffer eines bestehenden Passworts in einer Sammlung geleakter Passwörter sind zwei praktische Auslöser; beide sind Entscheidungen Ihrer Richtlinie und keine vom NIST definierten Ereignisse.

Rate Limiting. Ein Verifier muss aufeinanderfolgende Fehlversuche bei einem einzelnen Authentifikator auf höchstens 100 begrenzen, und zwar „durch Deaktivieren dieses Authentifikators“; ein deaktivierter Authentifikator muss erneut an das Konto gebunden werden, bevor er wieder funktioniert (Abschnitte 3.2.2, 4.1). Das Limit ist eine Obergrenze, niedrigere Limits sind zulässig. Damit Angreifer legitime Benutzer nicht aussperren können, kann ein Verifier eine Bot-Erkennung, eine Wartezeit, die von 30 Sekunden auf bis zu eine Stunde ansteigt, oder risikobasierte Signale ergänzen. Vergleichen Sie das Sperrverhalten Ihres IdP mit der Formulierung „Deaktivieren“. Für Aktivierungsgeheimnisse, etwa eine Geräte-PIN, die das Gerät nie verlässt, gilt eine andere Regel: mindestens 4 Zeichen (6 empfohlen) und höchstens 10 aufeinanderfolgende Fehlversuche (Abschnitt 3.2.10).

Speicherung. Passwörter müssen mit einem geeigneten Passwort-Hashing-Verfahren gesalzen und gehasht werden; der Salt muss mindestens 32 Bit lang sein und so gewählt werden, dass Kollisionen zwischen Konten minimiert werden. Verifier sollten ein zugelassenes Verfahren aus der aktuellen SP 800-132 oder aktualisierten NIST-Vorgaben verwenden, den Kostenfaktor so hoch wie praktikabel ansetzen und ihn mit der Zeit erhöhen. Zusätzlich sollten sie einen Keyed Hash (Hash mit geheimem Schlüssel) einsetzen, dessen Schlüssel getrennt von den Hashes gespeichert wird, idealerweise in einem Hardware-Sicherheitsmodul (HSM) oder einer Trusted Execution Environment. Das NIST nennt keine konkreten Algorithmen mehr, weil sich die Anforderungen an die Speicherung schnell ändern.

Welche Rolle Passwörter in AAL1, AAL2 und AAL3 spielen

Die reine Passwortauthentifizierung ist nur auf AAL1 zulässig, deshalb gilt dort die 15-Zeichen-Regel. Auf AAL2 muss ein Passwort mit einem physischen Authentifikator kombiniert werden, und Verifier müssen eine phishing-resistente Option anbieten. AAL3 verlangt einen kryptografischen Authentifikator mit nicht exportierbarem privatem Schlüssel; ein Passwort ist dort nur als zusätzlicher Faktor erlaubt.

Die Werte stammen aus den Abschnitten 2.1 bis 2.3 des NIST-Standards. Dazu drei Anmerkungen.

1. Die Untergrenze von 15 Zeichen gilt für die Nutzung als einziger Faktor. Die FAQ des NIST beschreibt die Erhöhung als gültig für Passwörter, die „als einziger Authentifizierungsfaktor auf AAL1 verwendet werden“.
2. Passwörter sind nicht phishing-resistent (Abschnitt 3.1.1). Auf AAL2 müssen Verifier mindestens eine phishing-resistente Option anbieten (Abschnitt 2.2.2). Phishing-Resistenz erfordert kryptografische Authentifizierung; Authentifikatoren, bei denen eine Ausgabe manuell eingegeben wird, etwa OTP- und Out-of-Band-Codes, erfüllen die Anforderung nicht (Abschnitt 3.2.5). Der Leitfaden dazu, wie Passkeys funktionieren, behandelt die kryptografische Seite.
3. Synchronisierbare Authentifikatoren wie synchronisierte Passkeys können AAL2 unterstützen, wenn die Anforderungen aus Anhang B erfüllt sind. Auf AAL3 dürfen sie nicht verwendet werden: Synchronisierung bedeutet, dass der private Schlüssel exportierbar ist, und AAL3 verlangt einen nicht exportierbaren Schlüssel (Abschnitt 2.3.2).

SMS- und Sprachcodes bilden eine eigene Kategorie. Out-of-Band-Authentifizierung über das Telefonnetz ist ein eingeschränkter Authentifikator. Die Organisation muss das Risiko bewerten und akzeptieren, mindestens eine uneingeschränkte Alternative anbieten, die Subscriber angemessen informieren und einen Migrationsplan vorhalten (Abschnitte 3.1.3.3, 3.2.9).

NIST-Passwortrichtlinien umsetzen: Ein SHALL-First-Rollout

Ein SHALL-First-Rollout konfiguriert jede verpflichtende Anforderung vor jeder empfohlenen. Inventarisieren Sie jedes System, das ein Passwort prüft, legen Sie die Untergrenze von 15 Zeichen fest, entfernen Sie Kompositions- und Ablaufregeln, aktivieren Sie die Sperrlistenprüfung, bestätigen Sie das Rate Limiting, prüfen Sie selbst entwickelten Code, bieten Sie phishing-resistente Authentifizierung an und dokumentieren Sie Ausnahmen in einem Register.

1. Inventarisieren Sie jede Stelle, an der ein Passwort geprüft wird: Verzeichnisdienst, IdP, VPN, kundenseitige Anwendungen und interne Anwendungen. Die NIST-Pflichten knüpfen an den Verifier an, daher braucht jedes System, das ein Passwort prüft, eine eigene Zeile.
2. Legen Sie die Mindestlänge fest. Verwenden Sie 15 Zeichen für jeden reinen Passwort-Anmeldeweg und entscheiden Sie über die Untergrenze für MFA-Wege: Das NIST erlaubt dort 8, und eine einheitliche Regel von 15 für beide hält Richtlinie und Benutzerhinweise einfach.
3. Entfernen Sie Kompositionsregeln aus der Passwortrichtlinie des Verzeichnisdienstes, der IdP-Richtlinie und dem Anwendungscode.
4. Entfernen Sie den kalenderbasierten Ablauf. Behalten Sie den erzwungenen Wechsel bei Hinweisen auf eine Kompromittierung bei, und halten Sie fest, was ihn auslöst.
5. Aktivieren Sie die Sperrlistenprüfung beim Festlegen und Ändern von Passwörtern, einschließlich kontextspezifischer Wörter wie Dienstname und Benutzername. Die Ablehnungsmeldung muss den Grund nennen und Hinweise geben. Kann Ihr Verzeichnisdienst nicht nativ prüfen, liegt die Anforderung trotzdem beim Verifier; prüfen Sie daher, was Ihr IdP leisten kann.
6. Prüfen Sie das Rate Limiting: höchstens 100 aufeinanderfolgende Fehlversuche pro Authentifikator. Setzen Sie ein niedrigeres Limit und progressive Verzögerungen ein, wo das Unternehmen sie akzeptieren kann, und vergleichen Sie Ihr Sperrverhalten mit der NIST-Formulierung „Deaktivieren dieses Authentifikators“.
7. Prüfen Sie selbst entwickelte Anwendungen. Sie sollten 64 oder mehr Zeichen, Unicode und Leerzeichen akzeptieren, Einfügen und Autofill erlauben, nie kürzen und Passwörter mit einem aktuellen Verfahren gesalzen und gehasht speichern. Verzichten Sie auf Sonderzeichenfilter gegen SQL-Injection: Anhang A merkt an, dass ein ungehashtes Passwort nie unverändert an eine Datenbank gesendet wird, daher sind solche Filter überflüssig.
8. Bieten Sie phishing-resistente Authentifizierung für privilegierte Zugriffe und Fernzugriffe an. Passwörter sind nicht phishing-resistent, und Verifier auf AAL2 müssen mindestens eine phishing-resistente Option anbieten.
9. Dokumentieren Sie Ausnahmen. Ein Vertrag oder ein Framework kann weiterhin etwas anderes verlangen, etwa einen regelmäßigen Passwortwechsel. Erfassen Sie jede Ausnahme mit der Anforderung, der Begründung, einem Verantwortlichen und einem Überprüfungsdatum.

Welche Rolle ein Passwort-Manager in einer Richtlinie nach SP 800-63B-4 spielt

SP 800-63B-4 verpflichtet Verifier, Passwort-Manager und Autofill zuzulassen, und das NIST merkt an, dass Passwortmanager die Wahrscheinlichkeit sicherer Passwörter erhöhen, besonders mit Generatoren. Ein Passwort-Manager deckt Zugangsdaten ab, die Ihr Identity-Provider nicht prüft. Er ändert nichts daran, wie Ihr Verzeichnisdienst oder IdP Passwörter prüft; das bleibt eine separate Konfigurationsaufgabe.

Zwei Gruppen von Zugangsdaten liegen außerhalb Ihrer Verifier-Konfiguration: Konten in SaaS- und Anbietersystemen, die Sie nicht selbst prüfen, und gemeinsam genutzte oder privilegierte Zugangsdaten, die keine Passwortrichtlinie eines Verzeichnisdienstes abdeckt. Beide brauchen lange, zufällige und eindeutige Passwörter.

Passwork unterstützt diesen Einsatz mit vier Funktionen:

• Ein integrierter Passwortgenerator in der Weboberfläche, der Browser-Erweiterung sowie den Mobil- und Desktop-Apps. Er wendet von der Organisation definierte Regeln an und hilft Benutzern, für jeden Dienst ein eindeutiges Passwort zu erstellen.
• Ein Sicherheits-Dashboard, das Passwortstärke (basierend auf Länge und Zeichenvielfalt), Alter (es markiert Passwörter, die seit 180 Tagen oder länger nicht geändert wurden) und Kompromittierungsrisiko anzeigt, etwa Passwörter, auf die Benutzer mit entzogenem Zugriff noch zugreifen können. Administratoren können nach Tresor, Ordner, Benutzer und Bedrohungskategorie filtern.
• Eine von Administratoren konfigurierbare Sperrrichtlinie für die lokale Authentifizierung mit maximaler Anzahl von Fehlversuchen, Zeitfenster und Sperrdauer. Sie regelt die Anmeldung am Tresor selbst und ist unabhängig von dem Versuchslimit, das Ihr Verifier gemäß Abschnitt 3.2.2 durchsetzt.
• Anmeldung mit Passkeys (WebAuthn), TOTP, SAML SSO oder LDAP/AD sowie ein Aktivitätsprotokoll mit Benutzer-, Admin- und Systemaktionen, das sich in SIEM-Systeme exportieren lässt.

Die Altersmarkierung ist ein Signal zur Überprüfung, keine Ablaufregel. Abschnitt 3.1.1.2 verbietet, einen regelmäßigen Wechsel der Passwörter zu verlangen, die Ihr eigener Verifier prüft, und die Plattform ändert daran nichts.

Fazit

Die NIST-Passwortrichtlinien in SP 800-63B-4 ergeben zusammen eine kurze Richtlinie: eine Mindestlänge, keine Kompositionsregeln, kein Ablaufkalender, Sperrlistenprüfung, Rate Limiting und gesalzenes Hashing. Setzen Sie die SHALL-First-Passwortrichtlinie um, bevor Sie Aufwand in die SHOULD-Zeilen stecken.

Beginnen Sie mit drei Änderungen. Legen Sie 15 Zeichen für jeden reinen Passwort-Anmeldeweg fest und streichen Sie Kompositions- und Ablaufregeln. Ergänzen Sie die Sperrlistenprüfung überall dort, wo Passwörter festgelegt werden. Bieten Sie privilegierten Benutzern phishing-resistente Authentifizierung an. Zugangsdaten für Systeme außerhalb der Passwortrichtlinie Ihres IdP brauchen weiterhin lange, eindeutige Werte, und ein Passwort-Manager ist der richtige Ort dafür.

Sehen Sie Passwortstärke, Alter und Kompromittierungsrisiko über alle Ihre Tresore hinweg in einem Dashboard. Starten Sie eine kostenlose Passwork-Testversion und prüfen Sie, wie gut Ihre gemeinsam genutzten Zugangsdaten abschneiden.

Häufig gestellte Fragen

Sicherheitsvorfall bei Northflank: Was nach dem Vorfall rotiert werden muss

Northflank forderte Kunden auf, davon auszugehen, dass jede Umgebungsvariable entschlüsselt wurde. Railway warnte, dass dies bei einigen der Fall sein könnte, und Huntress verfolgte gestohlene M365-Tokens, die bei 79 Organisationen wiederverwendet wurden. Was jeder Anbieter offengelegt hat und was zu rotieren ist.

PassworkPasswork Team

Zugriffsverwaltung nach NIS2: Was fünf Experten zuerst beheben würden

Von der Richtlinie zur Praxis: Wer hatte Zugriff worauf, mit wessen Genehmigung, wie lange, und können Sie es nachweisen? Fünf Führungskräfte aus der Cybersicherheit über die Zugriffskontrollen, die sich am schwersten operationalisieren lassen, und die Nachweise, die Organisationen brauchen, um ihre Wirksamkeit zu belegen.

PassworkPasswork Team

Compliance-Standards für Passwort-Manager: Was sich 2026 geändert hat

Das NIST sagt: niemals regelmäßig wechseln. PCI DSS kann weiterhin einen Wechsel alle 90 Tage verlangen. Dieser Leitfaden ordnet neun Frameworks und Passkeys den Tresor-Kontrollen zu und zeigt, wie sich der Konflikt über den Geltungsbereich auflösen lässt.

PassworkAlex Muntyan