CISA KEV FortiMail: Due 4.10. – IBE aus oder Hoffnung

Freitag, 2. Oktober 2026. Der KEV-Katalog der US-Behörde CISA hat einen neuen Eintrag, und der trägt einen Namen, den viele Mail-Betreibende kennen: FortiMail. Fällig ist er laut Katalog am Sonntag, 4. Oktober 2026. Der Clou: Die Fixes heißen bei Fortinet noch „upcoming“. Übrig bleibt ein Workaround. Er heißt IBE aus.

Das ist die Lage. Eine Frist im Kalender, aber kein Patch zum Einspielen. Wer jetzt sagt „wir patchen, sobald es da ist“, hat die Exposition nicht auf dem Board. Dieser Text sortiert die organisatorische Seite: was CISA sagt, was Fortinet sagt, was digital-magazin.de daraus rechnet und was bis Sonntag auf dem Zettel stehen sollte. Keine Technik zum Nachstellen. Nur Lage, Fragen, Zuständigkeiten.

Die These vorweg, kurz und trocken: Due in zwei Tagen ohne Exposure-Inventar und IBE-Check ist Hoffnung, kein Patch-Fenster. „Zwei Tage“ ist dabei Redaktionsrechnung, kein CISA-Wortlaut.

Die Reihenfolge ist bewusst gewählt: erst die Aussagen der Behörde, dann die des Herstellers, dann die Aufgaben. Wer nur eine Seite liest, bekommt ein schiefes Bild. Wer beide liest, hat immerhin eine Liste.

KEV-Eintrag: Was CISA sagt und was nicht

Der Alert von CISA trägt das Release Date 1. Oktober 2026. Laut CISA wurde eine neue Schwachstelle in den Katalog der Known Exploited Vulnerabilities (KEV) aufgenommen, gestützt auf Belege aktiver Ausnutzung. Der Eintrag im Alert lautet CVE-2026-104286, Fortinet FortiMail. Die Quelle ist der Alert bei CISA.

Zur Einordnung schreibt CISA, diese Art von Schwachstelle sei ein häufiger Angriffsvektor für böswillige Akteure und berge erhebliche Risiken für die Bundesverwaltung der USA. Das ist CISA-Prosa, high-level. Mehr steht dazu im Alert nicht. Wir lesen nicht mehr hinein.

Der Alert verweist auf BOD 26-04, „Prioritizing Security Updates Based on Risk“. Die Anweisung gilt für Behörden der zivilen US-Bundesverwaltung (FCEB). Sie verlangt, KEV-Einträge auf öffentlich exponierten Assets zu priorisieren, wenn die Ausnutzung volle Kontrolle über das Asset gibt. Niedrigere Risiken rücken nach hinten. Dazu sagt der Alert: BOD 26-04 lege Grunderwartungen fest, wann Behörden prüfen müssen, ob Angreifende das System kompromittiert haben, bevor der Patch eingespielt wurde.

CISA ermutigt alle Organisationen, nicht nur Bundesbehörden, zur risikobasierten Behandlung. Das ist eine Empfehlung der CISA. Keine deutsche Rechtsfolge, keine Meldepflicht, kein Bußgeldkatalog. Wer in der DACH-Region FortiMail betreibt, schuldet Washington nichts. Der eigenen Geschäftsführung schuldet man trotzdem die Antwort auf eine einfache Frage: Was hängt im Internet?

Was im Alert-Fließtext nicht steht: ein Due Date, ein CVSS-Wert, ein Ransomware-Hinweis. Das Due Date steht im Katalogeintrag selbst. Dort finden sich dateAdded 1. Oktober 2026, dueDate 4. Oktober 2026, forensicTriage: Yes und knownRansomwareCampaignUse: Unknown. Unknown heißt unbekannt. Nicht „nein“. Nicht „ja“. Und kein Freibrief.

Als geforderte Maßnahme nennt der Katalog sinngemäß: Mitigations nach Anweisung des Herstellers anwenden, BOD 26-04 beachten, die Erwartung zur Forensic Triage erfüllen und die Internet-Exposition je Asset bewerten. Ein Untersuchungsrezept ist das nicht. Eine Aufgabenliste für Verantwortliche schon.

