NIST SP 800-63-4: Nachweise zu Passwörtern, MFA und Passkeys

Am Montag um 08:10 Uhr erhält der CISO eines Fintech-Unternehmens die Nachricht, die jede Sicherheitsleitung fürchtet: „Wir sehen verdächtige Anmeldungen am Finanz-Administrationsportal. MFA wurde bestätigt, aber der Benutzer sagt, er sei es nicht gewesen.“

Um 08:25 Uhr erkennt das SOC das Muster. Der Angreifer hat keine Verschlüsselung gebrochen, keine Zero-Day-Schwachstelle ausgenutzt und keine Firewall umgangen. Er hat ein Passwort gephisht, eine Push-Bestätigung ausgelöst und auf Ermüdung gewartet. Eine Freigabe genügte. Das Konto hatte erhöhte Zugriffsrechte auf Exporte zur Kundenabrechnung, Audit-Protokolle und ein Abwicklungs-Dashboard eines Drittanbieters.

Um 09:00 Uhr fragt die Rechtsabteilung, ob es sich um eine Verletzung des Schutzes personenbezogener Daten nach GDPR handelt. Das Risikoteam fragt, ob das Ereignis eine Meldung nach DORA auslöst. Das Leitungsorgan will wissen, ob die Aussage „MFA überall“ tatsächlich zutraf. Der ISO 27001-Auditor, der ohnehin für den kommenden Monat eingeplant ist, verlangt nun Nachweise zu sicherer Authentifizierung, Zugriffskontrolle, Protokollierung und Korrekturmaßnahmen.

Deshalb ist NIST SP 800-63-4 im Jahr 2026 relevant.

Für CISOs, Compliance-Manager und Geschäftsverantwortliche ist NIST SP 800-63-4 nicht nur ein weiteres Identitätsdokument. Es entwickelt sich zur praxisrelevanten Referenz für moderne Passwortrichtlinien, phishing-resistente MFA, Passkeys, passwortlose Authentifizierung und Governance über den Lebenszyklus von Authentifikatoren. Die eigentliche Herausforderung besteht nicht darin, die Leitlinie zu lesen. Die Herausforderung besteht darin, die Umsetzung über ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 und interne Auditerwartungen hinweg nachzuweisen.

Die Position von Clarysec ist eindeutig: Identitätskontrollen scheitern, wenn sie als Einstellungen und nicht als Governance behandelt werden. Passwörter, MFA, Passkeys, Wiederherstellungsabläufe, Sitzungstoken, privilegierter Zugriff, Servicekonten und Authentifizierungsprotokolle müssen als zusammenhängendes, nachweiserzeugendes Kontrollsystem konzipiert werden.

Genau diese Perspektive wird in Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, in der Richtlinienbibliothek von Clarysec und in Zenith Controls: Der Cross-Compliance-Leitfaden verwendet. Zenith Controls schafft keine neuen Kontrollen. Es ordnet die Kontrollerwartungen aus ISO/IEC 27001:2022 und ISO/IEC 27002:2022 anderen Standards, Vorschriften und Auditperspektiven zu, damit Organisationen fragmentierte Nachweise und doppelte Compliance-Arbeiten vermeiden.

„MFA aktiviert“ ist keine Auditantwort

Viele Organisationen gingen in den vergangenen Jahren davon aus, dass die Einführung von MFA die Diskussion über Identitätsrisiken abschließt. Im Jahr 2026 ist diese Annahme nicht mehr belastbar.

Auditoren und Aufsichtsbehörden stellen inzwischen präzisere Fragen:

• Wird MFA für alle privilegierten, Remote- und risikobehafteten Zugriffe durchgesetzt?
• Ist die Authentifizierung phishing-resistent, wenn das Risiko dies erfordert?
• Werden Passkeys oder FIDO2-Authentifikatoren über Registrierung, Wiederherstellung, Widerruf und Gerätelebenszyklus gesteuert?
• Werden Passwörter gegen Listen kompromittierter und häufig verwendeter Zugangsdaten geprüft?
• Werden Passwortänderungen durch Kompromittierung ausgelöst und nicht durch pauschale Kalendervorgaben?
• Können Benutzer Passwörter aus Passwortmanagern einfügen?
• Werden Ereignisse zu Authentifikatoren protokolliert und überprüft?
• Sind Verfahren zur Kontowiederherstellung ebenso stark wie Anmeldeverfahren?
• Werden API-Geheimnisse, OAuth-Token, SSH-Schlüssel und Zugangsdaten von Servicekonten mit derselben Disziplin kontrolliert?

