Verschlüsselung & sichere Authentifizierung

Wo sichere Authentifizierung (faktisch) Pflicht ist

12.

Jan.

2026

Authentifizierung in BSI C5, Authentifizierung in DORA, Authentifizierung in DSGVO, Authentifizierung in ISO 27001, Authentifizierung in NIS2, Authentifizierung in PCI DSS, Authentifizierung in TISAX, Gesetzliche Regelungen für Authentifizierung

Diese Zertifizierungen, Regulatoriken und Gesetze empfehlen oder verlangen den Schutz von Identitäten

Der Begriff «sichere Authentifizierung» ist der Überbegriff für Verfahren wie der

Zwei-Faktor-Authentifizierung (2FA) bzw. Mehrfaktor-Authentifizierung (MFA), also ein statisches Passwort plus OTP, TOTP, Push Notification, Token oder Biometrie
Phishing-resistenter Authentifizierung, FIDO2 Hardware Token, plattformbasierter Passkeys oder zertifikatsbasierter Anmeldung
Passwortlose Authentifizierung mit Passkeys und Magic Links
Biometrische Authentifizierung als zusätzlicher Faktor mit Fingerabdruck, Gesichtserkennung und Iris-Scan
Zertifikatsbasierter Authentifizierung mit Smartcards, Geräte- oder Benutzerzertifikate und mTLS

Dieser Blogartikel gibt Ihnen eine praxisnahe Aufschlüsselung, wo «sichere Authentifizierung» gefordert wird – getrennt nach Zertifizierungen, Regulatoriken und Gesetzen.

(Hinweis: Manche Vorgaben nennen MFA explizit, andere verlangen risikoadäquate Sicherheitsmaßnahmen, aus denen starke Authentifizierung typischerweise folgt.)

Zertifizierungen / Standards / Audit-Frameworks

ISO/IEC 27001:2022 (ISMS-Zertifizierung)

Wo relevant: Annex-A Controls zu Identity & Access (u. a. Identity Management, Authentication Information, Access Control / Access Rights).
Was das praktisch bedeutet: geregelte Vergabe/Verwaltung von Zugangsdaten, klare Identitäten, Zugriff nach Rollen/Need-to-know, robuste Authentifizierungsmechanismen (oft MFA für kritische & privilegierte Konten sowie bei Remote Access). ISMS.online

SOC 2 (AICPA Trust Services Criteria)

Wo relevant: Common Criteria CC6.x (Logical Access Controls).
Was das praktisch bedeutet: Identitätsprüfung und logische Zugriffskontrollen, saubere User-Lifecycle-Prozesse; starke Authentifizierung/MFA ist ein typischer Nachweisweg, besonders für schützenswerte Systeme und Admin-Zugänge. ISMS.online

PCI DSS v4.0 (Payment Card Industry – Kartenumfeld)

Wo relevant: Requirement 8 (Identifikation & Authentifizierung), u. a. MFA-Pflichten für Zugriffe auf die Cardholder Data Environment (CDE).
Was das praktisch bedeutet: MFA ist in PCI DSS 4.0 deutlich breiter gefordert (nicht nur „Admins“), inkl. Zugriff in/auf CDE-Systemkomponenten. OneSpan

BSI C5 (Cloud Computing Compliance Criteria Catalogue)

Wo relevant: Anforderungen an Zugriffskontrolle/Monitoring im Cloud-Kontext; C5 nennt 2FA/MFA in bestimmten Zugriffsszenarien (z. B. für besonders sensible/überwachungsrelevante Systemzugriffe).
Was das praktisch bedeutet: MFA für privilegierte Zugriffe und sicherheitskritische Verwaltungs-/Monitoring-Zugänge ist ein gängiger Prüfpunkt. BSI

TISAX (Automotive; basiert auf VDA ISA)

Wo relevant: VDA-ISA-Fragenkatalog enthält u. a. Access-Control-Themen; TISAX-Assessments prüfen, ob diese Anforderungen umgesetzt sind.
Was das praktisch bedeutet: belastbare Authentifizierung als Teil von Access Control / IAM (z. B. für kritische Systeme/Remote/privilegiert), abhängig vom Scope/Label. enx.com

IEC 62443 (Industrial / OT-Security)

Wo relevant: „Foundational Requirement“ FR1 Identification & Authentication Control; in den Detailanforderungen finden sich u. a. Vorgaben bis hin zu MFA für Schnittstellen (je nach Sicherheitslevel/Systemanforderung).
Was das praktisch bedeutet: eindeutige Identitäten + geeignete Authentifizierung für Menschen, Prozesse, Geräte; MFA kann explizit gefordert sein (system-/schnittstellenbezogen). Fortinet