Heute ist Freitag. Due ist Sonntag. Zwei Tage, rechnet die Redaktion, und dazwischen liegt ein Wochenende, an dem Ansprechpersonen gern im Funkloch sitzen. Wer die Frist nur in Werktagen plant, hat sie schon verbraucht. Wie schnell ein regulärer Change-Slot an so einer Frist vorbeiläuft, ohne dass etwas gehärtet wurde, steht in unserem Text über KEV und warum ein Change-Slot keine Härtung ist.

Fortinet-PSIRT: Critical, unauthentifiziert, ausgenutzt gemeldet

Fortinet führt den Fall im PSIRT als FG-IR-26-175, veröffentlicht am 1. Oktober 2026. Der Timeline-Eintrag lautet Initial publication, am selben Tag. Alles Folgende ist Angabe des Fortinet-PSIRT, keine Beobachtung von digital-magazin.de. Die Quelle ist das Fortinet-PSIRT zu FG-IR-26-175.

Die Eckdaten laut PSIRT:

• Component: GUI
• Severity: Critical
• Discovered: Internal
• Attack Type: Unauthenticated
• Known Exploited: Yes
• Virtual Patch: No

Der CVSSv3-Score liegt laut Fortinet bei 9.8.

Zur Wirkung nennt Fortinet zwei Formulierungen. Die Summary spricht davon, dass ein unauthentifizierter Angreifer auf dem darunterliegenden System beliebige Dateien schreiben kann. Das Impact-Feld der Seitenleiste nennt: Execute unauthorized code or commands, also das unerlaubte Ausführen von Code oder Kommandos. Beides Fortinet. Beides high-level. Wir glätten das nicht zu einer einzigen Aussage, und wir erklären nicht, wie es im Detail zustande kommt. Das gehört nicht in ein Magazin.

Zum Stand der Ausnutzung schreibt Fortinet sinngemäß: Es sei berichtet worden, dass die Lücke in freier Wildbahn ausgenutzt wird, Kundschaft werde dringend gebeten, den genannten Workaround anzuwenden. „Virtual Patch: No“ steht ebenfalls im PSIRT. Mehr sagt das Feld nicht, mehr deuten wir nicht hinein. Zur Herkunft gibt Fortinet an: intern entdeckt und gemeldet von Gwendal Guégniaud aus dem Fortinet-Product-Security-Team.

Wenig überraschend passt das zusammen. Known Exploited „Yes“ im PSIRT, Eintrag im KEV bei CISA. Das Pikante daran ist der Zustand dazwischen: Ausnutzung gemeldet, Workaround verfügbar, Fixes angekündigt. Drei Zeitformen in einem Advisory. Installiert ist davon nur eine, und zwar der Workaround, falls ihn jemand eingespielt hat.

Betroffene FortiMail-Stände: Wo „upcoming“ noch nichts nützt

Fortinet listet vier Zweige. Das Inventar, wie das PSIRT es führt:

• FortiMail 8.0: betroffen sind 8.0.0 bis 8.0.1. Fortinet nennt als Ziel „upcoming 8.0.2 or above“.
• FortiMail 7.6: betroffen sind 7.6.0 bis 7.6.6. Ziel laut Fortinet: „upcoming 7.6.7 or above“.
• FortiMail 7.4: betroffen sind 7.4.0 bis 7.4.8. Ziel laut Fortinet: „upcoming 7.4.9 or above“.
• FortiMail 7.2: betroffen sind 7.2.0 bis 7.2.9. Fortinet schreibt: „Upgrade to branch 7.4 or above“.

„Or above“, „upcoming“ und „branch 7.4 or above“ sind Fortinet-Wortlaut. Wir machen kein „7.4+“ daraus und schätzen keine Build-Nummer, die im PSIRT nicht steht. Auf dem Zweig 7.2 gibt es laut Tabelle keinen Punkt-Fix. Wer dort sitzt, wartet nicht auf einen kommenden Patch, sondern hat einen Zweigwechsel auf der Agenda. Das ist kein Change-Ticket. Das ist ein Projekt.

