Ivanti EPMM ablösen: Gründe, Kriterien, Migrationspfad

Eine häufige Kundenfrage lautet: „Sollen wir Ivanti EPMM ablösen?“ Wenn du EPMM selbst betreibst, lautet meine Antwort: Prüf die Ablösung ernsthaft. Angreifer haben Lücken in EPMM 2023, 2025 und 2026 ausgenutzt, teils bevor es einen Patch gab. Behörden in Norwegen und den Niederlanden haben Einbrüche über EPMM bestätigt, und im September 2026 hat Ivanti EPMM aus einem laufenden BSI-Zertifizierungsverfahren zurückgezogen.

Ob BlackBerry UEM dann das richtige Ziel ist, hängt am Betriebsmodell und daran, ob du Patchen, Kompromittierungsprüfung und Wiederaufbau dauerhaft leisten kannst. Beim Wechsel baust du Richtlinien, Profile und Container-Apps neu auf und nimmst die Geräte neu auf; organisationseigene iPhones ab iOS 26 ziehen dabei ohne Löschen um. Das gilt für EPMM (früher MobileIron Core) und, mit Einschränkungen, für Neurons for MDM (früher MobileIron Cloud), Stand 13. Oktober 2026.

Warum Kunden EPMM ablösen wollen

Sieben Gründe lassen sich belegen. Jeder zählt für dich aber nur, wenn er auf dein System zutrifft.

1. Ausgenutzte Lücken, teils vor dem Patch. Die US-Behörde CISA führt Lücken in EPMM und Standalone Sentry aus den Jahren 2023, 2025 und 2026 als ausgenutzt [1]. CVE-2023-35078 wurde mindestens ab April 2023 als Zero-Day ausgenutzt, also bevor es eine Abhilfe gab [2]. Zu CVE-2026-1281 und CVE-2026-1340 deckte das niederländische NCSC bei forensischen Untersuchungen im Februar 2026 vergleichbare erfolgreiche Angriffe auf, die schon im August 2025 stattgefunden hatten [3]. Die französische Behörde ANSSI zählt CVE-2025-4427 und CVE-2025-4428 zu den Lücken, die in den von ihr bearbeiteten Vorfällen des Jahres 2025 am häufigsten ausgenutzt wurden [4]. In solchen Fällen schützt auch schnelles Patchen allein nicht.
2. Bestätigte Einbrüche mit Folgen. Die norwegische Regierung bestätigte 2023 Schwachstellen in EPMM als Einstieg in den Angriff auf die gemeinsame IT-Plattform von zwölf Ministerien [5]. Die Angreifer tunnelten Verkehr durch Sentry zu einem Exchange-Server, der aus dem Internet nicht erreichbar war [2]. Am Ende schaltete Norwegen die Mail-Lösung dieser Ministerien ab und stellte eine neue bereit [5]. In den Niederlanden sahen Unbefugte 2026 über EPMM Namen, dienstliche E-Mail-Adressen und Telefonnummern von Beschäftigten der Datenschutzbehörde ein [6], bei der Justizvollzugsbehörde DJI auch Standortdaten [7].
3. Aufräumen kostet mehr als ein Patch. Die EPMM-Datenbank kann je nach Einrichtung Kennwort-Hashes, Zuordnungen zu AD-Gruppen, Zugriffs-Tokens für Office 365, Gerätekennungen und Standortdaten enthalten [3]. Das BSI rät deshalb nach den Januar-Lücken 2026, von einer Kompromittierung auszugehen, selbst wenn du schon am 29. Januar gepatcht hast. Ist ein System kompromittiert, empfiehlt es keine eigene Bereinigung, sondern die Wiederherstellung aus einem sicheren Backup oder eine Neuinstallation mit Datenmigration und den Austausch verbundener Zugangsdaten [8]. Die französische CERT-FR nennt dazu die Kennwörter der LDAP- und Kerberos-Dienstkonten und die öffentlichen EPMM-Zertifikate [9]. Gründlich suchen musst du auch deshalb, weil die Angreifer 2023 gezielt Einträge aus den Logs der Appliance gelöscht haben [2].
4. Pflichten machen daraus eine Leitungsfrage. Seit dem 6. Dezember 2025 gilt in Deutschland das NIS-2-Umsetzungsgesetz [10]. Fällt dein Unternehmen darunter [11], verlangt § 30 BSIG Risikomanagement einschließlich des Umgangs mit Schwachstellen, und die Geschäftsleitung muss die Umsetzung überwachen [12][13]. Unabhängig davon verlangt die DSGVO risikogerechte Schutzmaßnahmen. Eine bekannt gewordene Verletzung personenbezogener Daten meldet der Verantwortliche unverzüglich und möglichst binnen 72 Stunden der zuständigen Aufsichtsbehörde, außer wenn voraussichtlich kein Risiko für die Rechte und Freiheiten der Betroffenen entsteht [14]. Nach IT-Grundschutz muss das gewählte MDM die Anforderungen erfüllen können, die du in deiner MDM-Strategie festgelegt hast [15]. Diese Pflichten gelten für jedes MDM, auch für BlackBerry UEM. Zum Ablösegrund werden sie, wenn du sie mit deinem EPMM-Betrieb dauerhaft nicht erfüllen kannst.
5. Kein BSI-Verfahren mehr für EPMM. In seiner Erklärung vom 15. September 2026 hat Ivanti den Rückzug von EPMM aus dem laufenden Zertifizierungsverfahren BSI-DSZ-CC-1241 bekanntgegeben [16]. Wer für seine Beschaffung ein BSI-Zertifikat braucht, kann bei EPMM nicht mehr auf dieses Verfahren setzen. Wie du Zertifikate beider Hersteller prüfst, steht unten bei den Kriterien.
6. Ivantis Richtung ist die Cloud. Ivanti richtet sich seit Mai 2025 auf SaaS aus und fördert den Umzug von On-Premises-Produkten zu Ivanti Neurons [17]. Einzelne Bausteine fallen weg: Email+ mit Android AppConnect ist abgekündigt [18], Web@Work für Android 2.6.1 und Secure Apps Manager 9.4.1.0 sind außerhalb des Supports [19], das Windows-Tunnel-VPN funktioniert ab Sentry 10.4 nicht mehr [20], Integrated Sentry ist ab EPMM 12.7 abgekündigt [21], und die Windows-Verwaltung verlagert Ivanti zu Endpoint Manager und Neurons for MDM [22]. Steckt einer dieser Bausteine in deinem Bestand, baust du an dieser Stelle sowieso um.
7. Der Mailweg steht ohnehin zur Planung an. Exchange Server 2016 und 2019 sind seit dem 14. Oktober 2025 ohne Support [23]. Wechselst du zu Exchange Server SE oder Microsoft 365, ist das der Moment, auch den mobilen Mailweg neu zu planen. Nutzt Sentry für ActiveSync OAuth, bleibt er auf ActiveSync beschränkt, und für AppTunnel brauchst du einen weiteren Sentry [24].

