Passwortrichtlinie: Vorlage nach NIST und BSI

Die US-Standardisierungsbehörde NIST hat im Juli 2025 die SP 800-63B-4 als endgültige Fassung veröffentlicht; sie ersetzt die bisherige SP 800-63B. Sie richtet sich an Informationssysteme der US-Regierung und ist für Unternehmen in Österreich nicht verbindlich, eignet sich aber als Maßstab. SHALL bedeutet verpflichtend, SHOULD empfohlen. Für Anmeldesysteme gilt unter anderem: mindestens 15 Zeichen, wenn das Passwort der einzige Faktor ist, keine Regeln zu Zeichenarten, kein Wechsel nach Frist, eine Sperrliste und höchstens 100 Fehlversuche (3.1.1.2, 3.2.2).

Das IT-Grundschutz-Kompendium des deutschen BSI (Edition 2023) verlangt, den Passwortgebrauch verbindlich zu regeln (ORP.4.A8). Rein zeitgesteuerte Wechsel SOLLTEN vermieden werden; dafür MÜSSEN Maßnahmen ergriffen werden, um kompromittierte Passwörter zu erkennen (ORP.4.A23). Basis-Anforderungen sind vorrangig zu erfüllen, Standard-Anforderungen bilden mit ihnen den Stand der Technik. Auf seiner Verbraucherseite empfiehlt das BSI lange Passwörter, etwa fünf bis sechs zufällig gewählte Wörter mit Leerzeichen, nennt daneben kürzere Passwörter mit vier Zeichenarten und rät zum Passwortmanager.

Pflicht oder Empfehlung? NIST und IT-Grundschutz sind Standards, keine Gesetze in Österreich. Gesetzlich genannt ist Multi-Faktor-Authentifizierung für wesentliche und wichtige Einrichtungen in § 32 Abs. 4 lit. j NISG 2026; für sie gelten außerdem die Anforderungen an die Authentifizierung im Anhang der Durchführungsverordnung (EU) 2024/2690 (§ 2 NISV 2026), siehe Abschnitt 02. Die Vorlage in diesem Dokument ist eine Empfehlung von TOMORIS auf Grundlage dieser Quellen.

NIS2-Einrichtungen: Nach Anhang Nr. 11.6.2 der Durchführungsverordnung (EU) 2024/2690, den § 2 NISV 2026 für anwendbar erklärt, sind Authentifizierungsdaten zu Beginn, in vorab festgelegten Zeitabständen und bei Verdacht zu ändern (lit. c), nach einer festgelegten Zahl erfolgloser Anmeldeversuche das Zurücksetzen der Authentifizierungsdaten und die Sperrung zu verlangen (lit. d), inaktive Sitzungen zu beenden (lit. e) und für privilegierte Konten gesonderte Zugangsdaten zu nutzen (lit. f). Den Zeitabstand legen Sie selbst fest und begründen ihn mit der Risikoanalyse; einen Mindestwert nennt der Anhang nicht.

Für wesentliche und wichtige Einrichtungen zählt § 32 Abs. 4 lit. j NISG 2026 seit 1. Oktober 2026 die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“ zu den Mindestinhalten der Risikomanagementmaßnahmen. Sie müssen geeignet und verhältnismäßig sein (Abs. 1 und 3). Näheres regelt die NISV 2026 (BGBl. II Nr. 290/2026): Ihr § 2 erstreckt den Anhang der Durchführungsverordnung (EU) 2024/2690 auf alle wesentlichen und wichtigen Einrichtungen, die die Verordnung nicht schon selbst erfasst. Danach sind Nutzer, soweit angemessen und je nach Klassifizierung der Werte, mit mehreren Faktoren oder kontinuierlich zu authentifizieren (Anhang Nr. 11.7.1).

Die Microsoft-Pflicht gilt für alle Benutzerkonten, auch für Notfallkonten; für diese empfiehlt Microsoft Passkey (FIDO2) oder zertifikatbasierte Authentifizierung. Verwaltete Identitäten und Dienstprinzipale sind nicht betroffen, Benutzerkonten, die als Dienstkonto Skripte ausführen, schon. Im IT-Grundschutz SOLLTEN Kennungen mit weitreichenden Berechtigungen mit Mehr-Faktor-Authentisierung geschützt werden (ORP.4.A10), bei erhöhtem Schutzbedarf generell (ORP.4.A21). NIST verlangt auf der Stufe AAL2, mindestens ein phishingresistentes Verfahren anzubieten (2.2.2).

Empfehlung von TOMORIS: MFA für alle Konten, mindestens für E-Mail, Cloud-Dienste, Fernzugriff und Administration. Das geht über die hier genannten Pflichten hinaus.