Regulatoriken (EU-Verordnungen/Richtlinien + Aufsicht)

DSGVO / GDPR (Art. 32 „Sicherheit der Verarbeitung“)

Wo relevant: Art. 32 verlangt „geeignete technische und organisatorische Maßnahmen“ nach Risiko.
Was das praktisch bedeutet: Starke Authentifizierung ist ein typischer TOM-Baustein (Zugriffskontrolle, Schutz vor unbefugtem Zugriff), v. a. bei sensiblen Daten/Remote-Zugriff/administrativen Konten. Datenschutz-Grundverordnung (DSGVO)

NIS2-Richtlinie (EU) 2022/2555

Wo relevant: Mindest-Cybersecurity-Maßnahmen inkl. Access-Control-Policies und Nutzung von Multi-Factor-Authentication/Continuous Authentication.
Was das praktisch bedeutet: Für betroffene „essential/important entities“ ist MFA (oder gleichwertig) als Maßnahme ausdrücklich adressiert. EUR-Lex

DORA – Digital Operational Resilience Act (EU) 2022/2554 (Finanzsektor)

Wo relevant: DORA gilt seit 17. Januar 2025; konkretisierende Aufsichtshinweise betonen starke Authentifizierung für privilegierte/remote Zugriffe (PAM etc.).
Was das praktisch bedeutet: starke Authentifizierung und Privileged Access Management werden im DORA-Umfeld als zentrale Kontrollen erwartet. EIOPA

PSD2 / RTS zur „Strong Customer Authentication“ (SCA) – Delegierte VO (EU) 2018/389

Wo relevant: Bei Zahlungsdiensten/Online-Zahlungen/Account-Access ist SCA der Kernbegriff.
Was das praktisch bedeutet: mindestens 2 Faktoren (Wissen/Besitz/Inhärenz) plus Anforderungen an die sichere Kommunikation – sehr konkret und prüfbar. EUR-Lex

eIDAS (VO (EU) Nr. 910/2014; E-Identitäten/Trust Services)

Wo relevant: „Assurance Levels“ (low/substantial/high) für elektronische Identifizierung.
Was das praktisch bedeutet: Dienste, die ein bestimmtes Vertrauensniveau verlangen, müssen Authentifizierung/Identitätsprüfung in der passenden Stärke umsetzen (z. B. high/substantial für höherwertige Transaktionen/Services). EUR-Lex

BaFin BAIT (Bankaufsichtliche Anforderungen an die IT) / Aufsichtserwartungen

Wo relevant: BAIT nennt als Beispiele u. a. die Auswahl geeigneter Authentifizierungsverfahren (inkl. starker Authentifizierung bei Remote-Zugriff).
Was das praktisch bedeutet: Im Finanzbereich werden starke Authentifizierung und sichere Remote-Admin-Zugriffe regelmäßig erwartet und geprüft. BaFin

Gesetze - v. a. Deutschland; „Stand der Technik“-Pflichten

BSIG § 8a (Kritische Infrastrukturen / KRITIS) + BSI-Konkretisierung

Wo relevant: KRITIS-Betreiber müssen angemessene TOM nach „Stand der Technik“ umsetzen und regelmäßig nachweisen; das BSI veröffentlicht hierzu Konkretisierungen.
Was das praktisch bedeutet: Starke Authentifizierung ergibt sich typischerweise aus „Stand der Technik“ für kritische/administrative/remote Zugriffe (auch wenn nicht immer als einzelnes Wort „MFA“ im Gesetzestext steht, ist es ein gängiger Nachweisbaustein in Prüf- und Maßnahmenkatalogen).

(Einordnung) IT-Sicherheitsgesetz 2.0 / Weiterentwicklung KRITIS-Pflichten

Wo relevant: erweitert/verschärft die KRITIS- und BSIG-Pflichten in Deutschland (systematisch weiterhin „Stand der Technik“ + Nachweise).

Was das praktisch bedeutet: Gleiche Logik: sichere Authentifizierung ist ein Kernbaustein zur Erfüllung der TOM-Pflichten im KRITIS-Kontext (insb. bei priveligierten Konten wie Admin Accounts und bei Remote Access)

k

**Mini-Merkschema: „Wann ist sichere Authentifizierung zwingend?“**