Drei verbreitete Argumente halten dagegen nicht. EPMM wird nicht eingestellt: Zwischen August 2025 und August 2026 erschienen die Versionen 12.6 bis 12.10 [25], und Ivanti erklärt, weiter in EPMM zu investieren [16]. EPMM unterstützt Apples Declarative Device Management seit Version 12.1 und neue iOS-26-Steuerungen seit 12.7 [26]. Und BlackBerry UEM ist nicht frei von Lücken: Am 28. Juli 2026 veröffentlichte BlackBerry Abhilfe für CVE-2026-18084 (hoch) und CVE-2026-18085 (mittel) in der Verwaltungskonsole. Betroffen sind UEM 12.23.0 QF8 und früher sowie 12.22.1 QF7 und früher; die Abhilfe lautet 12.23.0 QF10 oder 12.22.1 QF8 [27]. Beide setzen voraus, dass das Opfer eine präparierte Webseite oder einen Link öffnet, und keine steht im KEV-Katalog [27][1]. Für Neurons for MDM gelten die EPMM-Lücken nicht [28][29].

Welches Ivanti-Produkt betreibst du?

Ivanti hat die Übernahme von MobileIron im Dezember 2020 abgeschlossen [30] und die Produkte umbenannt [31]. In Advisories, Verträgen und Vergleichslisten tauchen beide Namen auf. Ordne deshalb zuerst zu, was bei dir läuft:

Drei Namen gehören nicht in diese Tabelle: Ivanti Endpoint Manager (EPM), die Cloud Services Appliance (CSA) und Connect Secure. Trotz ähnlicher Namen sind das andere Produkte mit eigenen Advisories [29][37]. Führt eine Liste EPM- oder CSA-Lücken unter „Ivanti UEM“, beantwortet sie deine Frage nicht. Auch die US-Notfallanweisung ED 24-01 betraf Connect Secure und Policy Secure, nicht EPMM [38].

In unserem Beispiel uemfaq.de läuft EPMM als Appliance epmm.uemfaq.de, davor steht sentry.uemfaq.de für den ActiveSync-Zugang zu Exchange.

Wie ernst ist die Schwachstellenlage für dein System?

Geräte müssen EPMM aus dem Internet erreichen, für iOS-MDM über HTTPS 443 [39]. Mobile@Work nutzt für Registrierung und Check-in je nach Einrichtung zusätzlich TCP 9997; schließen lässt er sich bei einer Neuinstallation, wenn Mutual Authentication vor der ersten Geräteregistrierung aktiv ist und alle iOS-Geräte Mobile@Work ab Version 9.8 nutzen [40]. Zugleich verteilt der Server Profile und Konfigurationen an alle registrierten Geräte. Eine ausnutzbare Lücke betrifft deshalb die Verwaltung aller Geräte.

Die Tabelle zeigt die Lücken in EPMM und Standalone Sentry seit 2023, die die US-Behörde CISA in ihrem Katalog ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) führt [1]. Lies sie zeilenweise: Lief bei dir zu diesem Datum eine betroffene Version? Die Spalte „Behoben in“ nennt die Abhilfe der jeweiligen Meldung, nicht den Stand, den du heute brauchst.