NIST SP 800-63-4 führt Organisationen zu risikobasierter Vertrauenssicherung digitaler Identitäten, Stärke von Authentifikatoren und Lebenszyklusnachweisen. Für die Passwortmodernisierung bedeutet dies, überholte Praktiken wie erzwungene regelmäßige Passwortänderungen ohne Hinweis auf Kompromittierung aufzugeben und zugleich Länge, Abgleich gegen kompromittierte Passwörter, Ratenbegrenzung, sichere Speicherung und Wiederherstellungskontrollen zu stärken. Für MFA und Passkeys bedeutet es, den Fokus auf Vertrauen in Authentifikatoren, Phishing-Resistenz, sichere Registrierung, Kontobindung, Widerruf und Auditierbarkeit zu legen.

Zenith Blueprint greift diese Entwicklung in Kontrollen in der Praxis, Schritt 19, Technische Kontrollen I, bei der Erläuterung sicherer Authentifizierung auf:

Authentifizierung ist die erste und kritischste Verteidigungslinie zwischen einem Bedrohungsakteur und Ihren Systemen, Daten und Services. Ist die Authentifizierung schwach, kann alles andere – Verschlüsselung, Überwachung, Segmentierung – umgangen werden. Maßnahme 8.5 stellt sicher, dass Authentifizierungsmechanismen sicher konzipiert, konsistent angewendet und gegen bekannte Angriffsmethoden widerstandsfähig sind.

Dieser Satz beschreibt den Kern des Identitätsaudits 2026. Die Frage lautet nicht mehr: „Haben Sie Passwörter und MFA?“ Die Frage lautet: „Können Sie nachweisen, dass Ihre Authentifizierungsarchitektur risikobasiert, gegen bekannte Angriffsmethoden widerstandsfähig, konsistent durchgesetzt und überwacht wird?“

Das Kontrollsystem rund um Identität, Authentifizierungsinformationen und sichere Authentifizierung aufbauen

Der nützlichste Weg, NIST SP 800-63-4 in Nachweise für ISO/IEC 27001:2022 zu übersetzen, besteht darin, Identität als verbundenes Kontrollsystem zu behandeln.

Über Zenith Controls identifiziert Clarysec drei zentrale Maßnahmenbereiche aus ISO/IEC 27002:2022 für die Ausrichtung an NIST SP 800-63-4: 5.16 Identitätsmanagement, 5.17 Authentifizierungsinformationen und 8.5 Sichere Authentifizierung. In ISO/IEC 27001:2022 Anhang A entsprechen diese A.5.16, A.5.17 und A.8.5.

Die Unterscheidung ist wesentlich. A.5.16 fragt: „Wer hat eine Identität?“ A.5.17 fragt: „Wie wird der Nachweis dieser Identität geschützt?“ A.8.5 fragt: „Wie wird die Authentifizierung in Systemen sicher durchgeführt?“

Wenn Organisationen in Audits scheitern, liegt es häufig daran, dass sie eine Ebene ohne die anderen umsetzen. Sie führen Passkeys ein, können aber keinen Nachweis zum Widerruf vorlegen. Sie erzwingen MFA, aber nicht für eine Legacy-Administrationskonsole. Sie definieren Passwortregeln, prüfen aber nicht gegen kompromittierte Passwörter. Sie deaktivieren ein Benutzerkonto, vergessen jedoch aktive Sitzungen oder Wiederherstellungstoken.

In Zenith Blueprint, Kontrollen in der Praxis, Schritt 22, Organisatorische Kontrollen, erläutert Clarysec A.5.17 als Lebenszyklusthema:

Wenn Identität die Frage ist: „Wer sind Sie?“, dann ist Authentifizierung der Nachweis. Maßnahme 5.17 ist der Punkt, an dem Theorie auf Vertrauen trifft. Sie verlangt, dass Authentifizierungsinformationen über ihren gesamten Lebenszyklus sicher verwaltet werden, damit die Methoden und Zugangsdaten zur Überprüfung einer Identität nicht selbst zum schwächsten Glied werden.

Ein Passkey ist nicht konform, nur weil er existiert. Er wird belastbar, wenn Sie zeigen können, wie er registriert, gebunden, geschützt, wiederhergestellt, widerrufen, protokolliert und überprüft wird.

Passwörter modernisieren, ohne Audit-Nachvollziehbarkeit zu verlieren