Explizit (MFA/SCA explizit als Erfordernis genannt): PSD2/RTS SCA, NIS2 (MFA/Continuous Authentication), PCI DSS v4.0 (MFA-Requirements), IEC 62443 (je nach Anforderung), teils BSI C5.
Implizit (Umsetzung, wenn risikoadäquat erforderlich oder Stand der Technik vorgegeben ist): DSGVO Art. 32, BSIG §8a (KRITIS), ISO 27001, SOC2, TISAX – dort ist starke Authentifizierung meistens der „erwartbare“ Weg, um Zugriffskontrollanforderungen prüfbar zu erfüllen.

Pflichtenmatrix (Auth-Szenarien × Sektoren)

Hier die Pflichtenmatrix „Sichere Authentifizierung“ (EU/DE-Fokus) für die jeweiligen Sektoren / Branchen.
Legende je Zelle: MUSS = explizit gefordert / praktisch zwingend nachweisbar, SOLL = „Stand der Technik“ / risikobasiert erwartet, KANN = je nach Scope/Schutzbedarf.

Auth-Szenario / Mindestkontrolle	Automotive	Finance	KRITIS	OT (Industrie/ICS)	Healthcare	Kommunaler Straßenverkehr	Transport (Logistik/ÖPNV etc.)
A) Kunden-/Nutzerzugänge (extern)	SOLL (OEM-Portale/Apps; Risiko)	MUSS (PSD2/SCA für Payment-Account-Zugriff & Zahlungen)	SOLL (risikobasiert)	KANN (selten extern; wenn doch → Risiko hoch)	SOLL (Patienten-/Portalzugänge; DSGVO-TOM)	SOLL (Bürger-/Portalzugänge; Risiko)	SOLL (Ticketing/Portale; Risiko)
B) Mitarbeiterzugänge (normaler Zugriff)	SOLL (TISAX/ISO-Programme)	SOLL→MUSS (BAIT/EBA-Erwartung, je nach Kritikalität)	SOLL→MUSS (Stand der Technik in KRITIS-Nachweisen)	SOLL (IEC 62443 FR1: Identität+Auth für Nutzer/Entitäten)	SOLL→MUSS (B3S Krankenhaus/Stand der Technik)	SOLL (NIS2/„Access control policies“)	SOLL (NIS2 Transport-Sektor)
C) Remote Access (VPN/VDI/Jump Host)	MUSS (wenn NIS2-Scope) / sonst SOLL	MUSS (BAIT: starke Auth bei Remote; plus DORA-Erwartung)	MUSS (Stand der Technik; NIS2 nennt MFA/Continuous Auth als Maßnahme)	MUSS (OT-Remote ist Hochrisiko; IEC 62443 + „MFA/strong auth“)	MUSS (B3S/Stand der Technik)	MUSS (wenn NIS2-Scope) / sonst SOLL	MUSS (wenn NIS2-Scope) / MUSS bei KRITIS-Schwelle Transport
D) Privilegierte Konten (Admin, Root, Domain Admin, Cloud-Console)	SOLL→MUSS (in Audits praktisch zwingend)	MUSS (DORA/BAFin-Hinweise: PAM + starke Auth)	MUSS (Stand der Technik)	MUSS (IEC 62443 FR1/UC + SL-abhängig)	MUSS (B3S Krankenhaus)	MUSS (wenn NIS2-Scope) / sonst SOLL	MUSS bei NIS2/KRITIS-Schwelle
E) Service Accounts / Maschinenidentitäten	SOLL (Zertifikate/Key-Mgmt)	MUSS/SOLL (EBA-ICT-Guidelines)	MUSS (Stand der Technik)	MUSS (IEC 62443)	SOLL→MUSS	SOLL	SOLL→MUSS
F) Drittanbieter-/Wartungszugänge	SOLL→MUSS	MUSS (DORA + PAM)	MUSS	MUSS	MUSS	SOLL→MUSS	MUSS