Für die Januar-Lücken 2026 gab es zunächst RPM-Hotfixes; die in der Tabelle genannten Release-Fixes folgten im Mai [29][25]. Daneben hat Ivanti weitere Lücken behoben, für die bei Veröffentlichung keine Ausnutzung bekannt war. Den aktuellen Stand setzen zwei Advisories vom 8. September 2026: EPMM 12.10.0.0, 12.9.0.2 oder 12.8.0.4 (CVE-2026-18851) [47] und Sentry R10.8.2, R10.7.3 oder R10.6.4 (CVE-2026-83527) [48]. Ältere Versionen derselben Zweige sind von diesen Lücken betroffen.

Den Cloud-Dienst Neurons for MDM schließt Ivanti bei den EPMM-Lücken von 2025 und 2026 ausdrücklich aus [28][29]. Für den Dienst selbst gibt Ivanti eigene Meldungen ohne CVE-Nummer heraus, etwa im Oktober 2025 zu einer Umgehung der Mehrfaktor-Anmeldung, und aktualisiert die Instanzen selbst [49]. Betreibst du zu N-MDM einen eigenen Standalone Sentry, gehört er trotzdem in deine Prüfung: Das Sentry-Advisory vom September 2026 nennt Sentry unter EPMM und unter N-MDM [48].

Drei Fragen an dein System

1. Welche Version lief wann? Leg deine Upgrade-Historie neben die Daten der Tabelle. Entscheidend ist nicht die heutige Version, sondern die Zeit, in der eine ausgenutzte Lücke bei dir offen war.
2. Was ist aus dem Internet erreichbar? Geräte brauchen den Server. Admin-Portal und System Manager brauchen keinen allgemein offenen Internetzugang, und API-Zugriffe beschränkst du auf die Integrationen, die sie tatsächlich brauchen [50]. EPMM kann diese Zugänge über Portal-ACLs getrennt beschränken, auch die API-Verbindung [51]. Diese ACL nannte Ivanti auch als Minderung für die API-Lücken von 2025, mit dem Hinweis, dass sie Integrationen wie die Microsoft-Compliance-Anbindung blockieren kann [28]. Die Verwaltungsschnittstelle von Sentry auf Port 8443 gehört nicht ins Internet [46].
3. Hast du auf Kompromittierung geprüft? Ein Patch schließt die Lücke, macht aber einen Einbruch davor nicht rückgängig. Das niederländische NCSC rät nach den Januar-Lücken 2026 zu einem Vorgehen nach Assume Breach, also so zu prüfen, als wäre der Angreifer schon drin: Schlüssel und Geheimnisse wechseln, Logs außerhalb der Appliance sichern [52]. Ivanti hat mit dem NCSC ein Erkennungspaket herausgegeben und am 12. Februar 2026 verbessert. Findet es nichts, ist das System damit ausdrücklich nicht als sauber bestätigt [29]. Das BSI dokumentiert Angriffe auch gegen deutsche Organisationen, hat Hinweise auf Ausnutzung schon seit Sommer 2025 und fordert den erneuten Lauf des verbesserten Scanners [53]. Prüf dabei auch die Systeme, die über Sentry erreichbar sind [54].

Eine CVE-Zählung über Produktfamilien hinweg sagt nichts darüber, ob dein System betroffen, erreichbar und rechtzeitig gepatcht war. Den KEV-Katalog nutzt du als Prüfpunkt; die Direktiven der CISA binden US-Bundesbehörden, nicht dich [55]. Dieselben Fragen stellst du jedem Nachfolger, auch BlackBerry UEM: Was muss erreichbar sein, wie schnell spielst du Updates ein, woran erkennst du einen Einbruch?

Supportstatus und Ivantis eigener Weg

Das Supportrisiko liegt bei der einzelnen Version: MobileIron Core 11.2 war seit März 2022 ohne Support, und für CVE-2023-35082 gab es für 11.2 und älter keine eigene Abhilfe mehr [43]. Prüf deshalb, bis wann deine Version unterstützt wird. Ivanti führt die Daten in seinem Kundenportal [56]. Bei BlackBerry UEM stellst du dieselbe Frage, unterscheidest aber zwei Supportarten: Der Engineering-Support liefert Fixes und Sicherheitspatches, der technische Support ist davon getrennt. UEM 12.21 bekommt seit dem 12. Mai 2026 keine Patches mehr, 12.22 ab dem 14. November 2026 [57].

Belastet dich vor allem der Betrieb der Appliance, hat Ivanti einen eigenen Weg: das Low User Impact Migration Portal von EPMM zu Neurons for MDM [58]. Es übernimmt aktive iOS- und Android-Geräte samt Benutzer und Labels, und Mobile@Work arbeitet danach mit N-MDM weiter [59]. Nutzer merken den Umzug an zwei Stellen: Lokale Benutzer vergeben ein neues Kennwort, und unter Android Enterprise synchronisiert Email+ neu und verliert lokale Entwürfe und den Postausgang [58][59]. Die Gerätemigration lässt sich nicht zurücknehmen. Bis in N-MDM eine eigene Richtlinie greift, kann die alte EPMM-Richtlinie auf dem Gerät weiterwirken [59]. Die Kompatibilitätsliste der Portalversion 20.0 vom März 2026 führt EPMM 12.5.0.0 als unterstützt und 12.4 bis 12.6 als kompatibel [60].