Versionszweige gehören aufs Board, nicht in den Kopf einer einzelnen Person. Je Zweig eine Spalte, je Gerät eine Karte, darauf Stand, Fix-Kandidat und Status. Das klingt nach Bürokratie, spart aber genau die Rückfrage, die am Freitagabend niemand mehr beantworten kann: Auf welchem Zweig steht das Gerät in der Außenstelle?

Der Zweigwechsel von 7.2 verdient eine eigene Karte mit eigener Verantwortung. Ein Projekt braucht Auftrag, Zeitfenster, Rückfallplan und einen Termin mit dem Fachbereich. Es braucht außerdem eine ehrliche Antwort darauf, was bis zum Wechsel gilt. Die Antwort heißt: der Workaround. Ohne ihn ist das Projekt ein Wunsch mit Projektnamen.

Und damit der Plot Twist, den man gern überliest: „Upcoming“ ist nicht installiert. Ein angekündigter Fix schließt nichts. Er steht in einer Tabelle. Bis er auf dem Gerät liegt, bleibt der Bestand, wie er ist. Und der Bestand hat eine Versionsnummer, die jemand kennen muss.

Für Betreibende heißt das ganz konkret: Versionsstand je Gerät feststellen. Zweig zuordnen. Fix-Kandidat eintragen. Ein Datum dazu, nicht „bald“. Wer auf 8.0.0 bis 8.0.1 steht, trägt 8.0.2 ein, solange es upcoming ist, und markiert den Eintrag als „nicht verfügbar“. Das ist keine Pedanterie. Das ist der Unterschied zwischen einem Plan und einer Absicht.

IBE aus: Der Workaround ist nicht der Fix

Fortinet nennt für die Zeit bis zum Fix einen Workaround: die IBE-Funktion per CLI abschalten. Der Befehl, wörtlich aus dem PSIRT:

• config system encryption ibe
• set status disable
• end

Laut Fortinet schaltet das die IBE-Feature-Unterstützung aus. Mehr CLI gibt es an dieser Stelle nicht, und wir erfinden keine.

Die Alternative laut Fortinet, sinngemäß: den Zugang zum FortiMail-Management-Interface aus dem Internet abschalten oder den Zugang auf ein vertrauenswürdiges privates Netz begrenzen. Das ist eine Netzwerkfrage, keine Mail-Frage. Wer verantwortet die Firewall-Regel? Wer prüft, dass sie wirkt? Und wer merkt es, wenn jemand sie in drei Wochen „nur kurz“ wieder öffnet?

Jetzt das Entscheidende. Ein Workaround ist kein Fix. Er verkleinert die Fläche, er repariert nichts. Er sagt auch nichts darüber, ob vorher schon jemand da war. Genau das verschluckt der Satz „wir patchen, sobald es da ist“. Der kommende Patch beantwortet nicht, ob vor dem Patch schon etwas passiert ist. BOD 26-04 stellt genau diese Frage.

Organisatorisch hat IBE aus einen Preis. Wird die Funktion im Haus genutzt, fällt sie mit dem Abschalten weg, denn Fortinet schreibt, der Befehl schalte die Feature-Unterstützung aus. Also vor dem Befehl den Fachbereich fragen, ob jemand sie braucht. Wer die Antwort nicht kennt, hat ein zweites Inventarproblem. Die Entscheidung braucht einen Namen und eine Uhrzeit, nicht ein Meeting mit offenem Ende.

Die Entscheidung gehört nicht der IT allein. Der Fachbereich weiß, ob jemand auf die Funktion angewiesen ist. Die IT weiß, was der Schalter bedeutet. Beide Seiten brauchen dieselbe Seite Papier: Wer entscheidet, bis wann, und was passiert, wenn der Fachbereich nicht antwortet? Schweigen ist keine Freigabe und keine Ablehnung. Es ist ein offener Punkt.

Wenn der richtige Stand noch nicht da ist, zählt der Notfallschritt. Wie so ein Moment aussieht, wenn Hersteller und Betreibende nicht im Takt sind, zeigt unser Text zum Notfall-Release bei PaperCut. Dort ging es um den Notfallschritt. Hier geht es ebenfalls darum, nur dass der Schritt kein Update ist, sondern ein Schalter.