So passen Sie die Vorlage an: Ersetzen Sie alle Angaben in eckigen Klammern, wählen Sie bei Varianten mit | eine aus und streichen Sie, was nicht zutrifft. Zahlen wie [15] Zeichen sind Vorschläge von TOMORIS auf Grundlage der Quellen. Fundstellen in runden Klammern zeigen, worauf eine Regel beruht; Regeln ohne Fundstelle sind organisatorische Ergänzungen von TOMORIS.

Für Konten, die direkt in Entra ID angelegt und verwaltet werden, gilt eine feste Kennwortrichtlinie: 8 bis 256 Zeichen, drei von vier Zeichenarten (Klein- und Großbuchstaben, Ziffern, Symbole), keine Unicode-Zeichen. Ändern lässt sich nur der Ablauf. Für Konten, die aus dem lokalen Active Directory synchronisiert werden, gilt sie nur, wenn die Cloud-Kennwortrichtlinie für synchronisierte Benutzer ausdrücklich aktiviert ist.

Eine Mindestlänge von 15 Zeichen und den Verzicht auf Zeichenarten-Regeln kann Entra ID für Cloudkonten daher nicht technisch durchsetzen. Empfehlung von TOMORIS: Regeln Sie die Länge über Richtlinie, Einweisung und den Generator des Passwortmanagers und stützen Sie den Schutz auf MFA und Passkeys.

• Kennwortablauf prüfen: Mandanten, die vor 2021 angelegt wurden, haben standardmäßig 90 Tage. Microsoft empfiehlt für reine Cloudkonten, Kennwörter nie ablaufen zu lassen.
• MFA für alle Benutzer erzwingen: mit Conditional Access (Entra ID P1 oder P2) oder, ohne diese Lizenz, mit den Sicherheitsstandards (Security Defaults).
• Die globale Sperrliste ist immer aktiv; sie beruht laut Microsoft auf eigener Telemetrie zu Password-Spray-Angriffen. Ergänzen Sie unter Entra ID › Authentifizierungsmethoden › Kennwortschutz die benutzerdefinierte Liste: Firmen-, Produkt- und Ortsnamen, interne Begriffe; nur Grundbegriffe, Varianten erkennt der Algorithmus; höchstens 1.000 Begriffe; ab Entra ID P1.
• Bei lokalem Active Directory: Kennwortschutz mit dem Agenten auf den Domänencontrollern ausrollen, damit dieselben Sperrlisten auch dort gelten (Entra ID P1 oder P2).
• Smart Lockout prüfen: Standard ist eine Sperre nach 10 Fehlversuchen für 60 Sekunden mit steigender Dauer; anpassen am selben Ort (Entra ID P1). Bei Pass-Through-Authentifizierung: Entra-Schwelle kleiner, Entra-Sperrdauer länger als im lokalen AD.
• Passkeys (FIDO2) in der Richtlinie für Authentifizierungsmethoden aktivieren, in allen Editionen ohne Zusatzlizenz; für Admin-Rollen und sensible Ressourcen phishingresistente Anmeldung über die Authentifizierungsstärke in Conditional Access verlangen (Entra ID P1).
• Notfallkonten mit Passkey (FIDO2) oder zertifikatbasierter Authentifizierung ausstatten; Benutzerkonten, die Skripte ausführen, auf verwaltete Identitäten oder Dienstprinzipale umstellen.
• Identity-Protection-Risikorichtlinien aktivieren (Entra ID P2) und die Kennwortzurücksetzung mit einer Authenticator-App verbinden, wie Microsoft es für Microsoft 365 empfiehlt.