Wer eine EU-Cloud verlangt, findet bei Ivanti seit April 2026 Neurons for MDM Sovereign Edition – EU, betrieben von sector27 mit Rechenzentrum in Deutschland [61][62]. Das ist ein eigenes Angebot, nicht die Eigenschaft jedes N-MDM-Tenants.

Nach welchen Kriterien entscheidest du?

Ich würde die Entscheidung an wenigen Kriterien festmachen und beiden Herstellern dieselbe Frage stellen:

Für beide Seiten gilt bei der Microsoft-Anbindung: Die Benutzer brauchen Intune-Lizenzen, auch wenn ein Partner die Geräte verwaltet [67]. Wie Container und Betriebssystemverwaltung auf dem iPhone zusammenspielen, zeigt Ein iPhone, vier Ebenen.

Für das Kriterium Souveränität brauchst du ein gemeinsames Raster, sonst versteht jeder etwas anderes darunter. Das Cloud Sovereignty Framework der EU-Kommission (Version 1.2.1, Oktober 2025) nennt acht Ziele: strategische Souveränität (SOV-1), rechtliche Souveränität und Gerichtsbarkeit (SOV-2), Daten und KI (SOV-3), Betrieb (SOV-4), Lieferkette (SOV-5), Technologie (SOV-6), Sicherheit und Compliance (SOV-7) sowie ökologische Nachhaltigkeit (SOV-8) [70]. Frag beide Hersteller je Ziel nach dem Nachweis für deinen konkreten Aufbau. Eine Selbsteinstufung des Herstellers ist kein solcher Nachweis.

Bei Zertifikaten verlangst du ebenfalls den Nachweis für deinen Aufbau. Ivanti hat EPMM aus dem Verfahren BSI-DSZ-CC-1241 zurückgezogen, begründet das mit seinem Schwerpunkt auf Cloud-Lösungen und will EPMM weiter pflegen [16]. Für BlackBerry UEM führt das BSI das Zertifikat BSI-DSZ-CC-1235-2025; es gilt für den UEM Server 12.21.1, nicht für jede spätere Version [71]. Lass dir die Zertifikatsnummer geben und prüf im Register des BSI, ob Produkt und Version zu deinem geplanten Aufbau passen. Dort stehen je Zertifikat die Nummer, das Produkt mit Version und der Antragsteller [72]. Was das UEM-Zertifikat abdeckt und was nicht, steht in Ist BlackBerry UEM BSI-zertifiziert?.

Wann BlackBerry UEM nicht die passende Ablösung ist

• Dein Problem ist nur die Appliance. Erfüllt Neurons for MDM deine Anforderungen und stört dich vor allem der Eigenbetrieb von EPMM, ist Ivantis Migration Portal der kürzere Weg. Die Geräte bleiben dabei in Betrieb, statt neu aufgenommen zu werden. Brauchst du eine EU-Cloud, prüf dort die Sovereign Edition.
• Du willst SaaS im Microsoft-Umfeld und keinen eigenen Container. Hast du die Intune-Lizenzen ohnehin, die du auch für die Compliance-Anbindung eines Partners brauchst [67], und genügt dir die Verwaltung über das Betriebssystem, ist Intune der naheliegende Kandidat, den du zuerst prüfen solltest.
• Du brauchst eine Umgebung ganz ohne Herstellerverbindung. BlackBerry UEM läuft auch als Dark Site ohne Verbindung zur BlackBerry Infrastructure. Dann fehlen unter anderem BlackBerry Secure Connect Plus, Secure Gateway und BlackBerry Proxy, iOS-Geräte laufen nur mit „MDM controls“ und ohne iOS-Compliance-Profile, Android-Geräte melden sich per Polling statt Push, und iOS braucht weiterhin Apples Push-Dienst APNs [66]. Prüf diese Liste gegen deine Anforderungen, bevor du dich festlegst.
• Dein Schwerpunkt sind Windows- und Mac-Clients. Dann zählen andere Kriterien als die hier besprochenen.
• Dein EPMM ist aktuell, abgeschottet und geprüft. Läuft ein aktueller Zweig, sind Portale und API per ACL begrenzt, ist die Kompromittierungsprüfung dokumentiert und drängt kein anderes Kriterium, ist Abwarten eine vertretbare Entscheidung. Leg ein Datum fest, an dem du sie erneut prüfst.

Wie ein Wechsel zu BlackBerry UEM praktisch aussieht