Viele Unternehmen verwenden noch Passwortrichtlinien, die für ein anderes Bedrohungsmodell geschrieben wurden. „Zwölf Zeichen, Sonderzeichen, alle 90 Tage ändern“ ist vertraut; Vertrautheit ist jedoch nicht gleichbedeutend mit Resilienz.

NIST SP 800-63-4 bekräftigt einen moderneren Ansatz: längere Passwörter und Passphrasen, Prüfung gegen kompromittierte oder häufig verwendete Passwörter, Ratenbegrenzung, sicheres Zurücksetzen, keine pauschalen regelmäßigen Änderungen ohne Verdacht auf Kompromittierung sowie benutzerfreundliche Kontrollen, die Passwortmanager unterstützen. Das bedeutet nicht, dass jede Organisation jede Richtlinie über Nacht neu schreiben muss. Es bedeutet, dass Passwortanforderungen risikobasiert, technisch durchgesetzt und mit ISO 27001-Nachweisen abgestimmt sein sollten.

Die Clarysec-Richtlinienbibliothek für KMU bietet kleineren Organisationen eine praxisnahe Basislinie, die mit zunehmender Reife verbessert werden kann. Die User Account and Privilege Management Policy - SME legt fest:

Passwörter müssen Komplexitätsanforderungen erfüllen (z. B. mindestens 12 Zeichen, alphanumerisch mit Sonderzeichen) und mindestens alle 90 Tage geändert werden.

Dies ist ein nützlicher, durchsetzbarer Ausgangspunkt für KMU. Ein Modernisierungsprojekt nach NIST SP 800-63-4 im Jahr 2026 sollte jedoch prüfen, ob ein festes Ablaufintervall von 90 Tagen für jedes System weiterhin angemessen ist – insbesondere wenn MFA, Abgleich gegen kompromittierte Passwörter, starke Passwortlänge und kompromittierungsbedingte Zurücksetzungs-Workflows vorhanden sind. In der Praxis behalten viele Organisationen die Basislinie während der Übergangsphase bei und ergänzen anschließend einen Anhang zur Passwortmodernisierung, der über Risikobehandlung und Anwendbarkeitserklärung (SoA) genehmigt wird.

Für Unternehmensumgebungen bietet Clarysecs User Account and Privilege Management Policy einen Governance-Anker, statt jede Passwortregel fest zu codieren:

Alle Benutzerkonten müssen Passwortkomplexität und Passwortablauf gemäß der Passwortrichtlinie der Organisation durchsetzen.

Diese Formulierung ermöglicht es dem CISO, die Passwortrichtlinie an NIST SP 800-63-4 auszurichten, ohne das gesamte Rahmenwerk für Zugriffsmanagement neu zu schreiben.

Ein praxisnahes Nachweispaket zur Passwortmodernisierung sollte Folgendes enthalten:

• Aktuelle Passwortrichtlinie und genehmigten Modernisierungsanhang.
• IdP-Konfiguration mit Mindestlänge, Maximallänge und zulässigen Zeichen.
• Nachweise, dass Passwortmanager zugelassen sind, einschließlich Einfügefunktion, sofern relevant.
• Konfiguration zur Prüfung gegen kompromittierte, schwache und häufig verwendete Passwörter.
• Ratenbegrenzungs- oder Sperrrichtlinie für Online-Rateangriffe auf Passwörter.
• Workflow zum Zurücksetzen von Passwörtern mit angemessener Identitätsprüfung.
• Architektur zur Speicherung von Passwort-Hashes für Anwendungen, die Zugangsdaten speichern.
• Ausnahmenregister für Legacy-Systeme, die moderne Einstellungen nicht unterstützen.
• Verfahren zur kompromittierungsbedingten Zurücksetzung mit Verknüpfung zur Incident Response.
• Nachweise zu Benutzerkommunikation und Schulung.

Ziel ist nicht, eine Diskussion über eine bestimmte Passwortlänge zu gewinnen. Ziel ist der Nachweis, dass Passwortauthentifizierung kontrolliert, messbar und in das ISMS integriert ist.

MFA und Passkeys vom „zweiten Faktor“ zur Vertrauenssicherung weiterentwickeln

Der Vorfall am Montagmorgen begann mit MFA-Ermüdung. Deshalb fragen Auditoren zunehmend, ob MFA phishing-resistent ist – nicht nur, ob sie vorhanden ist.