Exposure-Inventar: Was auf das Board gehört

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of a closed laptop beside a blank calendar page on a wooden desk, no logos, no readable text, no watermarks, no dates, 16:9

Ein Board ist keine Hoffnung mit Spalten. Es braucht je Gerät ein paar Antworten, schriftlich, mit Datum:

1. GUI im Internet erreichbar: ja oder nein? Nicht „sollte nicht“, sondern geprüft.
2. Versionsstand: Zweig und genaue Version.
3. IBE aus oder nicht? Wer hat es wann abgeschaltet, und wer hat es kontrolliert?
4. Management-Interface: nicht aus dem Internet erreichbar, beziehungsweise nur aus einem privaten Netz?
5. Fix-Kandidat: upcoming 8.0.2, 7.6.7, 7.4.9 oder der Wechsel von 7.2 auf Branch 7.4 oder höher.
6. Triage: Steht die IoC-Liste im Suchauftrag?
7. Wer schaut bis Sonntag? Name, Vertretung, Uhrzeit.

Das klingt nach Verwaltung. Es ist Verwaltung. Ohne sie ist es Glück. Warum das Inventar vor jedem Patch kommt, beschreibt unser Text zur digitalen Inventarisierung. Und wer wissen will, wie sich ein Bestandsbild überhaupt aktuell halten lässt, findet bei ITAM mit KI-Agenten Ansätze, um zu wissen, was im Bestand steht.

Eine Zeile ist besonders tückisch. Mail-Gateways stehen gern in Außenstellen, bei Dienstleistern, in Testumgebungen, die nach dem Projekt nie abgebaut wurden. Das Gerät, das keiner auf dem Plan hat, ist das Gerät, das im Internet hängt. Spoiler: Es ist meistens das, das keiner angefasst hat.

Und dann der Satz, der vom Board fliegen sollte: „Wir patchen, sobald es da ist.“ Er ist keine Planung. Er lässt die Exposition außen vor. Ersetzen Sie ihn durch fünf Angaben: GUI im Internet ja oder nein, IBE aus ja oder nein, Fix-Kandidat mit Zweig, Triage beauftragt ja oder nein, verantwortliche Person mit Namen. Fehlt eine der fünf, ist der Satz wieder Hoffnung.

Eine Änderung dieser Art prüft eine zweite Person. Nicht aus Misstrauen, sondern weil ein gesetzter Schalter, den niemand gegengelesen hat, auf dem Board genauso grün aussieht wie ein geprüfter. Die zweite Person bestätigt mit Datum und Namen. Fehlt sie, bleibt die Karte gelb.

Dann das Wochenende. Der Sonntag ist ein Kalendertag, kein Arbeitstag, und die Frage lautet nicht, wer es könnte, sondern wer es tut. Eine Person, eine Vertretung, eine Erreichbarkeit, die vorher getestet wurde. Wer die Telefonnummer erst am Sonntag sucht, hat den Termin bereits verpasst. Die Vertretung braucht denselben Wissensstand wie die Hauptperson, sonst vertritt sie nur den Namen.

Ein Board lebt nur, solange jemand hineinschaut. Legen Sie fest, wann und von wem es gelesen wird, und was passiert, wenn eine Karte länger als einen Tag unverändert bleibt. Stillstand ist auch ein Befund.

Forensic Triage: Suchliste statt Entstehungsgeschichte

Im Katalogeintrag steht forensicTriage auf Yes. BOD 26-04 erwartet die Prüfung auf Kompromittierung vor dem Patch. Fortinet liefert dafür im PSIRT Indikatoren. Das ist eine Suchliste. Keine Entstehungsgeschichte. Wir sagen nicht, wie die Dateien dorthin kamen, wir drucken keine Logzeilen, und wir erklären nichts nach. Wer sucht, braucht drei Dinge: welche Datei, welcher Hash, welche Adresse.

Dateien laut Fortinet-PSIRT, wie veröffentlicht, mit Status ADDED oder MODIFIED:

• [ADDED] /data/lib/liblog.so, MD5 64c90a00c7fda4d5c7973ed64c25783a, SHA256 8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84
• [MODIFIED] /bin/smit, MD5 5241738a3e9988404239e12243f6d35b, SHA256 77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a
• [ADDED] /data/bin/webconsole, MD5 ae0ea6502d3fa5f0664bceb73189eb54, SHA256 7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38
• [ADDED] /data/bin/mailservice, MD5 f90fa81a5f521d785f2b2f765e3ab897, SHA256 4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b
• [MODIFIED] /data/etc/httpd.conf, MD5 61af1c4bce1c2eebc8ff689ca5337791, SHA256 703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5
• [ADDED] /data/etc/ld.so.preload, MD5 8eb64f25d2a8e18e05aae058629473cf, SHA256 8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6
• [MODIFIED] /data/migadmin.tar.gz, MD5 49a7156a7d043cc8f9f680579db22f86, SHA256 d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3

Dazu zwei IP-Adressen, ebenfalls von Fortinet veröffentlicht: 79.141.169.187 und 45.129.0.192. Im PSIRT ist die erste Adresse mit einer Klammer am ersten Punkt notiert. Gemeint ist dieselbe Adresse.

Eine Einordnung gehört dazu. Das Katalogfeld knownRansomwareCampaignUse steht auf Unknown. Wir verbinden diese Adressen nicht mit einer Kampagne, nicht mit Ransomware, nicht mit einem Namen. Eine IP in einer Liste ist eine IP in einer Liste.

Was die Triage organisatorisch braucht: einen Suchauftrag, der die sieben Dateien und beide Adressen nennt. Eine Person, die ihn ausführt. Eine zweite, die das Ergebnis abnimmt. Einen Ablageort für den Befund, auch wenn er leer ist. Ein leerer Befund ist ein Ergebnis. Ein nicht gesuchter Befund ist keins.

Der leere Befund braucht denselben Rahmen wie ein voller: Wer hat gesucht, wann, mit welcher Liste, und wer hat gegengelesen? Ein Satz „nichts gefunden“ ohne diese Angaben lässt sich später nicht verteidigen. Er ist eine Behauptung, kein Beleg.

Und eine Grenze, die man laut aussprechen sollte: Kein Treffer heißt kein Treffer auf diesen Indikatoren. Nicht: nichts passiert. Die Liste stammt von Fortinet, mehr behaupten wir nicht.

Workaround und Triage sind getrennte Aufgaben. Getrennte Verantwortliche, getrennte Tickets. Wer beides bündelt, schließt das Ticket nach dem Workaround und hält die Sache für erledigt. Wer Geräte neu aufsetzt oder Konfigurationen ändert, klärt vorher, wer sichert, was für die Prüfung gebraucht wird. Erst sichern, dann aufräumen. Umgekehrt ist es ein Tatort ohne Tatort.

Drei Szenen aus dem Freitag

Drei erfundene Szenen. Sie könnten so oder ähnlich stattfinden. Keine ist ein Bericht über reale Betreibende.

Szene eins: Mittelstand, 19 Uhr

Die zuständige Person kennt zwei FortiMail-Geräte. Die Buchhaltung erwähnt beiläufig ein drittes, in der Niederlassung, vor Jahren eingerichtet, seitdem still. Das Board bekommt eine dritte Zeile. In der Spalte „GUI im Internet“ steht zunächst ein Fragezeichen. Das Fragezeichen ist ehrlich. Es ist besser als ein „nein“, das niemand geprüft hat. Bis zum Abend bekommt das Gerät einen Standort und eine Person, die morgen früh anruft.

Szene zwei: Konzern, Lagebesprechung

Im Ticketsystem steht der Status „wartet auf Hersteller“. Der Stabschef streicht ihn. Er schreibt drei Zeilen: Fix upcoming, Workaround offen, Triage offen. Aus einem grünen Haken werden drei gelbe Felder. Die Sicherheitsleitung sagt: „So sieht Ehrlichkeit aus.“ Der Rest des Raums schweigt, was in Lagebesprechungen als Zustimmung gilt. Eine Frage bleibt im Raum: Wer sichert, bevor jemand aufräumt? Niemand meldet sich, also bekommt die Frage einen Namen.

Szene drei: Dienstleister, Zweig 7.2