Die Migrationsfunktion in UEM übernimmt Benutzer, Geräte und Gruppen aus einem anderen BlackBerry-UEM-Server, nicht aus EPMM [65]. Richtlinien, Profile und App-Zuweisungen baust du deshalb neu auf. Haben sich in EPMM über die Jahre Ausnahmen und Sonderprofile angesammelt, ist das die Gelegenheit, nur mitzunehmen, was du begründen kannst.

Die erste Zeile gilt für organisationseigene Geräte, die über Automated Device Enrollment (ADE) aufgenommen wurden. In der ADE-Konfiguration von UEM steht „Device configuration“ dafür auf „Wait until device is configured“ [65]. Sollen verwaltete Apps erhalten bleiben, darf das alte MDM beim Abmelden keine Befehle zum Löschen der Apps senden, und UEM muss die Apps zuweisen, bevor die Einrichtung abgeschlossen ist [73]. Für Kauf-Apps aus dem Volume Purchase Program (VPP) entfernst du den Content-Token aus dem bisherigen MDM und lädst einen neuen Token für dieselbe Organisationseinheit in UEM hoch [73]. VPP-Apps mit Benutzerlizenz ziehen nur mit verwalteten Apple-Accounts mit; sonst nimmst du für die Migration Gerätelizenzen [65]. Geteilte iPads und Geräte mit „Return to Service“ samt App-Erhalt sind ausgeschlossen, und per Apple Configurator hinzugefügte Geräte müssen ihre 30-tägige vorläufige Frist hinter sich haben [73].

Bei den übrigen iPhones verschwinden mit dem alten MDM-Profil auch dessen Konfigurationen und verwaltete Apps [74]. In UEM aktivierst du sie danach etwa mit „MDM controls“ oder „User privacy“. Vollständig verwaltete Android-Geräte nimmst du nach dem Werksreset als „Work space only“ oder „Work and personal – full control“ auf, private Geräte mit Arbeitsprofil als „Work and personal – user privacy“ [75].

Die App-Konfiguration legst du unter iOS als Schlüssel und Werte oder als XML-Vorlage an, unter Android über die verwalteten Einstellungen der App [69]. Eigene AppConnect-Apps brauchen das Dynamics SDK, das ist Entwicklungsarbeit; App-Wrapping gibt es nur als separates Partnerangebot [69][68].

Für die Zertifikate bindest du die Zertifizierungsstelle per SCEP, Entrust oder PKI Connector an, legst ein CA-Zertifikatsprofil für das Vertrauen und ein SCEP- oder User-credential-Profil für die Clientzertifikate an und verknüpfst sie mit den WLAN-, VPN- und Mailprofilen [79]. Fehlt eine Verknüpfung, scheitert genau die Verbindung, die daran hängt. Für iOS braucht das neue MDM außerdem ein eigenes APNs-Zertifikat [82].

Beim Mailweg ersetzt du Sentry auf eine von zwei Arten. BlackBerry Work spricht direkt mit Exchange, lokal etwa per KCD, mit Exchange Online über Modern Authentication; Benachrichtigungen kommen über BEMS [80][83]. Native Mail sicherst du mit Gatekeeping ab: UEM pflegt die erlaubten ActiveSync-Geräte in Exchange [81]. Gatekeeping ist kein Gateway. Den Netzweg zum Mailserver brauchst du zusätzlich, für native iOS-Mail etwa über BlackBerry Secure Gateway [81][63]. Verlangt deine Conditional-Access-Regel ein konformes Gerät, braucht native iOS-Mail außerdem ein Single-Sign-on-Erweiterungsprofil mit Microsoft Authenticator, damit die Anmeldung die Geräte-ID an Entra mitschickt [84].

Reihenfolge im Parallelbetrieb

In unserem Beispiel uemfaq.de laufen epmm.uemfaq.de und sentry.uemfaq.de weiter, während uem01.uemfaq.de dazukommt. Für den Umzug nehmen wir diese Reihenfolge:

1. Bestand aufnehmen. Je Plattform: Aktivierungsart, ADE ja oder nein, iOS-Version, AppConnect-Apps, Zertifikatsprofile und Mailweg. Daraus folgt, welche Zeile der Gerätetabelle für welches Gerät gilt.
2. UEM aufbauen. Verzeichnisanbindung, PKI, IT-Policy, Profile, Apps und Mailweg, jeweils neu und begründet.
3. Compliance-Umschaltung planen. Intune akzeptiert je Plattform nur einen Compliance-Partner, auch wenn mehrere in Entra eingetragen sind [67]. Solange iPhones teils in EPMM und teils in UEM stecken, liefert für iOS also nur eines der beiden Systeme den Compliance-Status. Leg je Plattform einen Umschaltzeitpunkt fest und klär vorher, wie deine Conditional-Access-Regel die Geräte behandelt, die noch im anderen System sind.
4. Pilot. Aus jeder Zeile der Gerätetabelle einige Geräte, darunter mindestens ein ADE-iPhone mit iOS 26 für den Apple-Weg. Apple empfiehlt, Migration, Betriebsabläufe und Nutzererlebnis vorher zu testen, und erlaubt eine gestaffelte Migration [82]. Für die Compliance-Anbindung braucht UEM passende Benutzer im Verzeichnis und auf dem Gerät die Registrierung über UEM Client und Microsoft Authenticator [65]. Prüf dann mit einem konformen und einem absichtlich nicht konformen Gerät, ob die echte Conditional-Access-Regel greift. Eine Regel mit der Aktion „Monitor and log“ meldet keinen Verstoß an Intune [65].
5. Wellen. Gruppenweise umziehen, mit vorbereiteter Anleitung und festen Hilfezeiten. Die ersten Gruppen hältst du klein und begleitest sie; daran siehst du, wie viel Unterstützung die folgenden Wellen brauchen.
6. Abschalten. EPMM und Sentry erst, wenn das letzte Gerät umgezogen ist und keine Mail mehr über Sentry läuft. Danach entfernst du die Ivanti-Anbindung aus Intune.