Klassische MFA-Verfahren wie SMS, E-Mail-OTP, TOTP-Apps und Push-Benachrichtigungen können Risiken reduzieren, sind aber nicht gleichwertig. Passkeys und FIDO2/WebAuthn-Authentifikatoren bieten stärkere Phishing-Resistenz, weil die Authentifizierung an den legitimen Ursprung gebunden ist und Kryptografie mit öffentlichen Schlüsseln verwendet. Für risikobehaftete Benutzer, privilegierte Administratoren, Finanzfreigeber, Entwickler mit Produktionszugriff und Remote-Zugriffspfade sollte phishing-resistente MFA als Zielzustand behandelt werden, sofern keine dokumentierte und genehmigte Ausnahme besteht.

Clarysecs Unternehmensrichtlinie Secure Communications and Multi-Factor Authentication (MFA) Policy setzt die Basislinie:

Multi-Faktor-Authentifizierung (MFA): Jeder Zugriff auf das Netzwerk und die Informationssysteme der Organisation, insbesondere privilegierter Zugriff oder Remote-Zugriff, muss Multi-Faktor-Authentifizierung (MFA) erfordern (z. B. Passwort plus OTP-Token oder biometrischer Faktor). Lösungen für Multi-Faktor-Authentifizierung (MFA) müssen an Best Practices der Branche ausgerichtet sein (z. B. zeitbasierte Einmalcodes oder Hardware-Schlüssel) und so konfiguriert werden, dass sie vor nicht autorisiertem Zugriff schützen.

Für KMU legt die Access Control Policy - SME fest:

Privilegierte Konten müssen Multi-Faktor-Authentifizierung (MFA) verwenden, sofern unterstützt.

Die Formulierung „sofern unterstützt“ eröffnet KMU einen realistischen Umsetzungspfad, schafft aber zugleich eine Auditverpflichtung. Wenn ein privilegiertes System MFA nicht unterstützt, muss die Organisation kompensierende Kontrollen dokumentieren, etwa Netzwerkbeschränkungen, Privileged Access Management (PAM), Jump Hosts, kürzere Sitzungen, Überwachung, Vaulting und einen Migrationsplan.

Zenith Blueprint, Kontrollen in der Praxis, Schritt 19, beschreibt die Entwicklungsrichtung klar:

Soweit möglich, sollte reine Passwortauthentifizierung vermieden werden, insbesondere für Administratorkonten, Cloud-Konsolen, Fernzugriffswerkzeuge und alle internetseitig erreichbaren Systeme. MFA mit einem zweiten Faktor wie Hardware-Schlüssel, mobiler App oder Biometrie ist heute eine Basislinie, kein Luxus.

Passkeys fügen sich natürlich in diese Argumentation ein. Ein Passkey-Rollout sollte nicht nur als Technologie-Upgrade dargestellt werden. Er sollte als Risikobehandlung für Phishing, Credential Stuffing, MFA-Ermüdung, Passwortwiederverwendung und Kontoübernahme dokumentiert werden.

Das Passkey-Nachweismodell, das Auditoren benötigen

Passkeys können je nach Authentifikator und Ökosystem synchronisierbar, gerätegebunden, hardwaregestützt, plattformbasiert oder roamingfähig sein. Das Vertrauensniveau hängt von Registrierung, Gerätevertrauen, Wiederherstellung, Kontobindung und Widerruf ab. Ein Passkey-Projekt ohne Nachweise kann Auditunklarheit erzeugen, selbst wenn die Technologie stark ist.

Nutzen Sie dieses Modell, um einen auditfähigen Passkey-Rollout vorzubereiten.

Dies ist direkt mit ISO/IEC 27001:2022 verzahnt. Die Abschnitte 4.1 bis 4.4 verlangen, dass Organisationen Kontext, interessierte Parteien, ISMS-Geltungsbereich und operative Prozesse verstehen. Die Abschnitte 5.1 bis 5.3 verlangen Führung, Richtlinie, organisatorische Rollen und Rechenschaftspflicht. Die Abschnitte 6.1.2 und 6.1.3 verlangen einen wiederholbaren Prozess für die Informationssicherheitsrisikobeurteilung und Risikobehandlung, einschließlich Kontrollauswahl, Abgleich mit Anhang A, Anwendbarkeitserklärung und Genehmigung des Restrisikos durch den Risikoverantwortlichen. Abschnitt 6.2 verlangt messbare Informationssicherheitsziele.

Das bedeutet: Ein Passkey-Rollout sollte im ISMS wie folgt erscheinen:

• Als Risikobehandlung für Zugangsdatendiebstahl und Phishing.
• Als Ziel, etwa „90 Prozent des privilegierten Zugriffs bis Q3 auf phishing-resistente MFA migriert“.
• Als Begründung in der Anwendbarkeitserklärung (SoA), verknüpft mit A.5.16, A.5.17 und A.8.5.
• Als Aktualisierung der Zugriffskontrollrichtlinie.
• Als Anwendungsfall für Protokollierung und Überwachung.
• Als Auditnachweispaket.

In Zenith Blueprint, Phase Risikomanagement, Schritt 13, Risikobehandlungsplanung und Anwendbarkeitserklärung, beschreibt Clarysec die SoA als Brücke:

Die SoA ist faktisch ein Brückendokument: Sie verbindet Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlich vorhandenen Kontrollen. Durch ihre Fertigstellung prüfen Sie zugleich, ob Sie Kontrollen übersehen haben.

Für NIST SP 800-63-4 ist diese Brücke der Ort, an dem Passwort-, MFA- und Passkey-Entscheidungen auditierbar werden.

Cross-Compliance-Zuordnung für ISO 27001, NIS2, DORA, GDPR, NIST CSF und COBIT

Identitätsnachweise werden besonders wirksam, wenn ein Maßnahmenpaket mehrere Verpflichtungen erfüllt.

NIS2 Article 21 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung geeigneter und verhältnismäßiger technischer, operativer und organisatorischer Maßnahmen, die Risiko, Stand der Technik, Implementierungskosten, Größe und Auswirkungen von Vorfällen berücksichtigen. Article 21(2) umfasst Risikoanalyse, Richtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Bewertung der Kontrollwirksamkeit, Cyberhygiene und Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management sowie – soweit angemessen – Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung. Article 20 macht Genehmigung durch das Management, Aufsicht und Cybersicherheitsschulung zu einer Governance-Verpflichtung.

DORA überführt dasselbe Identitätsthema in die finanzielle operationale Resilienz. Erfasste Finanzunternehmen müssen ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken mit Verantwortung des Leitungsorgans, Schutz- und Präventionskontrollen, Zugriffskontrolle, Authentifizierung, Überwachung, Anomalieerkennung, Kontinuität, Reaktion, Wiederherstellung und Schulung unterhalten. Articles 8 bis 10 sind besonders relevant für die Identifizierung von IKT-Assets und Abhängigkeiten, den Schutz von IKT-Systemen, Zugriffskontrolle, starke Authentifizierung, Überwachung und Erkennung. Articles 17 bis 19 verknüpfen dieselben Nachweise mit dem Management und der Meldung IKT-bezogener Vorfälle.

GDPR gilt überall dort, wo personenbezogene Daten in seinem räumlichen und sachlichen Anwendungsbereich verarbeitet werden. Article 5(1)(f) verlangt, dass personenbezogene Daten mit angemessener Sicherheit verarbeitet werden. Article 5(2) verlangt Rechenschaftspflicht. Article 32 verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Ein gestohlenes Passwort oder ein kompromittierter Authentifikator kann zu einer Verletzung des Schutzes personenbezogener Daten werden, wenn dadurch nicht autorisierter Zugriff auf personenbezogene Daten entsteht.

NIST CSF 2.0 ergänzt eine hilfreiche Managementperspektive. Seine GOVERN Function verlangt, dass rechtliche, regulatorische und vertragliche Cybersicherheitsanforderungen, einschließlich Datenschutzverpflichtungen, verstanden und gesteuert werden. CSF Profiles helfen Organisationen, Ist- und Zielzustände zu vergleichen und priorisierte Maßnahmenpläne zu erstellen.

COBIT 2019 und ISACA-Auditansätze fragen, ob Identitäts- und Zugriffskontrollen Governance-Ziele unterstützen, ob Managementpraktiken definiert sind, ob die Authentifizierungsstärke dem Risiko entspricht und ob der Betrieb der Kontrollen nachgewiesen ist.

Derselbe IdP-Bericht zu bedingtem Zugriff kann ISO 27001-Zugriffskontrolle, NIS2-MFA, DORA-Authentifizierung, GDPR-Sicherheitsrechenschaft und Fortschritt im Zielprofil nach NIST CSF unterstützen.

Ein Nachweispaket für Authentifikatoren an einem Nachmittag erstellen