• Sperrliste: Neue Passwörter vollständig gegen häufige, erwartbare und kompromittierte Passwörter prüfen, etwa Passwörter aus Datenlecks, Wörterbuchwörter, den Namen des Dienstes und den Benutzernamen; Ablehnung begründen und Hilfe zur Wahl anbieten (NIST 3.1.1.2).
• Länge: mindestens 15 Zeichen als einziger Faktor, mindestens 8 nur zusammen mit MFA; mindestens 64 Zeichen, alle druckbaren ASCII-Zeichen und Leerzeichen zulassen, Unicode nach Möglichkeit ebenso; das ganze Passwort prüfen, nie kürzen (NIST 3.1.1.2; ORP.4.A23).
• Fehlversuche: höchstens 100 in Folge je Konto, niedrigere Grenzen sind zulässig; ergänzend steigende Wartezeiten, etwa 30 Sekunden bis eine Stunde (NIST 3.2.2). Das BSI empfiehlt zunehmende Verzögerung und Sperre nach festgelegter Zahl (ORP.4.A13).
• Eingabe: Passwortmanager, automatisches Ausfüllen und Einfügen zulassen, das Passwort auf Wunsch anzeigen; keine Merkhilfen, keine Sicherheitsfragen (NIST 3.1.1.2). Bei Fehlanmeldung nicht verraten, ob Kennung oder Passwort falsch war (ORP.4.A23).
• Übertragung und Wechsel: Passwörter nur über verschlüsselte, authentifizierte Verbindungen; nach einem Wechsel keine alten Passwörter mehr zulassen (NIST 3.1.1.2; ORP.4.A23).
• Speicherung: gesalzen mit einem Passwort-Hashverfahren mit Kostenfaktor nach NIST SP 800-132, Salz mindestens 32 Bit, Kostenfaktor so hoch wie ohne Leistungseinbußen möglich und mit der Zeit erhöhen; empfohlen ist ein zusätzlicher Schritt mit geheimem Schlüssel, getrennt gespeichert, etwa in einem Hardware-Sicherheitsmodul (NIST 3.1.1.2; ORP.4.A12).

• Den Zwangswechsel abschaffen, ohne Kompromittierungen erkennen zu können: Das BSI knüpft den Verzicht an Maßnahmen, die kompromittierte Passwörter erkennen (ORP.4.A23).
• Als NIS2-Einrichtung den Wechsel ganz abschaffen: Anhang Nr. 11.6.2 lit. c DVO 2024/2690 verlangt einen Wechsel in vorab festgelegten Zeitabständen. Wählen Sie den Abstand bewusst und begründet, statt ihn wegzulassen.
• Die Mindestlänge in der Richtlinie erhöhen, aber Systeme mit kurzer Höchstlänge behalten: Prüfen Sie, ob jedes System die volle Länge annimmt und prüft (ORP.4.A23; NIST 3.1.1.2).
• Einen Passwortmanager einführen, ohne die Synchronisierung über Onlinedienste Dritter zu bewerten: Wer nach IT-Grundschutz arbeitet, MUSS solche Funktionen deaktivieren (ORP.4.A8).
• MFA mit Einmalcode per App oder SMS für phishingsicher halten: Codes, die von Hand eingegeben werden, gelten nicht als phishingresistent; das leisten nur kryptografische Verfahren wie Passkeys (NIST 3.2.5).
• Notfallkonten von MFA ausnehmen: Microsoft wendet die Pflicht-MFA für Admin-Portale ausdrücklich auch auf Notfallkonten an.

Passkeys beruhen auf FIDO2 und WebAuthn: Statt ein Passwort zu senden, weist das Gerät den Besitz eines privaten Schlüssels nach, freigegeben über eine PIN oder ein biometrisches Merkmal. NIST nennt WebAuthn als Beispiel für Phishingresistenz: Das Geheimnis ist an den authentifizierten Domainnamen des Dienstes gebunden, eine gefälschte Seite erhält deshalb nichts Verwertbares (SP 800-63B-4, 3.2.5).

• Passwörter sind nicht phishingresistent, ebenso wenig Verfahren mit manuell eingegebenem Code wie Einmalcodes oder Codes per SMS (NIST 3.1.1, 3.2.5).
• Synchronisierbare Passkeys, deren Schlüssel über einen Cloud-Dienst auf weitere Geräte kopiert werden, lässt NIST unter Auflagen zu, etwa dass der Schlüssel dort nur verschlüsselt liegt; für die höchste Stufe AAL3 sind sie ausgeschlossen (NIST 2.3.2, Anhang B).
• Entra ID unterstützt gerätegebundene Passkeys auf FIDO2-Sicherheitsschlüsseln und in Microsoft Authenticator sowie synchronisierte Passkeys; Letztere soll man laut Microsoft als phishingresistent, aber wie andere nicht attestierte Mittel behandeln. Gastkonten können keine Passkeys registrieren.

1. 1

   Bestand erheben

   Systeme mit Passwortanmeldung, ihre heutigen Regeln sowie Administrator-, Dienst- und Notfallkonten auflisten.

2. 2

   Vorlage anpassen und freigeben

   Platzhalter ausfüllen, Varianten entscheiden, Freigabe durch die Geschäftsführung einholen.

3. 3

   Technik umstellen

   Ablauf, Sperrliste, Fehlversuchsgrenzen, MFA und Passkeys umsetzen, zuerst für Administratoren, Notfallkonten und Fernzugänge.

4. 4

   Einweisen und prüfen

   Alle Mitarbeitenden einweisen (ORP.4.A19) und [jährlich] prüfen, ob Systeme die Regeln durchsetzen und sich Vorgaben geändert haben.