Was du als Nächstes entscheidest

Die Kompromittierungsprüfung für EPMM und Sentry brauchst du unabhängig davon, ob du ablöst. Steht sie noch aus, kommt sie vor allem anderen.

1. Produkt, Version und Exposition feststellen, mit der Namenstabelle, der CVE-Tabelle und einem Blick auf die Portal-ACLs.
2. Gründe gegen dein System legen: Welcher der sieben Gründe trifft bei dir zu, welcher nicht?
3. Kriterien gewichten, gemeinsam mit Security, IT-Leitung und Einkauf, und je Kriterium den Nachweis beim Hersteller anfordern.
4. Gegenfälle prüfen: Spricht einer für Abwarten, für Ivantis eigenen Weg oder für ein anderes Ziel?
5. Pilotumfang festlegen: welche Gerätetypen, wann die Compliance je Plattform umschaltet und welcher Mailweg Sentry ersetzt.

Liegen Security, IT-Leitung und Einkauf bei Gründen, Kriterien oder Reihenfolge auseinander, klär das in einem gemeinsamen Termin, bevor das erste Gerät umzieht.

Stand: 13. Oktober 2026. CVE- und KEV-Angaben nach den Ivanti-Advisories und dem KEV-Katalog vom 13. Oktober 2026; BlackBerry UEM 12.24; Apple-Migration ab iOS/iPadOS 26.

Stand und Quellen

Geprüft am 13. Oktober 2026 · BlackBerry UEM 12.24 · Ivanti EPMM 11.x bis 12.10 · Ivanti Standalone Sentry bis R10.8.2 · Apple iOS/iPadOS 26