Ein CISO, Compliance-Manager oder IT-Leiter kann schnell ein hochwertiges Nachweispaket erstellen, indem er sich auf ein risikobehaftetes System konzentriert, etwa eine Cloud-Konsole, Finanzplattform, ein Kunden-Administrationsportal oder eine Produktionsbereitstellungsumgebung.

Definieren Sie zunächst den Geltungsbereich. Identifizieren Sie Geschäftsverantwortliche, Datenklassifizierung, Benutzergruppen, privilegierte Rollen, Remote-Zugriffspfade, aktuelle Authentifikatoren, betroffene personenbezogene Daten und Abhängigkeiten von Drittparteien. Dies unterstützt ISO/IEC 27001:2022 Abschnitte 4.1 bis 4.4, weil Geltungsbereich, Anforderungen interessierter Parteien und Abhängigkeiten verstanden werden müssen.

Erfassen Sie zweitens die aktuellen Authentifizierungseinstellungen. Exportieren oder dokumentieren Sie per Screenshot Passwortrichtlinie, MFA-Durchsetzung, Passkey- oder FIDO2-Konfiguration, Regeln für bedingten Zugriff, Sitzungszeitüberschreitung, Wiederherstellungsmethoden, Break-Glass-Konten und Status von Legacy-Authentifizierung. Wenn das System lokale Authentifizierung verwendet, dokumentieren Sie den Grund und definieren Sie einen Migrationspfad.

Vergleichen Sie drittens mit einem klaren Zielzustand:

• Passwörter werden auf schwache, häufige und kompromittierte Zugangsdaten geprüft.
• Kein reiner Passwortzugriff für privilegierte, Remote- oder internetseitig erreichbare Systeme.
• Phishing-resistente MFA für Administratoren und risikobehaftete Benutzer.
• Sichere Registrierung und Wiederherstellung.
• Widerruf von Authentifikatoren bei Austritt oder Geräteverlust.
• Protokollierung erfolgreicher und fehlgeschlagener Authentifizierung, MFA-Nutzung und Änderungen an Authentifikatoren.
• Warnmeldungen bei Impossible Travel, wiederholten Fehlschlägen, Registrierung neuer Authentifikatoren und risikobehafteten Anmeldungen.

Fügen Sie viertens Richtliniennachweise hinzu. Die KMU-Richtlinie Access Control Policy - SME verlangt:

Eindeutige Benutzernamen sind erforderlich; gemeinsame Konten sind verboten.

Für Nachweise zum Kontenlebenszyklus legt die KMU-Richtlinie User Account and Privilege Management Policy - SME fest:

Protokolle zur Kontenerstellung, Kontodeaktivierung und zu Änderungen von Berechtigungen müssen mindestens 12 Monate sicher aufbewahrt werden.

Für Authentifizierungsprotokollierung spezifiziert Clarysecs Logging and Monitoring Policy - SME:

Authentifizierungsprotokolle: erfolgreiche und fehlgeschlagene Anmeldeversuche, Sitzungsdauer, MFA-Nutzung

Für Unternehmensimplementierungen verlangt die Logging and Monitoring Policy die Protokollierung von:

Benutzerauthentifizierung und Zugriffsversuchen

Aktualisieren Sie fünftens die Anwendbarkeitserklärung. Markieren Sie A.5.16, A.5.17 und A.8.5 als anwendbar und ergänzen Sie Hinweise wie:

• Unterstützt die Erwartungen aus NIST SP 800-63-4 an den Lebenszyklus von Authentifikatoren.
• Unterstützt die Erwartungen aus NIS2 Article 21 an Zugriffskontrolle und MFA.
• Unterstützt die Anforderungen aus DORA an Authentifizierung und Überwachung im IKT-Risikomanagement.
• Unterstützt GDPR Article 32 zu Sicherheit und Rechenschaftspflicht beim Zugriff auf personenbezogene Daten.
• Ausnahme: Das Legacy-Abwicklungsportal unterstützt FIDO2 nicht. Kompensierende Kontrollen umfassen VPN-Beschränkung, Überwachung privilegierter Sitzungen, Abhilfeplan des Lieferanten und monatliche Berechtigungsüberprüfung.

Erstellen Sie abschließend einen Ordner mit dem Namen „Nachweispaket Authentifizierung – Q2 2026“ mit Richtlinienauszügen, Risikobeurteilung, Behandlungsaufzeichnung, SoA-Auszug, IdP-Konfiguration, MFA- und Passkey-Abdeckungsbericht, Liste privilegierter Benutzer, Ausnahmenregister, Registrierungs- und Widerrufsprotokollen, Austrittstest-Stichprobe, SIEM-Abfragen, Screenshots von Warnmeldungen, Auszug aus dem Incident-Response-Playbook und Kommunikation zur Benutzersensibilisierung.