Ein Dienstleister betreibt für Kundschaft Geräte auf dem Zweig 7.2. Es gibt keinen Punkt-Fix, nur den Weg auf Branch 7.4 oder höher. Der Kundentermin heißt jetzt „Zweigwechsel“, nicht „Update“. Die Mail an die Kunden enthält drei Fragen: welcher Zweig, welcher Stand, IBE in Benutzung ja oder nein. Wer die dritte Frage nicht beantworten kann, bekommt sie am Sonntag noch einmal. Unter der Mail steht die Vertretung, mit Telefonnummer.

Checkliste bis Sonntag

1. Alle Geräte aufzählen, auch Testumgebung, Außenstelle und Geräte beim Dienstleister.
2. Je Gerät festhalten, ob die GUI aus dem Internet erreichbar ist.
3. Je Gerät Zweig und Version notieren.
4. Beim Fachbereich klären, ob die IBE-Funktion gebraucht wird. Danach IBE per CLI abschalten oder das Management-Interface aus dem Internet nehmen beziehungsweise auf ein privates Netz begrenzen.
5. Die Umsetzung von einer zweiten Person prüfen lassen und mit Datum eintragen.
6. Die sieben Dateien samt Hashes und die beiden Adressen in den Suchauftrag der Triage schreiben. Ergebnis dokumentieren, auch wenn es leer ist.
7. Fix-Kandidat je Gerät eintragen: upcoming 8.0.2, 7.6.7, 7.4.9 oder der Wechsel von 7.2 auf Branch 7.4 oder höher. Status „upcoming“ nicht als „erledigt“ führen.
8. Namen und Uhrzeit für Sonntag festlegen. Vertretung gleich dazu.

Acht Punkte. Kein Punkt davon ist Technik zum Nachstellen. Jeder Punkt ist eine Zuständigkeit. Wer eine davon nicht vergeben kann, hat die eigentliche Lücke gefunden.

Was folgt daraus? Jeder Punkt ist entweder belegt oder offen. „In Arbeit“ ist ein Zustand für Zwischenstände, nicht für eine Frist. Wer am Freitag mehrere offene Punkte hat, sollte wissen, welche bis Sonntag zu schließen sind und welche bewusst stehen bleiben. Beides gehört notiert, mit Begründung.

Was bedeutet ein offener Punkt am Sonntag? Das Katalogfeld dueDate ist dann verstrichen, und das Gerät steht in einem Zustand, den die Behörde als dringlich eingestuft hat. Für Betreibende hierzulande ist das keine Rechtsfolge, wohl aber eine Aussage über das eigene Risiko. Die Geschäftsführung sollte sie hören, bevor sie sie lesen muss. Ein offener Punkt heißt: Verantwortung benennen, Restrisiko beschreiben, nächsten Zeitpunkt festlegen. Nicht: abwarten.

Ein offener Triage-Punkt wiegt dabei schwerer als ein offener Fix-Punkt. Der Fix ist angekündigt, die Suche liegt bei Ihnen. Und ein Punkt, der am Sonntag niemandem gehört, gehört danach auch keinem. Deshalb steht neben jedem Punkt ein Name, nicht eine Abteilung.

IBE aus oder Hoffnung

Der KEV-Eintrag nennt Sonntag, 4. Oktober 2026. Das Fortinet-PSIRT nennt Fixes, die noch nicht da sind. Dazwischen liegt ein Freitag, an dem sich entscheidet, ob eine Frist ein Plan wird oder ein Datum, das man verstreichen sieht.

Der Workaround ist nicht der Fix. Upcoming ist nicht installiert. Der Patch, wenn er kommt, sagt nichts über die Zeit davor. Dafür gibt es die Suchliste und eine Person, die sie abarbeitet. Das ist die ganze Rechnung, und sie geht nur auf, wenn das Exposure-Inventar steht.

Am Ende zählt nicht, wie gut das Board aussieht, sondern ob am Sonntag jemand weiß, was zu tun ist.

Bei digital-magazin.de bleibt es bei einem Satz für alle, die FortiMail im Bestand haben: IBE aus oder Hoffnung. Hoffnung ist kein Change-Typ, und im KEV-Katalog steht sie nicht als Mitigation.