Identitätsangriffe überholen Exploits als Hauptursache für Ransomware
Sicherheitsteams hörten fast ein Jahrzehnt lang, dass schnelleres Patchen der sicherste Weg sei, um Ransomware zu stoppen. Neue Daten aus 2026 zeigen, dass dieser Rat die aktuelle Bedrohungslage für Unternehmen nicht mehr widerspiegelt. Heute nutzen Angreifer vor allem Identitätskompromittierung statt Software-Exploits als Einfallstor – und eine Kontrolle, auf die sich die meisten Unternehmen verlassen, um dies zu verhindern, erweist sich als deutlich weniger wirksam als angenommen.
Dieser Beitrag erläutert, was sich geändert hat, warum eine in 97 % der Ransomware-Fälle mit kompromittierten Zugangsdaten vorhandene Kontrolle dennoch versagt hat und was das für die Priorisierung von Investitionen in Sicherheits- und Compliance-Teams in den kommenden zwölf Monaten bedeutet.
Wichtige Erkenntnisse
1. Identitätsangriffe verursachen inzwischen mehr Ransomware als Software-Exploits. Die Sophos-Studie „State of Ransomware 2026“ zeigt, dass bösartige E-Mails (26 %) und Phishing (24 %) zusammen die Ausnutzung von Schwachstellen (18 %, zuvor 32 %) als Hauptursache für Ransomware abgelöst haben.
2. MFA war vorhanden und hat dennoch versagt. In 97 % der Ransomware-Fälle, bei denen kompromittierte Zugangsdaten die Ursache waren, war Mehrfaktor-Authentifizierung bereits irgendwo in der Umgebung implementiert. Das beweist: MFA-Präsenz und vollständige MFA-Abdeckung sind nicht dasselbe.
3. Eine aktuelle Angriffskampagne zeigt, wie diese Lücke ausgenutzt wird. Zwischen dem 12. und 26. Juni 2026 nutzten Angreifer den abgekündigten OAuth Resource Owner Password Credentials Flow, führten über 81 Millionen Login-Versuche durch und kompromittierten 78 Konten in 64 Unternehmen – MFA wurde umgangen, weil sie im Authentifizierungsprozess dieses Protokolls nie vorgesehen war.
4. Missbrauch von Zugangsdaten zieht sich durch die gesamte Angriffskette, nicht nur durch das Eingangstor. Der Verizon Data Breach Investigations Report 2026 fand, dass in 39 % aller Datenschutzverletzungen Zugangsdatenmissbrauch eine Rolle spielte – selbst in einem Jahr, in dem Schwachstellenausnutzung wieder die häufigste Einstiegsmethode war.
5. Compliance-Zeitpläne verschieben sich, das zugrunde liegende Risiko bleibt jedoch bestehen. Das Department of War setzte am 13. Juli 2026 die CMMC 2.0 Phase 2-Anforderungen für Drittzertifizierungen für 60 Tage aus. Die Phase 1-Selbsteinschätzung und die DFARS 252.204-7012-Schutzanforderungen gelten weiterhin uneingeschränkt.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es auch nachweisen?
Jetzt lesen
Die Hauptursache für Ransomware hat sich von Exploits zu Identitätsangriffen und MFA-Lücken verschoben
Sicherheitsteams hörten jahrelang, dass schnelles Patchen der beste Schutz gegen Ransomware sei. Doch dieses Bedrohungsmodell passt nicht mehr zu den aktuellen Daten. Der Sophos State of Ransomware 2026 Report, basierend auf einer Umfrage unter 2.158 IT- und Cybersecurity-Verantwortlichen aus 17 Ländern, deren Unternehmen im vergangenen Jahr von Ransomware betroffen waren, zeigt: Phishing und bösartige E-Mails sind inzwischen für die Hälfte aller Ransomware-Ursachen verantwortlich. Die Ausnutzung von Schwachstellen, drei Jahre lang die Hauptursache, fiel auf 18 % (zuvor 32 %).
Schon dieser Wandel ist bemerkenswert. Doch noch wichtiger ist ein zweiter Befund derselben Umfrage: In 97 % der Fälle, in denen kompromittierte Zugangsdaten zum Einbruch führten, war Mehrfaktor-Authentifizierung bereits in irgendeiner Form implementiert. Die Kontrolle, auf die Unternehmen zur Abwehr genau dieser Angriffe setzen, war vorhanden – und hat dennoch nicht verhindert, dass der Angriff erfolgreich war.
Dieser Beitrag beleuchtet, was die Sophos-Daten tatsächlich zeigen, eine reale Angriffskampagne im Juni 2026, die den Mechanismus hinter der 97 %-Zahl demonstriert, ergänzende Daten aus dem Verizon Data Breach Investigations Report 2026 sowie eine aktuelle Compliance-Entwicklung, die für regulierte Unternehmen die Rahmenbedingungen verändert – ohne das eigentliche Risiko zu verringern. Unternehmen, die auf Kiteworks secure data exchange zur Steuerung des Zugriffs auf sensible Inhalte setzen, sind von dieser Entwicklung anders betroffen als Unternehmen, die sich allein auf Authentifizierung verlassen – und dieser Unterschied gewinnt mit jedem Quartal an Bedeutung.
Was die Sophos-Daten 2026 tatsächlich zeigen
Drei Zahlen aus dem Sophos-Report verdienen besondere Aufmerksamkeit – über die Verschiebung der Ursachen hinaus.
Erstens gaben zwei Drittel der Betroffenen (67 %) an, dass der Ransomware-Angriff für sie der bedeutendste identitätsbezogene Angriff des Jahres war. Das ist bemerkenswert, da alle Befragten per Definition einen erfolgreichen Ransomware-Angriff erlebt haben. Es zeigt: Der Identitätskompromiss war nicht nur ein Nebenaspekt, sondern der eigentliche Bruch – Verschlüsselung war lediglich der letzte Schritt, nicht der Einstiegspunkt.
Zweitens waren kompromittierte Zugangsdaten in 23 % der Fälle die konkrete Ursache, getrennt von der Kategorie Phishing und bösartige E-Mails. Zusammengenommen mit den 50 % aus Phishing und E-Mail ergibt das: Rund drei Viertel der Ransomware-Angriffe in dieser Umfrage gehen auf irgendeine Form von Identitätskompromittierung zurück, nicht auf technische Schwachstellen. Ein erfolgreicher Ransomware-Angriff durch gestohlene Zugangsdaten gilt gemäß HIPAA, DSGVO und ähnlichen Vorgaben als meldepflichtiger Datenschutzverstoß – unabhängig davon, ob Verschlüsselung das Endziel war. Der Identitätskompromiss und jeder Zugriff des Angreifers während der lateralen Bewegung lösen eigenständige Meldepflichten aus.
Drittens, und besonders relevant für Sicherheitsbudgets, die auf Authentifizierungskontrollen basieren: die MFA-Zahl. Sophos fand heraus, dass bei kompromittierten Zugangsdaten als Ursache 97 % der betroffenen Unternehmen bereits Mehrfaktor-Authentifizierung eingeführt hatten. Der Report nennt dafür zwei Gründe: unvollständige Implementierung auf allen relevanten Systemen und Umgehungstechniken, die sich schneller weiterentwickeln als die Abdeckung. Keine der beiden Erklärungen ist beruhigend, denn beide beschreiben eine Lücke, die ein Compliance-Check mit „MFA: Aktiviert“ nicht erkennt.
Warum MFA-Präsenz keine MFA-Abdeckung ist: Die OAuth-Kampagne im Juni 2026
Wie eine zu 97 % implementierte Kontrolle dennoch in 97 % der Fälle versagt, zeigte sich im selben Monat, in dem Sophos seinen Report veröffentlichte. Zwischen dem 12. und 26. Juni 2026 führten laut The Hacker News Angreifer über 81 Millionen Login-Versuche gegen Microsoft 365- und Azure-Konten durch und kompromittierten letztlich 78 Konten in 64 Unternehmen.
Die Technik bestand nicht darin, einzelne Nutzer zu täuschen, damit sie eine Push-Benachrichtigung bestätigen oder einen Einmal-Code auf einer gefälschten Login-Seite eingeben. Stattdessen nutzten die Angreifer den OAuth Resource Owner Password Credentials Flow – eine veraltete Authentifizierungsmethode, die Microsoft zwar abgekündigt hat, die aber in den meisten Azure-Mandanten aus Kompatibilitätsgründen weiterhin aktiv ist. Secure Bulletin beschreibt, wie ROPC Benutzername und Passwort direkt an den Token-Endpunkt des Identity Providers sendet – ohne interaktive Abfrage. Es gab für die Angreifer keine MFA-Herausforderung, weil das Protokoll keine erzeugte.
Die betroffenen Unternehmen verzichteten nicht aus Prinzip auf MFA. In den meisten Fällen war MFA für SaaS-Konten und bedingter Zugriff korrekt konfiguriert. VPN-Konzentratoren, Firewall-Administrationskonsolen und ältere Fachanwendungen erhielten jedoch nicht die gleiche Aufmerksamkeit, weil niemand jedes System inventarisiert hatte, auf dem Zugangsdaten ohne zweiten Faktor genutzt werden konnten. Genau diese Lücke beschreibt Sophos: MFA „war möglicherweise nicht auf allen relevanten Systemen vollständig implementiert, was Angreifern Ausnutzungsmöglichkeiten eröffnete.“
Zwei unabhängige Datenquellen mit sechs Wochen Abstand, die denselben Fehler beschreiben, sind kein Zufall, sondern ein Muster – und dieses Muster hat einen Namen: MFA-Implementierung als abgeschlossenes Projekt zu betrachten, statt als kontinuierlich überprüften Bestand. Eine formale Risikoanalyse, die jedes Authentifizierungs-Endgerät gegen den aktuellen MFA-Status abgleicht – nicht nur die SaaS-Anwendungen, bei denen sich die Durchsetzung am einfachsten nachweisen lässt – ist der Grundstein, um aus einer MFA-Richtlinie ein echtes MFA-Programm zu machen.
Das Muster hinter den Zahlen: Was der Verizon DBIR 2026 bestätigt
Skeptiker könnten die Sophos-Ergebnisse als spezifisch für Ransomware oder die OAuth-ROPC-Kampagne interpretieren. Der Verizon Data Breach Investigations Report 2026, der über 22.000 bestätigte Datenschutzverletzungen analysierte, spricht jedoch dagegen.
Verizons Daten zeigen, dass Schwachstellenausnutzung dieses Jahr wieder die häufigste Einstiegsmethode ist – ein Unterschied zur ransomware-spezifischen Sophos-Umfrage. Doch Zugangsdatenmissbrauch spielt weiterhin in 39 % aller vollständigen Angriffsketten eine Rolle. Das heißt: Es bleibt die am weitesten verbreitete Technik im gesamten Angriffsverlauf, auch wenn es nicht immer das erste Einfallstor ist. Identitätskompromittierung konkurriert nicht mit anderen Methoden um den ersten Platz in einer einzelnen Kategorie – sie taucht in verschiedenen Phasen auf: teils beim Erstzugriff, meist aber bei lateraler Bewegung und Privilegienausweitung, unabhängig vom ursprünglichen Einstieg.
Diese Unterscheidung ist entscheidend für die Investitionspriorisierung von Sicherheitsteams. Ein Schutz, der sich nur auf den Erstzugriff konzentriert – etwa durch Patchen oder MFA –, lässt den Rest der Kette weitgehend ungeregelt: also den Bereich, in dem Zugangsdaten von System zu System wandern oder ein Angreifer mit scheinbar legitimen Rechten auf Inhalte zugreift, die eigentlich geschützt sein sollten. Programme zum Management von Lieferkettenrisiken, die Identitätsgovernance auf Drittanbieter-Konten ausweiten – insbesondere Servicekonten von Dienstleistern für interne Systeme –, adressieren genau die Phase der lateralen Bewegung, die Verizons Daten als häufigstes Element in Angriffsketten identifizieren.
Compliance-Entwicklung pausiert, Risiko bleibt: Die Aussetzung von CMMC 2.0 Phase 2
Regulierte Unternehmen, insbesondere in der Verteidigungsindustrie, wurden diesen Monat daran erinnert, dass Compliance-Zeitpläne sich schneller ändern können als das eigentliche Risiko – in beide Richtungen. Am 13. Juli 2026 setzte das Department of War Phase 2 des CMMC-Programms – die Drittzertifizierung auf Level 2, die ab dem 10. November 2026 in DoD-Ausschreibungen erscheinen sollte – für 60 Tage aus, wie die offizielle Mitteilung des Department of War und Federal News Network berichten.
Was sich nicht geändert hat, sollte klar benannt werden: Eine ausgesetzte Auditpflicht ist keine ausgesetzte Verpflichtung. DFARS 252.204-7021, die Vertragsklausel rund um CMMC 2.0, bleibt bestehen. Die Anforderungen an Selbsteinschätzungen der Phase 1, die seit November 2025 gelten, sind unverändert. Und die zugrundeliegenden DFARS 252.204-7012-Schutzanforderungen für „covered defense information“ sowie die NIST 800-171-Kontrollfamilien – darunter Identifikation, Authentifizierung und Auditierung – gelten während der 60-tägigen Überprüfung uneingeschränkt weiter.
Die Identitäts- und Zugriffskontrollen, die ein Level-2-Auditor unter dem ausgesetzten Zeitplan geprüft hätte, sind genau die Kontrollen, die laut Sophos-Daten aktuell im Markt versagen. Wer die Aussetzung als Freibrief für Verzögerungen versteht, löst ein Terminproblem, lässt aber die eigentliche Gefährdung unverändert. Eine kontinuierlich gepflegte NIST 800-171-Compliance-Dokumentation, die aktuelle Identitäts- und Zugriffskontrollen auf konkrete Anforderungen abbildet – und nicht erst kurz vor der Prüfung zusammengestellt wird – ist sowohl der Nachweis, den ein ausgesetztes C3PAO-Audit verlangt hätte, als auch die Verteidigung im Rahmen des False Claims Act für den eigenen SPRS-Score.
Von Zugriffskontrolle zu Content Governance: Die Lücke nach der Authentifizierung schließen
Die taktische Antwort auf all das – mehr MFA einführen und auf mehr Systeme ausweiten – ist notwendig, aber allein nicht ausreichend. Denn die Daten zeigen, dass dieselbe Schwachstelle selbst in Umgebungen mit scheinbar vollständiger MFA-Abdeckung immer wieder ausgenutzt wird. Die nachhaltigere Lösung besteht darin, einen erfolgreichen Login als Beginn einer zweiten, eigenständigen Sicherheitsfrage zu betrachten: Was darf eine authentifizierte Identität tatsächlich tun – und kann das Unternehmen nachweisen, worauf sie zugegriffen hat?
Genau hier leisten Zugriffskontrollen auf Basis von Role-Based Access Control (RBAC) und Attribute-Based Access Control (ABAC) das, was reine Authentifizierung nicht kann. Die Data Policy Engine von Kiteworks prüft jede Anfrage zu sensiblen Inhalten anhand von Benutzerrolle, Klassifizierung und Kontext zum Zeitpunkt der Anfrage – statt sich auf ein einmaliges Authentifizierungsereignis für die gesamte Sitzung zu verlassen. Ein kompromittiertes Konto, das eine MFA-Lücke ausnutzt, muss eine zweite, unabhängige Richtlinienprüfung bestehen, bevor es auf geschützte Inhalte zugreifen kann. Die Klassifizierung sensibler Inhalte vor dem Eintritt in einen kontrollierten Kanal ist Voraussetzung für präzise ABAC-Richtlinien: Eine Policy Engine kann Zugriffe nach Sensitivitätsstufen nur dann beschränken, wenn Inhalte kategorisiert wurden. Datenminimierung bei der Berechtigungsvergabe reduziert zusätzlich das Risiko: Konten erhalten nur Zugriff auf die Inhalte, die sie für ihre Rolle benötigen – nicht auf alles, was technisch möglich wäre. So kann ein kompromittiertes Konto selbst bei MFA-Umgehung deutlich weniger Schaden anrichten.
Der Audit-Trail, den diese Policy-Schicht erzeugt, macht aus „wir vermuten einen Kompromiss“ eine prüfbare Frage im Incident Response. Die einheitliche Protokollierung von Kiteworks über Secure Email, Filesharing, Managed File Transfer und Web-Formulare hinweg ermöglicht es Sicherheitsteams, nach einem Identitätskompromiss exakt nachzuvollziehen, auf welche Inhalte, wann und von wo zugegriffen wurde – kanalübergreifend und ohne mühsames Zusammenführen einzelner Logs. Wird dieser Audit-Stream in Echtzeit an eine SIEM-Plattform angebunden, erhalten Sicherheitsteams die Verhaltenskorrelation, um anomale Aktivitäten nach der Authentifizierung – also die laterale Bewegung, die der Verizon DBIR als häufigstes Angriffsketten-Element identifiziert – frühzeitig zu erkennen, bevor es zur Exfiltration kommt. Das ist der Unterschied zwischen einer zero trust architecture nur am Netzwerk-Perimeter und einer, die bis zur Inhaltsebene reicht – dorthin, wo die eigentlichen Daten liegen, auf die es Angreifer abgesehen haben.
Der Kiteworks Data Security and Compliance Risk: 2026 Forecast Report beziffert, wie verbreitet diese Schwachstelle ist: 33 % der Unternehmen verfügen nicht über revisionssichere Audit-Trails. Diese eine Lücke korreliert mit AI-Governance-Reifegraden, die in allen anderen Dimensionen des Surveys um 20 bis 32 Punkte niedriger ausfallen. Transparenz nach der Authentifizierung ist kein nachgelagerter Kontrollmechanismus – sie ist ein Frühindikator für die Qualität der gesamten Datensteuerung im Unternehmen.
So entsteht ein identitätsresilientes Datensicherheitsprogramm
Das alles spricht nicht gegen Mehrfaktor-Authentifizierung oder dafür, sie als gescheitert zu betrachten. Es spricht dafür, Identitätsrisiken als mehrschichtiges Programm und nicht als einmalige Implementierung zu behandeln.
Starten Sie mit einer ehrlichen Bestandsaufnahme aller Systeme, Protokolle und Anwendungen, die mit Zugangsdaten erreichbar sind – nicht nur der SaaS-Anwendungen, bei denen MFA leicht konfigurierbar und nachweisbar ist. VPN-Konzentratoren, Firewall-Administrationskonsolen, SFTP-Server und jede Legacy-Anwendung mit abgekündigtem Authentifizierungs-Flow „aus Kompatibilitätsgründen“ verdienen die gleiche Aufmerksamkeit, wie sie die Juni-2026-Kampagne bei 64 Unternehmen offengelegt hat, die vermutlich glaubten, ihre MFA-Abdeckung sei vollständig.
Setzen Sie veraltete Protokolle außer Betrieb, wo immer das möglich ist, und dokumentieren Sie überall sonst eine kompensierende Kontrolle. ROPC ist aus gutem Grund abgekündigt – und vermutlich nicht das einzige Legacy-Flow, das noch Passwörter ohne interaktive Prüfung akzeptiert.
Erweitern Sie die Incident-Response-Planung um die Annahme, dass Zugangsdaten trotz MFA irgendwann kompromittiert werden – und bauen Sie SIEM- und Audit-Trail-Integrationen so auf, dass innerhalb von Stunden (statt Wochen) nachvollzogen werden kann, worauf dieses Konto zugegriffen hat. Ein dokumentierter Incident-Response-Plan, der Ransomware-Szenarien durch kompromittierte Zugangsdaten abdeckt – inklusive lateralem Bewegungs- und Exfiltrations-Review, HIPAA- oder DFARS-Meldepflichten und Credential-Rotation – gibt Sicherheitsteams die Struktur, um mit der Geschwindigkeit eines modernen Angriffs Schritt zu halten.
Nutzen Sie die Pause bei der CMMC 2.0 Phase 2 als Chance, nicht als Fristverlängerung. Unternehmen, die weiter an Identitäts-, Zugriffs- und Audit-Kontrollen arbeiten, wie sie die ausgesetzten Prüfungen abdecken sollten – insbesondere beim CUI-Handling –, sind nach Abschluss der 60-tägigen Überprüfung in einer deutlich besseren Position, unabhängig davon, wie das finale Rahmenwerk aussieht.
Was diese Entwicklung für Cyber-Versicherungen und das Reporting an den Vorstand bedeutet
Versicherer fragten in den letzten Renewal-Zyklen regelmäßig, ob MFA eingeführt ist, und werteten eine positive Antwort als Risikominderung. Die Sophos-Daten widerlegen diese Annahme: Ein „Ja“ auf die MFA-Frage sagt wenig darüber aus, ob die Abdeckung vollständig ist. Wer ehrlich antwortete und dennoch durch eine MFA-Lücke Opfer eines Ransomware-Angriffs wurde, steht bei der nächsten Verlängerung schlechter da als ein Unternehmen, das nie vollständige Abdeckung behauptet hat.
Vorstände und Prüfungsausschüsse stellen eine ähnliche Frage, meist als „Sind wir abgesichert?“ statt „Wo sind die Lücken?“. Ein sinnvollerer Vorstands-KPI ersetzt die binäre MFA-Frage durch eine differenzierte: Welcher Prozentsatz der Systeme mit Zugriff auf sensible Inhalte erzwingt heute MFA – und wie sieht der Plan aus, die restlichen Lücken zu schließen? Diese Sichtweise macht aus einer Compliance-Checkbox eine kontinuierliche Messgröße, die das Sicherheitsteam quartalsweise berichten kann – so wie ein Dashboard für gesteuerte Aktivitäten Risiken aggregiert, statt nur einen einzelnen Status anzuzeigen.
Auch für Versicherungs-Gespräche ist diese Neuausrichtung entscheidend. Ein Unternehmen, das eine aktuelle, konkrete Übersicht über MFA-Lücken vorlegen kann – zusammen mit einem gesteuerten Audit-Trail, der zeigt, worauf jedes Konto über E-Mail, Filesharing und Managed File Transfer zugegriffen hat –, demonstriert eine ganz andere Risikoposition als eines, das nur eine Richtlinie mit MFA-Pflicht vorweisen kann. Ersteres ist die Art von Nachweis, die Versicherer zunehmend direkt verlangen; letzteres ist die Art von Antwort, die laut Sophos-Daten nicht mehr ausreicht. Dokumentation zur Data Governance, die abbildet, auf welche Inhalte jede Credential-Klasse zugreifen kann – nach Sensitivitätsstufe, mit aktuellem Zugriffsumfang und letztem Review-Datum –, ist die interne Grundlage für belastbare Vorstands-KPIs und Versicherungs-Gespräche.
Erfahren Sie mehr darüber, wie Sie die Lücke zwischen Authentifizierung und Inhaltszugriff mit gesteuertem, geprüftem Datenaustausch schließen können – fordern Sie jetzt eine individuelle Demo an.
Häufig gestellte Fragen
Der Sophos State of Ransomware 2026 Report führt die Verschiebung darauf zurück, dass es für Angreifer effizienter ist, gültige Zugangsdaten per Phishing oder bösartige E-Mails zu kompromittieren, als eine ungepatchte Schwachstelle zu finden und auszunutzen – insbesondere, da Unternehmen beim Patchen bekannter Softwarefehler schneller geworden sind. Gestohlene Zugangsdaten ermöglichen zudem oft breiteren, weniger überwachten Zugriff als ein einzelner Exploit. Deshalb machen Phishing und bösartige E-Mails inzwischen die Hälfte aller Ursachen in der Umfrage aus. Das spiegelt auch wider, dass jahrelange Investitionen in Schwachstellenmanagement auf der Exploit-Seite Wirkung zeigen, während Identitätsgovernance nicht die gleiche Aufmerksamkeit oder das gleiche Budget erhalten hat. Programme zum Management von Lieferkettenrisiken, die Identitätsgovernance auf Drittanbieter-Zugangsdaten ausweiten – etwa Servicekonten, geteilte API-Keys und Integrationstokens –, schließen die Zugangspfade, die interne MFA-Abdeckung offenlässt.
Nein. MFA bleibt eine notwendige Kontrolle. Sophos stellt nicht fest, dass MFA als Technologie versagt, sondern dass die MFA-Abdeckung oft unvollständig über alle Systeme hinweg ist, die mit Zugangsdaten erreichbar sind. Die Lösung ist, MFA und Zugriffskontrollen auf jedes System auszuweiten – inklusive VPNs, Admin-Konsolen und Legacy-Anwendungen – und nicht, Authentifizierungskontrollen zugunsten anderer Maßnahmen aufzugeben. Die Kombination aus vollständiger MFA-Abdeckung und ABAC-Richtlinien auf Inhaltsebene – sodass ein Konto, das MFA umgeht, dennoch eine zweite unabhängige Autorisierungsprüfung für regulierte Daten bestehen muss – verschafft Unternehmen eine Defense-in-Depth-Position, die reine Authentifizierung nicht bieten kann.
Sie bedeutet, dass die konkrete Anforderung für Drittzertifizierungen auf Level 2, die ab dem 10. November 2026 in DoD-Ausschreibungen erscheinen sollte, für eine 60-tägige Überprüfung (Ankündigung am 13. Juli 2026) pausiert ist. Die DFARS-Verpflichtungen bestehen jedoch weiterhin. Die Phase 1-Selbsteinschätzung und die DFARS 252.204-7012-Schutzanforderungen für „covered defense information“ gelten während der Überprüfung uneingeschränkt. Auftragnehmer sollten die Pause als Chance sehen, bestehende Lücken zu schließen, bevor das überarbeitete Rahmenwerk veröffentlicht wird – und nicht als Grund, CMMC 2.0 Compliance-Aktivitäten zu vernachlässigen. Eine Risikobewertung nach dem vollständigen NIST 800-171-Kontrollsatz – mit Nachweisen auf dem Niveau, das ein C3PAO erwarten würde – ist die beste Verteidigung während der Aussetzung und der nützlichste Input für das RFI der CMMC Reform Task Force.
MFA prüft, wer sich zu einem bestimmten Zeitpunkt anmeldet. ABAC bewertet jede nachfolgende Anfrage zu bestimmten Inhalten anhand von Attributen wie Benutzerrolle, Klassifizierung und Kontext. Ein Konto, das die Authentifizierung besteht, muss also eine separate, fortlaufende Autorisierungsprüfung bestehen, bevor es auf sensible Daten zugreifen kann. Beide Kontrollen greifen an unterschiedlichen Stellen der Angriffskette und ergänzen sich, statt sich zu überschneiden. Die Klassifizierung von Daten vor dem Eintritt in gesteuerte Systeme ist Voraussetzung für präzise ABAC-Prüfung: Policy Engines können Sensitivitätsbeschränkungen nur für kategorisierte Daten durchsetzen.
Erstellen Sie eine Übersicht aller Anwendungen und Protokolle, die noch Benutzername und Passwort ohne interaktive MFA-Prüfung akzeptieren – mit Fokus auf VPNs, Admin-Konsolen und Legacy-Fachanwendungen, statt von der SaaS-Abdeckung auf die gesamte Umgebung zu schließen. Ergänzen Sie diese Übersicht durch eine Audit-Trail-Prüfung, um sicherzustellen, dass das Unternehmen nachvollziehen kann, worauf jedes Konto zugegriffen hat – nicht nur, ob die Authentifizierung erfolgreich war. Wo ein Legacy-Protokoll nicht sofort außer Betrieb genommen werden kann, dokumentieren Sie eine kompensierende Kontrolle und ein Abschaltdatum, statt es als offene Ausnahme stehen zu lassen. Aktualisieren Sie den Incident-Response-Plan um ROPC-spezifische Indikatoren für Kompromittierungen – etwa anomale Token-Ausstellungen von Legacy-Authentifizierungsendpunkten – als Auslöser für SIEM-Alarme, damit die nächste Kampagne dieser Art als Alarm und nicht erst als forensischer Befund nach dem Vorfall erkannt wird.
Weitere Ressourcen
- Blogbeitrag Zero Trust Architecture: Never Trust, Always Verify
- Video Microsoft GCC High: Nachteile, die Defense Contractors zu intelligenteren Lösungen bewegen
- Blogbeitrag So sichern Sie klassifizierte Daten, nachdem DSPM sie erkannt hat
- Blogbeitrag Vertrauen in Generative KI aufbauen mit Zero Trust
- Video Der definitive Leitfaden für sichere Speicherung sensibler Daten für IT-Leiter