Auth-Szenario / Mindestkontrolle	Automotive	Finance	KRITIS	OT (Industrie/ICS)	Healthcare	Kommunaler Straßenverkehr	Transport (Logistik/ÖPNV etc.)
A) Kunden-/Nutzerzugänge (extern)	SOLL (OEM-Portale/Apps; Risiko)	MUSS (PSD2/SCA für Payment-Account-Zugriff & Zahlungen)	SOLL (risikobasiert)	KANN (selten extern; wenn doch → Risiko hoch)	SOLL (Patienten-/Portalzugänge; DSGVO-TOM)	SOLL (Bürger-/Portalzugänge; Risiko)	SOLL (Ticketing/Portale; Risiko)
B) Mitarbeiterzugänge (normaler Zugriff)	SOLL (TISAX/ISO-Programme)	SOLL→MUSS (BAIT/EBA-Erwartung, je nach Kritikalität)	SOLL→MUSS (Stand der Technik in KRITIS-Nachweisen)	SOLL (IEC 62443 FR1: Identität+Auth für Nutzer/Entitäten)	SOLL→MUSS (B3S Krankenhaus/Stand der Technik)	SOLL (NIS2/„Access control policies“)	SOLL (NIS2 Transport-Sektor)
C) Remote Access (VPN/VDI/Jump Host)	MUSS (wenn NIS2-Scope) / sonst SOLL	MUSS (BAIT: starke Auth bei Remote; plus DORA-Erwartung)	MUSS (Stand der Technik; NIS2 nennt MFA/Continuous Auth)	MUSS (OT-Remote ist Hochrisiko; IEC 62443)	MUSS (B3S/Stand der Technik)	MUSS (wenn NIS2) / sonst SOLL	MUSS (wenn NIS2 / KRITIS)
D) Privilegierte Konten (Admin, Root, Domain Admin, Cloud-Console)	SOLL→MUSS (in Audits praktisch zwingend)	MUSS (DORA/BAFin-Hinweise: PAM + starke Auth)	MUSS (Stand der Technik)	MUSS (IEC 62443 FR1/UC)	MUSS (B3S Krankenhaus)	MUSS (wenn NIS2) / sonst SOLL	MUSS (NIS2/KRITIS)
E) Service Accounts / Maschinenidentitäten	SOLL (Zertifikate/Key-Mgmt)	MUSS/SOLL (kritische Systeme)	MUSS (Stand der Technik)	MUSS (IEC 62443)	SOLL→MUSS	SOLL	SOLL→MUSS
F) Drittanbieter-/Wartungszugänge	SOLL→MUSS (Supply-Chain-Risiko)	MUSS (DORA + starke Auth, PAM)	MUSS	MUSS (OT-Fernwartung)	MUSS (B3S + DSGVO-TOM)	SOLL→MUSS	MUSS (NIS2/KRITIS)

Was „MUSS“ in der Praxis fast immer bedeutet (Kontrollpaket)

Diese Punkte sind in den oben als MUSS markierten Feldern praktisch Standard-Nachweis:

MFA/Strong Auth für Remote und privilegierte Zugriffe (Jump Hosts, Admin-Consoles, PAM). (NIS2 nennt MFA/Continuous Auth explizit als Maßnahme; BAIT/DORA-Hinweise sehr klar.)
Eindeutige Identitäten (keine Shared Accounts), Least Privilege, saubere Joiner/Mover/Leaver-Prozesse. (NIS2 u. Access-Control-Policies; IEC 62443 FR1; KRITIS-„Stand der Technik“ in Nachweisen).
PAM + Session-Kontrollen/Logging für Admins (Finance besonders ausgeprägt).
Maschinenidentitäten/Secrets: Zertifikate/Keys, Rotation, kein Hardcoding, getrennte Umgebungen.

Sektor-spezifische „Trigger“, wann aus SOLL → MUSS wird

Finance: Sobald Sie PSD2-relevante Flows haben → SCA zwingend; plus DORA/BAIT machen starke Auth für Remote/Privileged faktisch obligatorisch.
KRITIS: Sobald Sie als Betreiber unter BSIG §8a/BSI-KritisV fallen → „Stand der Technik“ ist Nachweisgegenstand, und starke Auth für Admin/Remote ist praktisch unvermeidbar.
OT: Sobald ICS/SCADA produktiv betroffen ist → IEC-62443-Logik (FR1) + OT-Fernwartung = „höchste Stufe“ Auth-Kontrollen.
Healthcare: Krankenhaus-KRITIS oder B3S-orientierte Sicherheitsprogramme → starke Auth für Remote/Privileged wird regelmäßig gefordert.
Transport / kommunaler Straßenverkehr: Wenn NIS2-Betroffenheit (Größe/Scope) oder KRITIS-Schwellenwerte Transport & Verkehr erreicht → Zugriffskontrollen inkl. MFA-Maßnahmen werden Pflichtniveau.

FAZIT:

Zertifizierungen, Regulatoriken und Gesetze verlangen zunehmend eine starke, sichere Authentifizierung als grundlegende Sicherheitsmaßnahme. Während manche Vorgaben MFA/2FA ausdrücklich fordern, schreiben andere risikoadäquate Kontrollen vor, aus denen sichere Authentifizierung faktisch folgt. In der Praxis bedeutet das: eindeutige Nutzeridentitäten, sauberes Credential-Management sowie besonders geschützte Remote- und privilegierte Zugriffe sind heute kein „Best Practice“ mehr, sondern ein zentraler Compliance- und Sicherheitsstandard.