Das ist der Unterschied zwischen „Wir nutzen MFA“ und „Wir können Governance für sichere Authentifizierung nachweisen“.

Wie unterschiedliche Auditoren dieselben Identitätskontrollen prüfen

Ein reifes Identitätsprogramm antizipiert unterschiedliche Auditperspektiven.

Der ISO 27001-Auditor beginnt beim Managementsystem. Er fragt, wie Identitätsrisiken beurteilt wurden, warum Kontrollen ausgewählt wurden, wie sie in der SoA erscheinen, ob Richtlinien genehmigt sind, ob Verantwortlichkeiten zugewiesen sind und ob Nachweise den Betrieb über die Zeit belegen. Er prüft die Konsistenz zwischen Risikoregister, Zugriffskontrollrichtlinie, IdP-Einstellungen und Protokollen.

Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 19, Audit-Checkliste für Maßnahmen 8.1 bis 8.5, beschreibt die praktische Auditfrage:

Auditoren werden nach Einstellungen zur Passwortkomplexität und deren Durchsetzung fragen (Active Directory GPOs, IdP-Richtlinien usw.). Zeigen Sie Dokumentation zur MFA-Einführung, für wen sie gilt, wo sie durchgesetzt wird und welche Systeme geschützt sind.

Ein DORA- oder NIS2-Auditor konzentriert sich auf Governance, Resilienz und systemisches Risiko. Er kann Nachweise zur Aufsicht durch Leitungsorgan oder Management, Abdeckung kritischer Systeme, Authentifizierungsverpflichtungen von Drittparteien, Kontinuitätstests und Nachweise verlangen, dass Wiederherstellungsverfahren nur durch authentifiziertes Personal eingeleitet werden können.

Ein GDPR-Prüfer konzentriert sich auf personenbezogene Daten. Er fragt, ob Authentifizierung personenbezogene Daten vor nicht autorisiertem Zugriff schützt, ob der Zugriff auf das Notwendige beschränkt ist, ob Protokolle die Bewertung von Datenschutzverletzungen unterstützen und ob die Organisation Rechenschaftspflicht nachweisen kann.

Ein an NIST orientierter Prüfer kann NIST CSF 2.0 Profiles verwenden, um Ist- und Zielzustände zu vergleichen. Er erwartet einen priorisierten Maßnahmenplan für Governance, Richtlinien, Zugriffskontrolle, Erkennung und Reaktionsergebnisse.

Ein COBIT 2019- oder ISACA-Auditor bewertet, ob Identitäts- und Authentifizierungspraktiken Governance-Ziele, Kontrolldesign, Kontrollbetrieb, Funktionstrennung, privilegierten Zugriff und Überwachung unterstützen. Ihn interessiert möglicherweise nicht, welche Passkey-Marke Sie verwenden. Entscheidend ist, ob die Kontrolle gesteuert, gemessen, verantwortet und verbessert wird.

Austritt, Wiederherstellung und nichtmenschliche Identitäten nicht vergessen

Viele Authentifizierungsprogramme wirken bei der Anmeldung stark und sind überall sonst schwach.

Austritt ist ein häufiger Schwachpunkt. Clarysecs Onboarding and Termination Policy enthält ausdrücklich:

Widerruf von MFA-/SSO-Token, Smartcards oder Zertifikaten

Diese Klausel muss getestet werden. Wählen Sie drei ausgeschiedene Benutzer aus und weisen Sie nach, dass Konten, Sitzungen, MFA-Geräte, Passkeys, Zertifikate und Wiederherstellungsmethoden fristgerecht widerrufen wurden. Wenn Sie den Token-Widerruf nicht nachweisen können, ist Ihre Austrittskontrolle unvollständig.

Wiederherstellung ist ein weiterer Schwachpunkt. Wenn ein Helpdesk MFA nach zwei einfachen Fragen zurücksetzen kann, greift der Angreifer die Helpdesk-Wiederherstellung statt die Anmeldung an. Wiederherstellungsverfahren müssen starke Verifikation, Ticketprotokollierung, Genehmigung für privilegierte Benutzer, Benutzerbenachrichtigung und Überwachung der Aktivität nach der Wiederherstellung verlangen.