1. CISA: Known Exploited Vulnerabilities Catalog, Katalog 2026.10.13; je CVE: Date Added.
2. CISA und NCSC-NO: Threat Actors Exploiting Ivanti EPMM Vulnerabilities (AA23-213A), 01.08.2023; S. 1–3: Summary; APT Actor Activity.
3. NCSC-NL: Casus kwetsbaarheden Ivanti EPMM systemen, 27.02.2026; In het kort; Zeitlinie; Exfiltratie gegevens MIFS-database.
4. ANSSI: Cyber Threat Overview 2025, Berichtsjahr 2025, Ausgabe 2026; S. 46: Vulnerabilities most exploited in the incidents processed by ANSSI in 2025.
5. Norwegische Regierung: Stenger e-postløsning etter dataangrep, Pressemitteilung 12.08.2023; Einleitung; Absatz zur Untersuchung durch DSS.
6. Niederländische Regierung: Incident bij de Autoriteit Persoonsgegevens en de Raad voor de rechtspraak (26643-1462), Schreiben 06.02.2026; Haupttext.
7. Niederländische Regierung: Ontwikkelingen over kwetsbaarheid in Ivanti EPMM (Kamerstuk 26643, nr. 1492), Schreiben 27.02.2026; Absatz zu DJI.
8. BSI-IT-Sicherheitshinweis BITS-H 2026-221601-1332: Ivanti EPMM, Version 1.3 (PDF), Version 1.3, 13.02.2026; S. 4: Kompromittierung prüfen; S. 6: Wiederherstellung nach einer Kompromittierung.
9. CERT-FR: Multiples vulnérabilités dans Ivanti Endpoint Manager Mobile (CERTFR-2026-ALE-001), Stand 09.02.2026; Recherche de compromission; Remédiation.
10. BSI: Allgemeine FAQ zu NIS-2, Stand 13.10.2026; Gesetzgebungsverfahren und Zuständigkeit, Frage 3.
11. BSIG § 28: Besonders wichtige Einrichtungen und wichtige Einrichtungen, BSIG 2025; § 28.
12. BSIG § 30: Risikomanagementmaßnahmen, BSIG 2025; § 30 Abs. 1 und Abs. 2 Nr. 5.
13. BSIG § 38: Pflichten der Geschäftsleitungen, BSIG 2025; § 38 Abs. 1.
14. Datenschutz-Grundverordnung (EU) 2016/679, Amtsblattfassung; Art. 32 Abs. 1; Art. 33 Abs. 1.
15. BSI IT-Grundschutz: SYS.3.2.2 Mobile Device Management (MDM), IT-Grundschutz-Kompendium, Edition 2023; SYS.3.2.2.A1 und A3.
16. Ivanti: Advancing Ivanti’s Commitment to Modern, Cloud-Connected Cybersecurity in Europe, 15.09.2026; Einleitung; FAQ zu EPMM-Kunden und zum Rückzug.
17. Ivanti: Delivering on Our Commitment to Empower Customers with Future-Proof Solutions, 07.05.2025; SaaS-Transformation.
18. Ivanti: About Ivanti Email+ for Android, Email+ für Android 5.0.0–5.5.0; Einleitung.
19. Ivanti: Docs@Work für Android, Support and compatibility, Docs@Work für Android bis 2.32.0; App-Matrix: Web@Work 2.6.1; Secure Apps Manager 9.4.1.0.
20. Ivanti: Standalone Sentry, New features summary, Sentry bis 10.8.2; Sentry 10.4.0: Windows.
21. Ivanti: EPMM, Deprecated features, EPMM 12.0–12.10; EPMM 12.7.0.0: Integrated Sentry.
22. Ivanti: EPMM, Support and compatibility, EPMM 12.10.0.0; Windows: Hinweis zur Verlagerung.
23. Microsoft Learn: Exchange Server 2019 and 2016 end of support roadmap, Supportende 14.10.2025; Einleitung; What are my options?.
24. Ivanti: OAuth for Sentry on Ivanti EPMM, Sentry 9.14.0–10.8.2; Hinweise zu nativer iOS-Mail und Email+ mit OAuth.
25. Ivanti EPMM 12.x Release Notes: Revision history, bis EPMM 12.10.0.0; Revision history, Einträge 12.6.0.0 bis 12.10.0.0.
26. Ivanti: EPMM, What’s New, EPMM 12.0–12.10; 12.1.0.0: Declarative Device Management; 12.7.0.0: iOS 26.
27. BlackBerry BSRT-2026-001: Vulnerabilities in BlackBerry UEM Management Console, 28.07.2026; Tabelle je CVE; Resolution.
28. Ivanti Security Advisory: EPMM CVE-2025-4427 und CVE-2025-4428, 13.05.2025; Affected Versions; Mitigation or Workaround.
29. Ivanti Security Advisory: EPMM CVE-2026-1281 und CVE-2026-1340, Advisory 29.01.2026, Abhilfe aktualisiert 07.05.2026; Affected Versions; Solution; Exploitation Detection RPM; FAQ.
30. Ivanti: Abschluss der Übernahme von MobileIron, Pressemitteilung 01.12.2020; erster Absatz.
31. Ivanti KB 000076083: Branding Updates to MobileIron products, Stand Oktober 2026; Former Name / Updated Name.
32. Ivanti: About AppConnect for Android, AppConnect für Android 9.3–9.4.1; Hinweis zu Connected Cloud.
33. Ivanti Neurons for MDM: Connector, Neurons for MDM R125; Hosting options.
34. Ivanti Standalone Sentry Guide: Overview, Sentry 9.14 bis 10.8.2; Sentry flavors; ActiveSync; AppTunnel.
35. Ivanti AppConnect: Android apps, AppConnect für Neurons for MDM 80–86; Ivanti-provided apps; Types of AppConnect apps.
36. Ivanti Tunnel für iOS: Deployment use cases, Tunnel für iOS 4.14–4.15; Deployment use cases.
37. Ivanti Security Advisory: Cloud Services Appliance CVE-2024-8190, Advisory September 2024; Affected Products.
38. CISA ED 24-01: Ivanti Connect Secure und Policy Secure, Januar/Februar 2024; Titel und Scope.
39. Ivanti EPMM On-Premise Installation: External and Internet Rules, EPMM 12.0–12.10; Inbound-Regeln EPMM und Standalone Sentry.
40. Ivanti EPMM System Manager: Port Settings, EPMM 12.0–12.10; Sync TLS Port 9997.
41. Ivanti: CVE-2023-35078, Remote unauthenticated API access, Juli 2023; Summary; Resolution.
42. Ivanti: CVE-2023-35081, Arbitrary File Write, 28.07.2023; Affected Versions; Resolution.
43. Ivanti: CVE-2023-35082, Remote unauthenticated API access in MobileIron Core, 02.08.2023, aktualisiert 21.08.2023; aktualisierte Versionsangaben; Supportende 11.2.
44. Ivanti: CVE-2023-38035, API Authentication Bypass on Sentry Administrator Interface, 21.08.2023; Affected Versions; Port 8443; RPM.
45. Ivanti Security Advisory: EPMM Mai 2026, mehrere CVEs, 07.05.2026; Vulnerability Details; Affected Versions; FAQ.
46. Ivanti Security Advisory: Sentry CVE-2026-10520 und CVE-2026-10523, 09.06.2026; Affected Versions; FAQ.
47. Ivanti Security Advisory: EPMM CVE-2026-18851, 08.09.2026; Affected Versions; Solution.
48. Ivanti Security Advisory: Sentry CVE-2026-83527, 08.09.2026; Summary; Affected Versions.
49. Ivanti Security Advisory: Neurons for MDM, Oktober 2025, 14.10.2025, Abhilfe R119; Vulnerability Details; Solution; FAQ.
50. Ivanti EPMM On-Premise Installation: Internal Corporate Network Rules, EPMM 12.0–12.10; Verwaltungszugang.
51. Ivanti EPMM System Manager: Access Control Lists, Portal ACLs, EPMM 12.0–12.10; Portal ACLs window.
52. NCSC-NL: Meldung zu Ivanti Endpoint Manager Mobile, Stand 12.02.2026; Updates 04.–12.02.2026.
53. BSI-Cybersicherheitswarnung 2026-221601-1032: Ivanti EPMM, Version 1.3, 13.02.2026; Update 1 bis 3.
54. Ivanti: Analysis Guidance EPMM CVE-2026-1281 und CVE-2026-1340, 2026; Off-box logging; Impact; Sentry.
55. CISA: Cybersecurity Directives, Stand 13.10.2026; Geltungsbereich der Direktiven.
56. Ivanti: End of Support Dates and Announcements, Kundenportal, Anmeldung erforderlich; Supportenddaten je Version.
57. BlackBerry: Software lifecycle – BlackBerry UEM, Stand Oktober 2026; Zeilen 12.21 und 12.22; Begriffe laut Enterprise Software Lifecycle.
58. Ivanti Low User Impact Migration Portal Guide: Getting started, Migration Portal 20.0, März 2026; Getting started.
59. Ivanti Migration Portal Guide: Mobile@Work features, Migration Portal 20.0; Mobile@Work for iOS / Android.
60. Ivanti Migration Portal Guide: Support and compatibility, Migration Portal 20.0; Migration Portal 20.0.0.
61. Ivanti: Neurons for MDM Sovereign Edition – EU, Pressemitteilung 14.04.2026; Hosting und Betrieb.
62. Ivanti: Releases Q2 2026, Q2 2026; Ivanti Neurons for MDM.
63. BlackBerry UEM: Overview and Architecture, BlackBerry UEM 12.24; UEM Cloud; Connectivity Node; Secure Gateway (S. 24–28).
64. BlackBerry UEM: Planning, Port requirements, BlackBerry UEM 12.24; Port requirements (S. 33–45).
65. BlackBerry UEM: Configuration, BlackBerry UEM 12.24; Entra Conditional Access (S. 42–45); Migration (S. 59–64); Direct Connect (S. 71).
66. BlackBerry UEM: Installation and upgrade, Dark Site, BlackBerry UEM 12.24; Dark-Site-Installation (S. 24–28).
67. Microsoft Learn: Third-party device compliance partners in Intune, aktualisiert 23.09.2026; Supported partners; Requirements; Add a compliance partner.
68. BlackBerry Enterprise Licensing Guide, September 2026; UEM Feature Summary (S. 6–7).
69. BlackBerry UEM: Managing apps, BlackBerry UEM 12.24; App-Konfiguration (S. 9–11); Dynamics (S. 37–38, 47, 55).
70. EU-Kommission: Cloud Sovereignty Framework, Version 1.2.1, Oktober 2025; Sovereignty Objectives (S. 2–3).
71. BSI: BlackBerry UEM Server, BSI-DSZ-CC-1235-2025, UEM Server 12.21.1; Zertifikatseintrag.
72. BSI: Zertifizierte Produkte nach Common Criteria, Stand 13.10.2026; Produktliste.
73. Apple Platform Deployment: Migrate managed devices, iOS/iPadOS 26 und neuer; Requirements; Preserve managed apps.
74. Apple Platform Deployment: Intro to device management, Onlinefassung Oktober 2026; Enrollment profiles.
75. BlackBerry UEM: Activating devices, BlackBerry UEM 12.24; Aktivierungsarten iOS und Android (S. 5–12).
76. Google: Provision devices (Android Enterprise), Stand 28.08.2025; Device owner provisioning methods.
77. Google: Wipe and deprovision a device, Stand 25.06.2025; WIPE.
78. BlackBerry UEM: Managing device configurations, BlackBerry UEM 12.24; IT-Policy und Profile (S. 8, 27).
79. BlackBerry UEM: Managing secure connections, PKI, BlackBerry UEM 12.24; Using PKI certificates (S. 60–80).
80. BlackBerry Work 3.20: App configuration settings, BlackBerry Work 3.20; Exchange und Modern Authentication.
81. BlackBerry UEM: Managing email, calendar, and contacts, BlackBerry UEM 12.24; Gatekeeping (S. 6–14).
82. Apple Platform Deployment: Plan your device management migration, Stand 17.09.2026; Recreate profiles; Test the migration.
83. BlackBerry Enterprise Mobility Server: What is BEMS?, BEMS 3.10; Dienste.
84. BlackBerry KB 000134689: iOS native Mail client is blocked by Entra Conditional Access when UEM is configured as a compliance partner, Stand 03.03.2026, BlackBerry-Konto erforderlich; Cause; Workaround.