Nichtmenschliche Identität ist der dritte blinde Fleck. Zenith Blueprint Schritt 22 stellt klar, dass Authentifizierungsinformationen „Passwörter, PINs, kryptografische Schlüssel, biometrische Vorlagen, Smartcards, Token, Zertifikate, OAuth-Token, SSH-Schlüssel, API-Geheimnisse“ umfassen. Angreifer nutzen häufig API-Token, Schlüssel von Servicekonten und OAuth-Genehmigungen, um persistent zu bleiben. Behandeln Sie diese Zugangsdaten unter A.5.17 – mit Vaulting, Eigentümerschaft, Rotation, Widerruf und Protokollierung.

Wie ein guter Sollzustand im Jahr 2026 aussieht

Ein reifes Identitätskontrollumfeld im Jahr 2026 weist folgende Merkmale auf:

• Das Leitungsorgan oder Management versteht Identitätsrisiken und genehmigt die Zielrichtung.
• Die Passwortrichtlinie ist modernisiert, benutzerfreundlich und technisch durchgesetzt.
• Reiner Passwortzugriff ist für privilegierte, Remote- und internetseitig erreichbare Systeme beseitigt.
• Passkeys oder FIDO2-Authentifikatoren werden für risikobehafteten Zugriff priorisiert.
• MFA-Ausnahmen sind dokumentiert, genehmigt, zeitlich begrenzt und kompensiert.
• Registrierung, Wiederherstellung und Widerruf von Authentifikatoren sind kontrolliert.
• Austritt umfasst den Widerruf von Konto, Token, Zertifikat, Sitzung und Passkey.
• Authentifizierungsprotokolle umfassen Erfolge, Fehlschläge, MFA-Nutzung, Sitzungsdauer und Änderungen an Authentifikatoren.
• SIEM-Anwendungsfälle erkennen Credential Stuffing, Impossible Travel, verdächtige Registrierung und MFA-Ermüdung.
• Die SoA erläutert, warum A.5.16, A.5.17 und A.8.5 anwendbar sind.
• Zuordnungen zu NIS2, DORA, GDPR und NIST CSF werden einmal erfasst und wiederverwendet.
• Nachweise werden kontinuierlich gesammelt und nicht panisch kurz vor dem Audit zusammengestellt.

So wird NIST SP 800-63-4 mehr als ein Referenzdokument. Es wird zu einem lebenden Kontrollsystem, das Sicherheit, Datenschutz, Resilienz und Auditbereitschaft unterstützt.

Identitätskontrollen in auditfähige Nachweise überführen

Wenn Ihre Organisation Passwortregeln aktualisiert, phishing-resistente MFA einführt, Passkeys bereitstellt oder sich auf Auditfragen zu ISO 27001, NIS2, DORA oder GDPR vorbereitet, beginnen Sie nicht allein mit der Werkzeugkonfiguration.

Beginnen Sie mit dem Nachweismodell.

Clarysec kann Sie dabei unterstützen:

• Erwartungen aus NIST SP 800-63-4 zu Passwörtern, MFA und Passkeys ISO/IEC 27001:2022 zuzuordnen.
• Eine Richtlinie und ein Nachweispaket für den Lebenszyklus von Authentifikatoren aufzubauen.
• Richtlinien zu Zugriffskontrolle, MFA, Protokollierung, Onboarding und Austritt zu aktualisieren.
• Eine Anwendbarkeitserklärung zu erstellen, die Identitätsrisiken mit Kontrollen verknüpft.
• Zenith Blueprint zu nutzen, um Umsetzungsschritte und Auditbereitschaft zu strukturieren.
• Zenith Controls zu nutzen, um Identitätskontrollen über NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019 hinweg zuzuordnen.

Der beste Zeitpunkt, schwache Wiederherstellung, fehlenden Passkey-Widerruf oder unvollständige MFA-Durchsetzung zu entdecken, ist vor dem Vorfall, vor der Aufsichtsbehörde und bevor der Auditor fragt.

Machen Sie Ihre nächste Berechtigungsüberprüfung zu einer Nachweisüberprüfung nach NIST SP 800-63-4. Laden Sie die relevanten Clarysec-Richtlinien herunter, erkunden Sie Zenith Blueprint und nutzen Sie Zenith Controls, um die Umsetzung von Passwörtern, MFA und Passkeys in eine praktische, verhältnismäßige und auditfähige Compliance-Nachweisführung zu überführen.