Kategorie: MDM

BlackBerry UEM Release 12.23 … just a little Watch Back

11. Mai 2026 / / Keine Kommentare

BlackBerry UEM 12.23: Das November-Update im Reality-Check, just a little Watch Back

Heute mal ein kleiner Watch back und ich schaue mir das 12.23 release von BB und Ihrem UEM an. Ich hatte ja in meiner Zeit beim Land, mehr als genug mit BB zutun. Dann kam der wechsel und die letzten 7,5 Jahren, waren mehr WS1 und nachher Intune im UEM & MDM Feld im Fokus. Nun ist es aber auch mal wieder Zeit, sich dem alten Herren in Schwarz zu widmen und auch diesen zu beleuchten.

Es ist November 2026 und UEM 12.23 ist da – und ehrlich gesagt: Das ist kein Release, das große Headlines verdient. Das ist ein solides, pragmatisches Update, das zeigt, wohin BlackBerry UEM wirklich unterwegs ist. Kein Marketing-Blabla, keine zehn neuen Features, die niemand braucht. Stattdessen: Stabilität, Sicherheit, Zertifizierungen.

Wenn eine neue Version im November kommt und die Release Notes nicht vor Features überlaufen, ist das erfrischend ehrlich. BlackBerry hat verstanden: In einem etablierten UEM-System geht es nicht um Raketenfunktionen, sondern um Zuverlässigkeit.

Das Wichtigste in einer Tabelle

Feature / Bereich 12.23 Relevanz Status
Upgrade-Pfade von 12.21, 12.22 Standard ✓ Supported
iOS/iPadOS Tag-Null Support für aktuelle OS Enterprise-Muss ✓ Ready
Android Android Enterprise, Management API Standard ✓ Stabil
Windows 10/11 MDM-Management Enterprise-Standard ✓ Unterstützt
macOS Vollständige Unterstützung BYOD/Enterprise ✓ Stabil
Automatische Backups Setup-Tool integration Betrieb-Critical ✓ Automatisch
Gatekeeping Microsoft 365 Modern Auth Email-Management ✓ Optimiert
BlackBerry Connectivity Node Optional für große Umgebungen Skalierung ✓ Verfügbar

Was sich in 12.23 konkret ändert

Installation und Upgrade

Die Setup-Anwendung erlaubt Installation von UEM 12.23 oder Upgrade von UEM 12.21 oder 12.22. Das ist sauber: Sie sind nicht auf eine Version beschränkt, können aber überspringen sollten Sie noch auf 12.20 sein (das ist dann ein etwas aufwändigeres Upgrade, das ich separat planen würde).

⚠️ Breaking Change Watch: Wenn der Setup-Tool lädt, stoppt und startet er alle UEM-Services automatisch. Das ist normal – aber planen Sie Wartungsfenster. In Produktionsumgebungen machen Sie das am Wochenende oder nachts. Die Datenbank wird automatisch gebackt, aber trotzdem: Backups vor dem Upgrade, auch wenn die Software das macht.

Database-Anforderungen verschärfen sich

BlackBerry UEM Core Server müssen weniger als 5ms Latenz zur Datenbank haben. Das ist nicht neu, aber wird strikte überprüft. Wenn Sie eine Standard-SQL-Server-Installation mit Fernanbindung haben und die Latenz borderline ist – jetzt wird das zum echten Problem. Optimieren Sie vorher.

Sicherheit: JRE 17 ist Pflicht

JRE 17 muss auf dem Computer installiert sein, der UEM hostet. Das ist eine harte Anforderung. Wenn Sie noch auf JRE 11 rumfahren: Das endet jetzt. JRE 17 ist seit November 2023 LTS, also aktuell und stabil.

Plattform-spezifische Neuerungen

iOS & iPadOS

BlackBerry UEM ist eine Multi-Platform-EMM-Lösung, die umfassendes Device-, App- und Content-Management mit integrierter Sicherheit für iOS, macOS, Android und Windows 10 Geräte bereitstellt.

Für iOS-Admin bedeutet 12.23:
– Tag-Null-Kompatibilität mit den neuesten iOS-Versionen (der Standard in jedem BlackBerry-Release)
– Verwaltung von Zertifikaten für Devices und Apps mittels UEM-Profilen und Setup von Work Connections.
– VPN-Profile und PKI sind weiterhin der Standard

Praxis-Tipp: Wer noch auf ältere iOS-Versionen verteilt ist – plant jetzt das Upgrade auf 12.23, damit bei iOS 19 keine Überraschungen kommen.

Android

Keine großen Explosionen hier. OEMConfig-Apps erlauben Administratoren, Device-spezifische Funktionen über App-Konfigurationen zu verwalten, wie für Samsung Knox und andere Hersteller.

Die wichtigsten Unterstützungen:
– Android Enterprise – Standard und stabil
– Android Management API (AMAPI) – für modernere Gerätekontrolle
– Samsung Knox – weiterhin vollständig

Was sich nicht ändert: Das Android-Management in BlackBerry UEM ist pragmatisch, nicht flashy. Policies, Compliance, App-Verwaltung – all bewährte Features.

Windows 10/11

Windows 10 Devices werden als Teil des umfassenden Device-Management unterstützt. Windows 11 auch – obwohl die Docs noch „Windows 10“ sagen, ist das eine dokumentations-Verzögerung.

Für Enterprise-Umgebungen, die Intune für Windows nutzen: BlackBerry UEM can Co-Exist, ist aber eher für spezialisierte Szenarien (alte Geräte, Hybrid-Umgebungen, sehr restrictive Sicherheitsrichtlinien).

Sicherheit und Zertifizierungen – Das Eigentliche Update

Das große News für 12.23 ist nicht in den technischen Features, sondern in der Compliance-Welt: BlackBerry UEM ist das erste UEM-Produkt, das BSI-Zertifizierung erreicht hat und wurde gegen die Common Criteria Standards auf den höchsten Levels validiert.

Was bedeutet das praktisch?

  • Deutsche Regierungsbehörden müssen jetzt nicht mehr auf Ausnahmegenehmigungen kämpfen
  • NATO-Länder, Skandinavien, Frankreich sehen das als Vertrauenszeichen
  • Kritische Infrastruktur (Energie, Telekommunikation, Gesundheit) bekommt ein zusätzliches Zertifikat

Für normale Enterprise-Kunden ist das eher ein Verkaufs-Feature („Ja, sogar die deutsche Bundesregierung vertraut uns“). Aber für hochregulierten Umgebungen: Das ist jetzt ein Kaufargument.

Gatekeeper und Microsoft 365 Authentication

Für Modern Authentication mit Microsoft 365 muss man ein Entra-App hinzufügen und dessen Details bereitstellen – man muss nicht die Anmeldedaten eines M365-Admin-Kontos angeben, sondern nur das Entra Application ID und Organization Values.

Das ist ein echter Fortschritt für größere Orgs:
– Weniger Admin-Accounts mit Super-Privilegien
– OAuth-basiert, nicht mehr nur Legacy-Auth
– Microsoft-Integration wird moderner

Handlungsbedarf: Das musst du vor dem Upgrade wissen

1. Datenbank-Latenz überprüfen – JETZT

Nicht erst im Upgrade. Führe einen Test durch:

ping <deine-db-server>

Wenn die Latenz über 10ms ist, hast du ein Problem. Unter 5ms: Alles gut.

2. JRE 17 im Voraus installieren

Nicht während des Upgrades. Installiere JRE 17 auf dem UEM-Server, teste es, dann erst das Upgrade.

3. Backups – und zwar echte Backups

Die Software macht das automatisch, aber:
– Externe Backups VOR dem Upgrade
– Oder: Snapshot der ganzen VM vor dem Upgrade
– Test-Restore auf einer Testumgebung, falls möglich

4. Notification der Nutzer

Das Upgrade stoppt Services. Mach es nachts oder am Wochenende. User sollten das nicht während der Arbeit erleben.

5. Critical Issue Advisories lesen

Die dokumentierten Critical Issue Advisory Knowledge Base Articles für UEM und Enterprise Mobility Server sollten vor dem Upgrade gelesen werden. BlackBerry publiziert dort wichtige Gotchas.

Marktkontext: Wohin geht BlackBerry UEM?

Seien wir ehrlich: BlackBerry UEM ist eine Nischen-Lösung. Das ist nicht negativ gemeint – es ist realistisch.

  • Große Konzerne mit Sicherheits-Paranoia? → BlackBerry UEM
  • Regierungen, Militär, kritische Infrastruktur? → BlackBerry UEM
  • Mittelständler mit Standard-Anforderungen? → Intune, Jamf, MobileIron

Das Release 12.23 zeigt das deutlich: Keine Konsumenten-Features, keine Mobile-First-Optik. Sondern:
– Stabilität
– Compliance
– Enterprise-Hardening

Die BSI-Zertifizierung ist nicht zufällig: Sie zeigt, dass BlackBerry sich bewusst positioniert – nicht „für jeden“, sondern „für die, die Security ernst nehmen“.

Fazit: Solltest du upgraden?

Ja, aber:

  1. Wenn du aktuell auf 12.21 oder 12.22 bist → Im nächsten Wartungsfenster. Das ist ein normales Stabilitäts-Update.
  2. Wenn du auf 12.20 oder älter bist → Plane einen größeren Upgrade-Prozess. Das ist ein Multi-Version-Jump.
  3. Wenn du von anderer Lösung kommst → 12.23 ist aktuell und stabil. Guter Zeitpunkt für einen New Deployment.
  4. Wenn du in stark regulierter Branche bist → Die BSI-Zertifizierung könnte Compliance-Anforderungen erfüllen, die bisher ein Problem waren.

Was ich nicht empfehle: Hektik. Dieses Release ist nicht „müssen sofort upgraden“. Es ist ein „plane in den nächsten 2-3 Monaten und mach es dann“.

Die Technologie ist reif, die Anforderungen sind klar, die Migration ist standardisiert. Das ist das Gegenteil von hastig.

Die letzte Realität

Nach 16+ Jahren in MDM-Land sag ich dir eins: Die besten Enterprise-Updates sind die, die man kaum merkt. Man startet die Systeme neu, alles läuft wie vorher, die Devices synchronisieren sich, Policies pushen, Compliance wird überwacht.

Das ist 12.23. Genau das.

Ressourcen & Dokumentation

Omnissa Workspace ONE UEM Release 2604

10. Mai 2026 / / Keine Kommentare

Hey Leute,

ich hatte es ja versprochen und nun kommt mein Artikel zum neuen 2604. Geile release Nummer by the Way (kleiner Insider 🤩). Das 2604 Release ist einer der expansivsten der letzten Zeit und baut auf dem Momentum der 2602 auf . Und ehrlich? Das ist die Release, auf die viele von euch gewartet haben. Windows Server endlich im UEM-Universum, macOS-Admins können die Verpackungsorgie lassen, und mit Vulnerability Defense gibt’s jetzt auch nen CrowdStrike-Integration (mir stellen sich die Nackenhaare auf 🤯🤓, aber das ist eher ein persönliches Problem mit CrowdStrike wieder so ein Insider), die tatsächlich Sinn macht.

Ich bin mir aber auch bewusst: Das ist eine Broadcom/KKR-Omnissa, die hier liefert. Die Richtung stimmt, die Features sind solid – aber wir beobachten weiterhin kritisch, wie stabil das bleibt und ob OEMConfig, Rugged und DEX im Fokus bleiben.

Lass mich ein paar Stunden recherchiert haben und dann durch die Features nehmen.

Übersichtstabelle: Features nach Kategorie

Feature Plattform Kategorie Status
Windows Server Management (Enroll 2016+) Windows Server Infrastructure GA
Granular Patch Management Windows Server OS Management GA
Vulnerability Defense (CrowdStrike Integration) Windows Security Limited Availability
Enterprise App Repository (macOS) macOS App Management GA
Platform SSO in Setup Assistant (ADE) macOS, iOS Enrollment Limited Availability
App Preservation during MDM Migration iOS/iPadOS 26+ App Lifecycle GA
Redesigned UEM Console All UI/UX GA
Phased Deployments (Percentage-based) All Deployment GA
Ansible in Custom Config Profiles Linux Configuration GA
Device Update Profile (SUSE Linux) Linux (openSUSE, SLED, SLES) OS Updates GA
Platform-specific ADE Default Profiles iOS, macOS Enrollment GA
Application Removal Protection Improvements iOS App Security GA

Die Top Features im Detail

🖥️ Windows Server Management – Jetzt generell verfügbar (GA)

Das ist die Headline: Windows Server Management ist nun generell verfügbar in Workspace ONE UEM und bringt Server-Infrastruktur in die gleiche Management-Ebene wie der Rest der Endpoint-Flotte .

Konkret:

  • Enroll Windows Server 2016 oder später via Intelligent Hub, und sie tauchen neben deinen Desktops auf mit Server-spezifischen Details wie installierten Rollen und Features
  • Du kannst die Tools nutzen, die du schon kennst: ADMX-Profile mit vorgeladenen Templates, Baselines für automatische Config-Refresh, granulare OS-Patching mit Scheduling, vollständiges App-Lifecycle-Management via Enterprise Application Repository, und Freestyle Orchestrator für Automation
  • Remote Support funktioniert auch: Screen Share, File Access, Command Line – genauso wie bei Desktops

Das ist clever gedacht von Omnissa. Jahrelang haben Server-Teams separate Tools gebraucht. Jetzt ist die Frage: Wie tief geht das? Die ADMX-Integration und das Patching-Handling hören sich solide an. Aber ich warte auf Real-World-Reports zu Skalierungsfragen – einen 5.000er Server-Fleet mit WS1 zu patchen ist nochmal ne andere Hausnummer als Desktops.

Granular Patch Management: Du kannst spezifische Updates aus dem Windows Update Catalog suchen und selektieren, sie auf definierte Server-Gruppen zielen und die Deployment innerhalb deinem Timeframe planen. Du kannst sogar Updates vorab herunterladen, damit die Installation sofort startet, wenn die Zeit kommt .

🔒 Vulnerability Defense + CrowdStrike Falcon – Limited Availability

Workspace ONE Vulnerability Defense tritt in Limited Availability ein und bringt einen kompletten Assessment-to-Remediation-Workflow direkt in die Omnissa Platform für Windows Endpoints. Die Lösung integriert WS1 UEM mit CrowdStrike Falcon Exposure Management, um die Lücke zwischen Vulnerability Management, Exposure Discovery und Remediation zu schließen .

Der Workflow:

  • Wenn ne CVE oder High-Risk-Bedingung identifiziert wird, mapped WS1 UEM das automatisch zu betroffenen Endpoints für schnelle Risk-based Priorisierung
  • Empfohlene Remediation Paths werden direkt in der Admin-Console angezeigt, zusammen mit vorkonfigurierten Updates aus dem Enterprise App Repository. Patches und App-Updates werden über UEM ausgeliefert und IT-Teams können den Remediation-Progress monitoren

Die Integration mit CrowdStrike ist clever – Falcon hat etablierte Visibility, und jetzt hast du direkt im UEM-Portal die Remediation-Automation. Das reduziert Ticket-Ping-Pongs massiv. Aber: Limited Availability heißt, das ist noch nicht für alle da. Warte auf GA, bevor du architektural darauf planst. Und der CrowdStrike-Lizenz-Stack ist nicht zu unterschätzen.

🍎 Enterprise App Repository (macOS) – Jetzt GA

Das war lange überfällig. Workspace ONE UEM launcht die Enterprise App Repository (EAR) für macOS – ein kuratierter Katalog von beliebten Applikationen, der Deployment und laufende Verwaltung streamlined .

Praktisch:

  • Admins können Apps aus dem Repository direkt in der UEM-Console selektieren und sofort in Device-Gruppen deployen – kein manuelles Packaging nötig
  • Updates werden automatisch gehandhabt, und Notifications halten Admins informiert, wenn neue Appversionen verfügbar sind
  • Das App-Repository integriert nativ mit bestehenden UEM Assignment Workflows – Deployment passiert wie mit jeder anderen verwalteten App

Endlich. macOS-Admins hatten bisher ne Lücke: Android und iOS haben ihre App-Kataloge, aber macOS-Packaging war immer ne Sandbox, wo man sich selbst überlassen war. Mit der EAR kriegt ihr da Consistency. Die Frage ist: Wie groß ist der Katalog wirklich? Und können Custom Apps dazukommen? Aber für die Top-Use-Cases (Office, Teams, Browser, Dev-Tools) ist das jetzt ein echter Gewinn.

🔐 Platform SSO beim Setup Assistant (ADE) – Limited Availability

Platform SSO kann jetzt direkt im Setup Assistant während Automated Device Enrollment (ADE) konfiguriert werden. Wenn ein Device ADE durchläuft, authentifizieren sich User mit ihrem Org-Identity-Provider und erstellen ihren ersten Local Account – alles während Initial Setup, bevor das Device übergeben wird. Keine zusätzlichen Schritte, kein separater Profile Push .

Das Resultat ist eine cleanere Onboarding-Experience und eine stärkere Security-Baseline von Tag 1 .

Das ist die richtige Richtung. Zero-Touch Enrollment mit PSSO on Day 0 – das war der USP von großen Apple-Lösungen, und jetzt kann WS1 das auch. Noch im Limited Availability Status, aber sobald das GA ist, sollte das zum Standard gehören für neue Mac-Enrollments.

📱 App Preservation during MDM Migration (iOS 26+)

Workspace ONE UEM führt granulare App Preservation während MDM Migration für iOS/iPadOS 26+ Devices ein .

Das Szenario: Du migrierst eine Flotte von nem anderen MDM zu WS1? Früher wurden die Apps gelöscht und neuinstalliert – Friction für User, Komplexität für IT. Jetzt können Apps erhalten bleiben.

Praktisch für größere Migrations-Szenarien. Aber iOS 26+ ist ne spezifische Anforderung – für ältere Devices musst du weiterhin mit App-Reinstall rechnen.

🖼️ Redesigned UEM Console – Now GA

Die neu designte WS1 UEM Admin-Console ist jetzt generell verfügbar. Sie ist auf einem modernisiertem Tech-Stack gebaut, geprägt von iterativem User Research und Testing. Die neue Experience reorganisiert Navigation in logischere Kategorien, stellt die meistgenutzten Features in den Vordergrund, und ersetzt Labels, die Institutional Knowledge brauchten, durch Sprache, die sofort klar ist .

UI-Überarbeitungen sind immer zweischneidig. Manche Admins haben Jahrzehnte in der alten Console gelebt. Aber wenn das Research-driven ist und auf Usability-Testing basiert, sollte das okay sein. Wird schnell klar, ob das wirklich besser ist oder nur anders. Ich bin gespannt drauf.

📊 Phased Deployments mit Percentage-based Rollout – GA

Phased Deployments sind jetzt GA, und diese Release fügt ne neue Capability hinzu: Admins können jede Phase jetzt nach Prozentanteil der Zielgruppe definieren, statt Gruppen explizit zu spezifizieren .

Praktisch: „Rollout an 10% → 25% → 50% → 100%“ ohne dass du Gruppen manuell aufteilen musst.

Das ist ein DLP-Playing-Field. Apple hat das via MDM-Restrictions seit Jahren, Microsoft Intune auch. Jetzt kann WS1 auch prozentual rollout – das ist gut.

🐧 Ansible in Linux Custom Config Profiles + SUSE Update Management

Zwei Linux-Highlights:

  1. Ansible Support: Enterprise Linux Environments vertrauen oft auf Ansible für Configuration Management. In 2604 bringt WS1 UEM diese Capability direkt ins Custom Configuration Profile. Ansible ist jetzt neben Bash, Python und Puppet als unterstützter Payload-Type verfügbar. Admins können Ansible Playbooks nutzen, um enrolled Linux Devices zu konfigurieren, mit Support für Ansible Collections und Roles .
  2. Device Update Profile für SUSE: Das Device Update Profile erweitert sich auf SUSE-basierte Linux Devices (openSUSE, SLED, SLES). Admins können das Level und die Frequenz von automatischen Updates konfigurieren, Security- und Policy-spezifische Update Rules, und Notifications für neue Major OS Versions .

Das ist solider Enterprise-Linux-Support. Ansible ist das Orchestration-Tool, und wenn WS1 das nativ unterstützt, brauchst du weniger Custom Integrations. Für SUSE-Shops ist das dann ne große Erleichterung.

🔧 Platform-specific ADE Default Profiles (iOS & macOS)

Ein Clarity-Feature: Admins können jetzt platform-spezifische Default ADE Profiles assignen. iOS und macOS können unterschiedliche On-Boarding-Profile haben, ohne dass man überall Conditional Logic bauen muss.

⚠️ Handlungsbedarfe & Deprecations

Vulnerability Defense: Limited Availability Status

Vulnerability Defense ist noch nicht GA. Wenn du das architekturiert, solltest du mit dem Omnissa-Account-Team aligned sein. Das kann sich bis GA noch verschieben.

CrowdStrike-Lizenzierung

Wenn du Vulnerability Defense einführen willst, brauchst du nicht nur WS1 UEM, sondern auch CrowdStrike Falcon Exposure Management. Das ist ein separater Lizenzstack – kalkuliere das mit in deine TCO.

Windows Server 2016+ Requirement

Windows Server Management funktioniert nur ab 2016. Wenn du ältere Server-Flotten hast (2012 R2, 2008 R2), brauchst du weiterhin separate Tools.

iOS 26+ für App Preservation

App Preservation during Migration funktioniert nur auf iOS/iPadOS 26+. Ältere Devices haben weiterhin App-Wipe während Migration.

Vergleich zu Microsoft Intune: Wo WS1 Vorteile hat

Der 2604 Release ist eines der expansivsten in letzter Zeit und baut auf 2602-Momentum auf . Wenn du Intune mit WS1 vergleichst:

Feature Workspace ONE UEM 2604 Microsoft Intune
Windows Server Management ✅ Jetzt GA ❌ Nicht native
macOS Enterprise App Repository ✅ GA (curated) ⚠️ Basic app store integration
Rugged Device Support ✅ OEMConfig first ❌ Limited
Linux Management ✅ Ansible

iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in

13. März 2026 / / Keine Kommentare

iOS 26: MDM-Migration ohne Factory Reset – Apple beendet den Vendor Lock-in

Apple löst eines der lästigsten Probleme in der Apple-Enterprise-Welt: Mit iOS/iPadOS/macOS 26 könnt ihr eure Geräte direkt im Apple Business Manager zwischen MDM-Lösungen verschieben – ohne Wipe, ohne Nachtschicht, ohne Drama. Fast.

Ab iOS/iPadOS/macOS 26 könnt ihr ADE-enrolled Corporate Devices direkt im ABM einem neuen MDM zuweisen – kein Factory Reset nötig. Ihr setzt eine Deadline, der User bekommt eine Notification, das Gerät enrollt sich neu. Persönliche Daten bleiben erhalten. Managed Apps auf iPhone/iPad werden entfernt und müssen vom neuen MDM neu ausgerollt werden. VPP-Lizenzen wandern nicht automatisch. Vorbereitung ist trotzdem Pflicht.

Was ist neu – und stimmt das wirklich?

In den letzten Wochen macht ein LinkedIn-Post die Runde, der das neue Feature von iOS 26 beschreibt. Kaum gelesen, weckte dieser Post mein Interesse.

Im Kern stimmt er – aber ein paar Details sind ungenau oder fehlen komplett. Ich hab das Ganze gegen die offizielle Apple-Dokumentation, Microsoft Intune Docs und mehrere MDM-Hersteller-Guides gecheckt. Hier kommt der vollständige Faktencheck.

Abb. 1: MDM-Migration bisher vs. ab iOS/iPadOS/macOS 26

Was stimmt (korrekte Claims im Umlauf)

  • MDM-Migration ohne Factory Reset für iOS/iPadOS/macOS 26 – korrekt
  • Steuerung komplett über Apple Business Manager – korrekt
  • Deadline-Feature mit automatischem Erzwingen – korrekt
  • User-Notifications mit steigender Häufigkeit – korrekt
  • Persönliche Daten bleiben auf dem Gerät – korrekt
Was fehlt oder ist ungenau (wichtige Details)

  • „Ohne Datenverlust“ ist nuanciert: Persönliche Daten bleiben, aber MDM-verwaltete Apps werden auf iPhone/iPad beim Unenrollment entfernt – außer das neue MDM liefert sie via await_device_configured rechtzeitig nach.
  • Nur für ADE-enrolled Corporate Devices: BYOD-Geräte sind komplett ausgeschlossen. Shared iPad und Apple Business Essentials ebenfalls nicht unterstützt.
  • Einmaliger Reset bei alten ABM-Einschreibungen: Geräte, die ursprünglich mit iOS < 26 in ABM eingeschrieben wurden, benötigen EINMALIG einen Reset zur Re-Registrierung. Danach nie wieder.
  • VPP-Lizenzen migrieren nicht automatisch: Der Apps & Books Content Token muss manuell aus dem alten MDM entfernt und im neuen registriert werden.
  • Vorbereitung ist Pflicht: Konfigurationsprofile, Compliance-Policies, Scripts und App-Deployments müssen im neuen MDM vorab nachgebaut werden.

Wie funktioniert das technisch?

Apple hat den nativen MDM-Protokoll-Stack erweitert. Der ABM koordiniert jetzt aktiv den Wechsel zwischen zwei MDM-Servern und kommuniziert gleichzeitig mit beiden. Das Gerät wird vom alten MDM unenrollt und enrollt sich direkt in das neue – alles gesteuert durch das OS, ohne manuellen Eingriff.

Technisch relevant: Das Feature basiert auf Declarative Device Management (DDM). Die Logik läuft direkt auf dem Gerät, wodurch die Abhängigkeit vom MDM-Server reduziert wird. Apple rotiert dabei automatisch sicherheitsrelevante Keys – z.B. den FileVault Personal Recovery Key auf macOS.

Was bleibt auf dem Gerät, was wird entfernt?
Was iPhone/iPad Mac
Persönliche Daten Bleiben vollständig erhalten Bleiben vollständig erhalten
MDM-Konfigurationsprofile Werden entfernt Werden entfernt
Managed Apps (MDM-deployed) Werden entfernt (*) Bleiben ggf. erhalten
App-Daten (bei Preservation) Bleiben bei korrektem Setup Bleiben bei korrektem Setup
VPP-Lizenzen Manuell migrieren! Manuell migrieren!
Activation Lock / Bypass Code Wird vom neuen MDM neu erstellt Wird vom neuen MDM neu erstellt
FileVault Key (macOS) N/A Wird automatisch rotiert

(*) Managed Apps können bei korrektem Setup preserviert werden: Das neue MDM muss die Apps per await_device_configured installieren, bevor DeviceConfigured gesendet wird. Declarative Managed Apps werden immer behalten.

Voraussetzungen

Bevor ihr loslegt, müssen folgende Punkte erfüllt sein:

Abb. 2: Voraussetzungen auf einen Blick

  • Gerät läuft auf iOS 26, iPadOS 26 oder macOS 26
  • Gerät ist per Automated Device Enrollment (ADE) enrolled – kein User Enrollment, kein BYOD
  • Gerät ist in Apple Business Manager (ABM) oder Apple School Manager (ASM) erfasst
  • Neues MDM ist als MDM-Server in ABM konfiguriert (Token-Austausch abgeschlossen)
  • APNs-Zertifikat im neuen MDM ist aktiv
  • VPP/Apps & Books Token für das neue MDM ist eingerichtet (falls Apps per VPP deployt werden)
  • Neues MDM ist vollständig vorbereitet: Profile, Policies, Apps und Scripts nachgebaut
Einschränkungen

  • Nicht unterstützt: Apple Business Essentials, Shared iPad, BYOD-Geräte
  • Return to Service mit App Preservation (is_return_to_service = TRUE) blockiert die Migration
  • Geräte offline nach Unenrollment: User wird zur WLAN-Auswahl geleitet, bis Migration abgeschlossen
  • Bei VPP-Apps: Deadline nicht größer als 30 Tage setzen

How-to: MDM-Migration mit iOS 26 – Schritt für Schritt

Phase 1: Vorbereitung (vor dem ersten Klick in ABM)

Die Migration selbst dauert Minuten – aber die Vorbereitung entscheidet über Erfolg oder Chaos. Hier solltet ihr keine Abkürzungen nehmen.

# Aufgabe Prio
1  Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status Pflicht
2  Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail Pflicht
3  Compliance-Policies, Security-Baselines und Scripts erfassen Pflicht
4  App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs Pflicht
5  Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen Pflicht
6  VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren Kritisch
7  Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout Empfohlen
8  User-Kommunikation vorbereiten: Was passiert, wann, was müssen User tun Empfohlen

Phase 2: Migration in ABM starten

  1. Anmelden bei business.apple.com als Administrator oder Device Enrollment Manager
  2. Im Seitenmenü auf ‚Devices‘ gehen
  3. Geräte suchen und auswählen (Seriennummer, Order-Nummer oder Filter ‚Eligible Devices‘ nutzen)
  4. Auf das Gerät klicken → ‚…‘ (Ellipsis-Menü) oder ‚Edit‘ → ‚Assign Device Management‘
  5. Neuen MDM-Server auswählen
  6. ‚Add Deadline‘ klicken und Datum/Uhrzeit setzen (kein Deadline = kein automatisches Erzwingen)
  7. ‚Continue‘ → Prompt lesen → ‚Confirm‘

Hinweis: Ohne Deadline kein Zwang!

Wenn ihr keine Deadline setzt, migriert das Gerät nur bei einem nächsten Erase oder wenn ihr manuell den profiles-Befehl ausführt. Für einen kontrollierten Rollout immer Deadline setzen.

Troubleshooting: „Add Deadline“ nicht verfügbar

Wenn der „Add Deadline“-Button im ABM ausgegraut ist oder gar nicht erscheint, liegt das fast immer an einem der folgenden drei Gründe:

Problem Ursache Lösung
OS < iOS/iPadOS/macOS 26 ABM zeigt die Option erst ab iOS 26 an – das Feature ist OS-seitig implementiert Gerät auf iOS 26 updaten, dann erneut in ABM prüfen
Gerät nur „Assigned“, nicht „Enrolled“ Migration setzt aktives, laufendes Enrollment voraus – „Assigned“ allein reicht nicht Gerät normal enrollen, dann Migration starten
Gerät im Status „Pending“ Gerät frisch ausgepackt oder noch im Setup Assistant – Enrollment-Flow noch nicht abgeschlossen Setup abschließen und einmalig enrollen, dann Option prüfen
Enrolled, aber Option fehlt trotzdem Letzter Check-in zu weit zurück oder MDM-Push ausstehend Force Check-in über MDM senden, ABM-Seite neu laden
Quelle = „Apple Configurator“ Gerät wurde manuell über Configurator 2 in ABM eingebracht – nicht über Reseller/DEP Siehe nächster Abschnitt
Schnellcheck: Enrolled vs. Assigned

Den Enrollment-Status „Enrolled“ bzw. „Assigned“ findet ihr nicht in ABM, sondern im jeweiligen MDM (z.B. Intune: Geräte → Gerät auswählen → Übersicht). ABM zeigt unter „Geräteverwaltungsdienst“ nur den zugewiesenen MDM-Server – keinen separaten Enrolled/Assigned-Status.

Was ihr direkt in ABM prüfen solltet: das Feld „Quelle“ unter Details. Steht dort „Apple Configurator“ → siehe nächster Abschnitt. Steht dort „Apple“ oder ein Reseller-Name → Migration sollte funktionieren, sofern das Gerät auf iOS 26 läuft und aktiv enrolled ist.

Sonderfall: Quelle „Apple Configurator“ – Migration nicht möglich

Wenn im ABM-Gerätedetail unter „Quelle“ der Wert „Apple Configurator“ steht, wurde das Gerät manuell über Apple Configurator 2 in ABM eingebracht – und nicht automatisch über den Kaufprozess via Reseller oder direkt bei Apple. Die Quelle ist fest gesetzt und lässt sich nachträglich nicht ändern. Die Option „Add Deadline“ erscheint für diese Geräte nicht.

Optionen und Lösungswege

Option 1 – Einmaliger Reset auf iOS 26 (empfohlen): Factory Reset des Geräts auf iOS 26. Beim Neuaufsetzen enrollt es sich sauber im ADE-Flow. Danach funktioniert die nahtlose MDM-Migration – dauerhaft, ohne weiteren Reset. Der einmalige Wipe ist der „Eintrittsbonus“ für den neuen Mechanismus.

Option 2 – Aus ABM entfernen und neu hinzufügen: über Configurator 2 möglich, ändert aber nichts – die Quelle bleibt „Apple Configurator“. Für dieses Problem kein sinnvoller Weg.

Option 3 – Für neue Geräte: Geräte künftig direkt über einen Apple Authorized Reseller oder Apple selbst kaufen. Diese landen automatisch mit Quelle „Apple“ bzw. Reseller-Name in ABM und sind von Anfang an für die nahtlose Migration geeignet.

Phase 3: User-Experience und Monitoring

Was der User sieht, hängt vom Zeitpunkt ab:

Abb. 3: Notification-Verhalten je nach Zeitpunkt bis zur Deadline

Zeitpunkt Notification-Verhalten
Deadline gesetzt Tägliche Benachrichtigung
24h vor Deadline Stündliche Benachrichtigung
Letzte Stunde Benachrichtigung alle 60, 30, 10 und 1 Minute(n)
Deadline erreicht Nicht-wegklickbarer Vollbild-Dialog, Enrollment wird erzwungen
Wann erscheint die erste Notification? Kann man das beschleunigen?

Die initiale Notification erscheint bei einem online Gerät in der Regel innerhalb weniger Minuten nach der ABM-Zuweisung. Der Ablauf dahinter: ABM benachrichtigt das alte MDM über das MDM-Protokoll → das alte MDM schickt einen APNs-Push ans Gerät → das Gerät checkt beim alten MDM ein, holt sich die Migration-Instruction und zeigt dem User die Notification an. Ist das Gerät offline, wartet APNs auf die nächste Verbindung.

Wichtig: Die täglichen, stündlichen und minuten-genauen Benachrichtigungen aus der Tabelle oben sind der Reminder-Rhythmus für den Fall, dass der User noch nicht reagiert hat – nicht der Zeitplan für die initiale Erstbenachrichtigung.

Beschleunigen möglich? Ja – aber nur über das alte MDM: einen manuellen Force Check-in / Sync-Befehl ans Gerät schicken. Das triggert sofort ein Check-in, das Gerät holt sich die Migration-Instruction und zeigt die Notification ohne Wartezeit an. Ein ABM-Sync im neuen MDM hat darauf keinen Einfluss – die User-Notification läuft ausschließlich über das alte MDM und APNs.

Phase 4: Was auf dem Gerät passiert (User-Flow)

Auf iPhone/iPad:

  1. User erhält eine Notification ‚Enrollment Required‘
  2. Tippen auf die Notification öffnet Einstellungen → VPN & Geräteverwaltung
  3. ‚Enrollment starten‘ antippen
  4. Gerät startet neu – nach dem Neustart enrollt sich das Gerät automatisch im neuen MDM
  5. Alle neuen MDM-Konfigurationen werden direkt im Anschluss OTA verteilt

Auf Mac:

  1. Notification erscheint im Notification Center
  2. Klick öffnet Systemeinstellungen → Geräteverwaltung
  3. ‚Enrollment starten‘ → Vollbild-Dialog → ‚Enroll‘
  4. MDM-Profile werden entfernt, Gerät enrollt sich neu
  5. Nach erfolgtem Enrollment: alle neuen MDM-Konfigurationen werden OTA verteilt
Was wenn’s schiefläuft?

Schlägt das Enrollment fehl (z.B. kein WLAN), wird das Gerät nicht mehr vom alten MDM verwaltet und gilt als ‚unmanaged‘. In diesem Fall: Gerät wie ein neu zu enrollendes Gerät behandeln. Es gibt keinen automatischen Rückfall zum alten MDM.

Wie sieht das konkret für Intune und Workspace ONE aus?

Beide Lösungen unterstützen das Feature. Die Vorbereitung auf Intune-Seite laut Microsoft:

  • APNs-Zertifikat in Intune hochladen
  • ABM/ASM-Token in Intune registrieren (gegenseitiger Token-Austausch)
  • Enrollment Profile in Intune erstellen und Geräten zuweisen
  • Danach in ABM: MDM-Server auf Intune umstellen und Deadline setzen

Für Workspace ONE gilt dasselbe Prinzip. Da ich in nächster Zeit den ganzen Prozess selbst teste, folgt dazu ein detaillierter Praxisbericht – Stay tuned.

Best Practices für die Praxis

  • Immer mit einer Pilot-Gruppe anfangen: 5–10 Geräte, alles prüfen, dann skalieren.
  • Separate ABM-Server-Tokens: Für altes und neues MDM je einen eigenen Token verwenden.
  • await_device_configured nutzen: Dadurch können Apps (inkl. deren Daten) preserviert werden – wichtig für nahtlose User-Experience.
  • VPP-Migration zuerst planen: Token aus altem MDM ZUERST entfernen, dann im neuen registrieren. Deadline max. 30 Tage bei VPP-Apps.
  • User-Kommunikation: Vorab informieren, was passiert. Kein Datenverlust, aber der Enrollment-Dialog kommt – das kann erschrecken.
  • Offline-Fälle einplanen: Geräte ohne WLAN nach der Deadline landen im Setup-Assistant, bis sie sich verbinden.

Managed Home Screen: Woher kommt der angezeigte Gerätename?

8. März 2026 / / Keine Kommentare

Managed Home Screen: Woher kommt der angezeigte Gerätename?

Wer den Microsoft Managed Home Screen (MHS) im Shared Device Mode einsetzt, kennt das: In der Top Bar wird ein Gerätename angezeigt – übersichtlich, praktisch, nützlich für Frontline-Worker-Umgebungen. Aber mal ehrlich: Hast du dich schon gefragt, wo dieser Name eigentlich herkommt? Aus dem Android-System? Aus Intune? Und was passiert, wenn du das Gerät in der Konsole umbenennst?

Genau diese Frage hatte ich letztens im Office und habe mich rangesetzt, um ihr auf den Grund zu gehen. Spoiler: Ich wusste schon intuitiv woher die Info kommt – aber ich wollte es dann doch etwas technischer beleuchten. 😄

1. Die Quelle: Nicht Android – sondern Intune

Kurze Antwort zuerst: Der angezeigte Gerätename kommt nicht vom Android-Betriebssystem selbst. Es ist nicht das, was unter Einstellungen → Gerät → Gerätename steht. Sondern es ist der Device Name-Eintrag aus dem Microsoft Intune Admin Center – also der Anzeigename, den du in der Verwaltungskonsole vergeben hast.

⚠️ Wichtig: Das Umbenennen eines Geräts in Intune ändert nur den Anzeigenamen in der Konsole – nicht den lokalen Gerätenamen auf dem Android-Betriebssystem selbst! MHS zeigt immer den Intune-seitigen Namen an.

2. Der Übertragungsweg: App Configuration Policy mit {{DeviceName}}

Der Name gelangt über eine App Configuration Policy an das Gerät. Microsoft stellt dafür die dynamische Variable {{DeviceName}} bereit – Intune löst diese Variable serverseitig auf und bettet den echten Gerätenamen in die Policy ein, bevor sie ans Gerät gepusht wird.

Die drei relevanten Konfigurationsschlüssel in der App Configuration Policy:

Konfigurationsschlüssel Wert Funktion
Top Bar Primary Element Device Name Gerätename als primäres Element (nur ohne Sign-In)
Top Bar Secondary Element Device Name Gerätename als sekundäres Element
Show device name for all supported OS versions on MHS {{DeviceName}} Pflichtfeld – Intune befüllt automatisch den korrekten Wert

ℹ️ Shared Device Mode – Sonderregel: Wenn Sign-In aktiviert ist, wird das primäre Top-Bar-Element automatisch durch den Namen des angemeldeten Benutzers ersetzt. Der Gerätename kann dann nur noch als sekundäres Element konfiguriert werden.

3. Wird der Name lokal gespeichert? Ja – aber nicht wo du denkst

Hier wird es technisch interessant. Der Gerätename wird lokal auf dem Gerät gespeichert – allerdings nicht in einer einfachen Datei oder Datenbank, die ein Nutzer einsehen könnte. Stattdessen nutzt Android dafür den sogenannten Managed Configuration Mechanismus, auch bekannt als App Restrictions oder RestrictionsManager.

Der vollständige Datenpfad

Schritt              Was passiert?
1 Intune löst {{DeviceName}} serverseitig auf → z.B. „DEV-WARD-01“
2 App Configuration Policy mit aufgelöstem Wert wird an das Gerät gepusht
3 Device Policy Controller (Intune / Company Portal) schreibt Wert ins Android Managed Config Bundle
4 Android RestrictionsManager speichert Bundle im geschützten Systembereich
5 MHS App liest Wert beim Start via RestrictionsManager.getApplicationRestrictions()
6 Anzeige des Namens in der Top Bar

Eigenschaften des lokalen Caches

Eigenschaft Detail
Speicherort Systembereich des Android OS – nicht im App-eigenen Storage
Format Android Bundle (Key-Value-Pairs, binär)
Zugriffsrechte Nur der DPC (Intune Company Portal) darf schreiben; MHS darf nur lesen
Persistenz Bleibt über App-Neustarts erhalten; wird bei Policy-Sync oder Factory Reset aktualisiert
Offline-Verhalten Gerätename wird auch ohne Netzwerkverbindung angezeigt (gecacht)
Update-Zyklus Wird beim nächsten Policy-Sync aktualisiert (~alle 8 Stunden oder manuell)

4. Wo wird der Name nicht gespeichert?

Zur Klarheit – diese Speicherorte werden explizit nicht verwendet:

  • ❌ Nicht im lokalen Android-Gerätenamen (Settings.Global.DEVICE_NAME)
  • ❌ Nicht in einer Datei im MHS-App-Verzeichnis (/data/data/com.microsoft.launcher.enterprise/)
  • ❌ Nicht in einer für den Nutzer zugänglichen Datenbank
  • ✅ Ausschließlich im geschützten Android Managed Configuration Bundle – weder einsehbar noch manipulierbar durch den Endnutzer

Fazit

Der im Managed Home Screen angezeigte Gerätename kommt direkt aus dem Intune Admin Center – übermittelt via App Configuration Policy mit der Variable {{DeviceName}}. Lokal wird er im Android RestrictionsManager-Bundle gecacht: sicher, persistent, offline-fähig und für den Endnutzer weder einsehbar noch veränderbar.

Das macht die Sache für Frontline-Worker-Szenarien besonders praktisch. Egal ob das Gerät gerade online ist oder nicht – der Gerätename wird immer korrekt angezeigt.

Omnissa Sovereign Solution: Das Ende von WS1 On-Premise – und was jetzt auf Kunden zukommt

7. März 2026 / / Keine Kommentare

Omnissa Sovereign Solution: Das Ende von WS1 On-Premise – und was jetzt auf Kunden zukommt

Wer meinen Post zum WS1 vs. Intune Vergleich gelesen hat, wird sich erinnern: Ich hab die Sovereign Solution dort kurz als Option für regulierte Umgebungen erwähnt und einen eigenen Post versprochen. Der Zeitpunkt ist dabei kein Zufall – denn das Thema ist gerade für alle WS1-Kunden und deren Berater hochaktuell. Der Countdown läuft. WS1 On-Premise hat ein Ablaufdatum: 30. April 2027.

In diesem Post gehen wir tiefer. Woher kommt WS1 überhaupt? Was steckt wirklich hinter der Sovereign Solution? Welche Optionen gibt es – und was bedeutet das Ende von On-Premise für Kunden, die aus regulatorischen Gründen nie in eine Public Cloud wollten oder nicht dürfen!? Und die große Frage zum Schluss: Ist das der Anfang vom Ende für Workspace ONE – oder doch ein Neustart?

Spoiler: Meine Einschätzung ist kritisch. Aber der Reihe nach.

Von AirWatch zu Omnissa: Eine kurze Reise durch 20 Jahre UEM

Wer im MDM-Markt unterwegs ist, kennt die Geschichte – aber für alle die sie nicht kennen: AirWatch wurde 2003 gegründet und war spätestens ab 2012/2013 die Referenz im Enterprise-MDM-Markt. 2014 übernahm VMware AirWatch für rund 1,54 Milliarden Dollar – damals eine der teuersten Software-Akquisitionen im EUC-Segment. Daraus entstand Workspace ONE: ein vollintegriertes Digital Workspace-Ökosystem mit MDM, Identity, Conditional Access und App-Management.

Jahrelang war WS1 das Maß der Dinge – besonders im Enterprise-Segment mit komplexen Anforderungen, heterogenen Device-Flotten und strengen Security-Vorgaben. On-Premise war dabei für viele Kunden nicht nur eine Option, sondern eine Notwendigkeit: KRITIS-Unternehmen, Behörden, Banken und Healthcare-Organisationen konnten oder wollten ihre MDM-Infrastruktur schlicht nicht in eine US-amerikanische Public Cloud geben.

Dann kam Broadcom. Im November 2023 schloss Broadcom die VMware-Übernahme für rund 61 Milliarden Dollar ab – und seitdem ist vieles anders. Das VMware EUC-Portfolio (also alles rund um Workspace ONE und Horizon) wurde im Mai 2024 in ein eigenständiges Unternehmen ausgegliedert: Omnissa. Privatgehalten, mit KKR als Hauptinvestor, 4.000 Mitarbeitern und dem klaren Auftrag, das EUC-Portfolio weiterzuführen und zu modernisieren. Klingt erstmal solide – aber der Markt hat das mit gemischten Gefühlen aufgenommen, und das zu Recht.

Der Countdown läuft: WS1 On-Premise End of Support am 30. April 2027

⚠️ Wichtige Deadline: Workspace ONE UEM On-Premises End of Support: 30. April 2027. Letzte installierbare Version: 24.10. Keine Neuentwicklungen – nur noch Security-Patches bis zum Stichtag. Neue On-Premise-Deployments sind nur noch als Ausnahme mit PS-Engagement möglich.

Omnissa hat es offiziell kommuniziert: Die monolithische On-Premise-Architektur von WS1 UEM wird nicht mehr weiterentwickelt. Der Grund ist technischer Natur – und eigentlich nachvollziehbar: Die klassische On-Premise-Architektur ist komplex, wartungsintensiv und inkompatibel mit dem, was Omnissa als strategische Zukunft sieht: den Modern Stack (kurz: ModStack).

Was ist der Modern Stack?

Der ModStack ist eine komplette Neuentwicklung der WS1 UEM-Architektur – weg vom monolithischen Aufbau, hin zu Microservices und Containern. Das bringt echte Vorteile: schnellere Updates, kürzere Release-Zyklen, bessere Skalierbarkeit und – das ist der entscheidende Punkt – Infrastrukturautonomie. Der ModStack kann auf verschiedenen Infrastrukturen laufen, also nicht nur auf einer bestimmten Public Cloud. Genau das ist die technische Grundlage für die Sovereign Solution.

Für On-Premise-Kunden bedeutet das aber auch: Features die im ModStack verfügbar sind – Freestyle Orchestrator, deklaratives Management für Apple, Linux-Support, WS1 Intelligence, DEX – die gibt’s für euch nicht mehr. Wer On-Premise betreibt, fährt ab sofort mit angezogener Handbremse. Keine neuen Features, nur noch Patches bis April 2027.

Was passiert nach dem 30. April 2027?

„End of Support“ heißt: keine Patches mehr, keine Security-Updates, kein Support. Wer dann noch On-Premise betreibt, tut das auf eigenes Risiko – in einer Umgebung ohne Sicherheits-Updates, die täglich verwundbarer wird. Für alle Unternehmen in regulierten Branchen ist das de facto kein tragbarer Zustand.

Der Handlungsdruck ist also real. Und wer glaubt, bis 2027 ist noch Zeit: Migrationsprojekte in Enterprise-Umgebungen mit tausenden Devices, bestehenden Zertifikatsinfrastrukturen, SCEP-Setups und gewachsenen Policy-Strukturen brauchen Zeit. Wer 2026 anfängt, könnte es eng werden.

Die Optionen: Wohin können Kunden migrieren?

Omnissa stellt drei zentrale Wege für den Umstieg bereit. Alle drei basieren auf dem ModStack – der Unterschied liegt in der Hosting-Infrastruktur und dem Datensouveränitätsniveau.

Option 1: Shared SaaS

Das ist die klassische Public-Cloud-Variante. WS1 UEM läuft in der Omnissa-Cloud, mandantenübergreifend auf shared Infrastructure. Günstigste Option, einfachste Migration via Brownfield-Ansatz (bestehende Umgebung wird 1:1 migriert, keine Neu-Enrollments nötig). Für Unternehmen ohne besondere Datensouveränitäts-Anforderungen der schnellste Weg nach vorne.

Aber: Die Daten liegen in einer US-amerikanischen Public Cloud. CLOUD Act. GDPR-Grauzone. Für KRITIS, Behörden und stark regulierte Branchen ein No-Go.

Option 2: Preferred SaaS

Wie Shared SaaS, aber mit dediziertem Tenant. Höhere Isolation, schnellere Performance, keine geteilten Ressourcen mit anderen Kunden. Teurer, aber für Unternehmen interessant, die zwar in die Cloud wollen, aber mehr Kontrolle über ihren Tenant brauchen. An den Datensouveränitäts-Fragen ändert das aber grundsätzlich nichts – die Daten liegen immer noch bei Omnissa in der Public Cloud.

Option 3: Sovereign Solution – der neue Weg für regulierte Umgebungen

Und hier wird’s interessant. Die Omnissa Sovereign Solution für Workspace ONE ist ein partner-gehostetes SaaS-Modell: Ein zertifizierter Omnissa-Partner betreibt die WS1 UEM-Umgebung vollständig auf eigener, lokaler Infrastruktur in privaten Rechenzentren – abgeschirmt von internationalen Public Clouds und damit vom Anwendungsbereich des U.S. CLOUD Act.

Technisch läuft das ganze auf dem ModStack – also moderner SaaS-Architektur, aber eben nicht in einer internationalen Public Cloud. Der Kunde hat direkten Vertrag mit einem lokalen Partner, volle Kontrolle über Datenhaltung und Compliance, und trotzdem alle ModStack-Features. Bring Your Own Key (BYOK) und Desired State Management (DSM) sind direkt integriert.

Wer der oder die aktuellen Partner für die Sovereign Solution in Deutschland und Europa sind, lässt sich mit etwas Recherche schnell herausfinden – ich nenne hier bewusst keine Namen. Warum? Dazu gleich mehr.

ℹ️ Sovereign Solution in Kürze: Partner-gehostetes SaaS | Lokales Rechenzentrum in DE/EU | Volle DSGVO/BDSG-Konformität | Schutz vor U.S. CLOUD Act | BYOK + DSM integriert | ModStack-Architektur | Verfügbar über zertifizierte Omnissa-Partner

Kriterium Shared SaaS Preferred SaaS Sovereign Solution
Hosting Omnissa Public Cloud Omnissa Public Cloud Partner-privates RZ (DE/EU)
Datensouveränität ❌ US-Cloud ❌ US-Cloud ✅ Lokal DE/EU
DSGVO / BDSG ⚠️ Eingeschränkt ⚠️ Eingeschränkt ✅ Vollständig konform
CLOUD Act Risiko ❌ Vorhanden ❌ Vorhanden ✅ Ausgeschlossen
ModStack-Features ✅ Alle ✅ Alle ✅ Alle
BYOK Support ⚠️ Begrenzt ⚠️ Begrenzt ✅ Nativ integriert
Kosten Niedrig Mittel Höher (Partner-Managed)
Für KRITIS geeignet ❌ ❌ ✅
Verfügbarkeit Sofort Sofort Über zertif. Partner (DE/EU)

Migration: Greenfield vs. Brownfield – was bedeutet das in der Praxis?

Für alle, die gerade eine On-Premise-Umgebung betreiben, ist die Migrationsfrage entscheidend. Omnissa unterscheidet zwei Ansätze:

Greenfield: Neuer Tenant, neue Struktur, alles von Grund auf neu aufgebaut. Für große Umgebungen mit viel gewachsenem Tech-Debt eigentlich die sauberere Lösung – aber bedeutet in den meisten Fällen: alle Devices neu enrollen. In einer Umgebung mit 10.000+ Geräten und Nutzern im Schichtbetrieb ist das operativ eine echte Herausforderung.

Brownfield: Die bestehende On-Premise-Umgebung wird 1:1 migriert. URLs, Zertifikate, Datenbankinhalt – alles wird übernommen, kein Re-Enrollment notwendig. Voraussetzung ist ein dedizierter UEM-Tenant. Das ist der bevorzugte Ansatz für bestehende Installationen und in den meisten Enterprise-Projekten die realistischere Option.

Mein Rat aus der Praxis: Fangt jetzt an zu planen. Nicht 2026. Evaluiert eure Umgebung, prüft ob Shared SaaS, Preferred SaaS oder Sovereign Solution für euren Use Case passt, und startet mit einem Proof of Concept. Migrationen dieser Größenordnung haben immer unerwartete Stolpersteine – sei es die Zertifikatsinfrastruktur, bestehende Integrations-Workflows oder schlicht organisatorische Hürden.

Ein Appell an die Berater-Community: Mehr Anbieter, mehr Wettbewerb, mehr Sicherheit

Ich möchte an dieser Stelle einen Punkt ansprechen, der mir persönlich am Herzen liegt – und der über die reine Technologiediskussion hinausgeht.

Die Sovereign Solution ist aktuell ein sehr junges Angebot im Markt. Das bedeutet: Es gibt bisher nur sehr wenige zertifizierte Partner in Deutschland und Europa, die diesen Service anbieten können und wollen. Und das ist – aller technischen Qualität zum Trotz – ein strukturelles Risiko. Wenn ein Modell das auf lokaler, partnerbasierter Infrastruktur aufbaut, de facto von einer Handvoll Anbieter abhängt, dann ist das keine gesunde Marktsituation.

Stellt euch vor: Ein Kunde entscheidet sich für die Sovereign Solution, bindet sich an einen Partner – und dieser Partner ändert seine Strategie, wird übernommen oder stellt den Service ein. Was dann? Die Abhängigkeit wäre mindestens genauso groß wie die, die man durch den Abschied von On-Premise gerade hinter sich lassen wollte.

💡 Mein Appell: Berater, SEs und Systemhäuser in Deutschland und der EU – schaut euch die Omnissa Sovereign Solution genauer an! Das Modell braucht mehr Anbieter. Mehr Wettbewerb bedeutet bessere Preise, mehr Auswahl für Kunden und vor allem: eine resilientere Infrastruktur für einen Markt, der auf Datensouveränität angewiesen ist. Gerade große Systemhäuser mit eigenen Rechenzentren und bestehendem Omnissa-Partnerstatus haben hier eine echte Chance – und eine Verantwortung gegenüber ihren Kunden.

Ich weiß, dass das Investment in Zertifizierung, Infrastruktur und Betrieb nicht trivial ist. Aber der Bedarf ist real, die regulatorischen Anforderungen wachsen, und die Kunden suchen aktiv nach Alternativen zur Public Cloud. Wer jetzt in diesen Markt einsteigt, positioniert sich für die nächsten Jahre. Und das ist – Stand heute – noch eine echte Chance, kein überfüllter Markt.

Die große Frage: Zukunft oder Todesurteil für Workspace ONE?

Jetzt kommt der Teil, für den ich bekannt bin: meine ehrliche, ungeschönte Meinung. Und die ist, um es direkt zu sagen, kritisch-skeptisch.

Was für Omnissa spricht

Technisch ist der ModStack ein echter Fortschritt. Die Microservices-Architektur ist moderner, skalierbarer und flexibler als das, was WS1 On-Premise je war. Die Sovereign Solution ist eine clevere Antwort auf ein reales Marktbedürfnis – gerade in Europa, wo Datensouveränität durch DSGVO, BDSG und den U.S. CLOUD Act ein echtes Thema ist. Und die Tatsache, dass Omnissa beim Gartner Critical Capabilities for Endpoint Management 2026 laut eigenen Angaben top platziert ist, zeigt: technisch ist das Produkt noch konkurrenzfähig.

Dazu kommt: Omnissa ist jetzt eigenständig. Kein großer Broadcom-Konzern der entscheidet, ob EUC-Investment Sinn ergibt oder nicht. Das kann – wenn KKR als Investor langfristig denkt – ein Vorteil sein.

Was mich besorgt – und das ist mehr

Aber dann ist da noch das Broadcom-Erbe. Und das sitzt tief. Die Lizenzstruktur-Änderungen nach der VMware-Übernahme haben viele Kunden und Partner kalt erwischt. Vertrauensverlust ist schwer zu reparieren – das spürt Omnissa bis heute im Markt. Viele Kunden die On-Premise betrieben haben, haben das bewusst gewählt. Nicht nur wegen Datensouveränität, sondern auch weil sie die Kontrolle über ihre Infrastruktur haben wollten. Die werden jetzt in eine SaaS-Abhängigkeit gedrängt – entweder Public Cloud oder Partner-Modell. Das ist eine fundamentale Veränderung in der Kundenbeziehung.

Dann ist da die Frage: Was passiert mit Omnissa selbst? Private Equity als Investor bedeutet in der Regel: Wachstum oder Exit. KKR wird Omnissa irgendwann verkaufen oder an die Börse bringen. Was das für Kunden und das Produkt bedeutet, ist heute nicht absehbar. Wer sich heute für die Sovereign Solution entscheidet, wettet also nicht nur auf die Technologie, sondern auch auf die Kontinuität des Unternehmens dahinter.

Und dann ist da noch der Elefant im Raum: Microsoft Intune. Für alle Kunden, die tief im M365-Stack stecken – und das sind in Deutschland viele – ist Intune heute eine echte Alternative. Nicht für alle Use Cases, nicht für Rugged Devices, nicht für maximale Granularität. Aber für die breite Masse der Standard-Device-Flotten? Intune holt auf, ist günstiger (weil oft schon lizenziert) und hat den Vorteil des vertrauteren Microsoft-Ökosystems.

⚠️ Meine Einschätzung: Die Sovereign Solution ist technisch solide und strategisch sinnvoll – aber das Vertrauen in Omnissa als Unternehmen muss erst noch zurückgewonnen werden. Kunden sollten die Migration nicht als reine Technologieentscheidung betrachten, sondern auch die langfristige Unternehmenskontinuität und die Stabilität des Partner-Ökosystems evaluieren. Wer jetzt migriert, bindet sich an ein junges, privatgehaltenes Unternehmen mit unklarer Eigentümer-Roadmap – und aktuell an einen sehr überschaubaren Kreis von Service-Anbietern.

Ist es das Todesurteil für WS1?

Nein – noch nicht. Aber es ist eine kritische Phase. Workspace ONE hat in spezifischen Segmenten – Rugged Devices, komplexe Multi-OS-Flotten, KRITIS-Umgebungen – nach wie vor keine gleichwertige Alternative. Intune kommt da schlicht nicht ran. Für diese Kunden ist die Sovereign Solution ein Lebenszeichen, kein Schwanengesang.

Für alle anderen – die Standard-Enterprise-Umgebungen mit iOS und Android die sowieso im M365-Ökosystem leben – wird die Abwanderung zu Intune weitergehen. Das ist eine Marktverschiebung die bereits im Gange ist, und die Sovereign Solution wird sie für dieses Segment nicht stoppen.

Mein Fazit: Workspace ONE wird überleben – aber in einer anderen Form und für eine schmalere, spezialisierte Zielgruppe. Die große Frage ist nicht ob WS1 stirbt, sondern ob Omnissa als Unternehmen die Zeit und Ressourcen hat, diesen Wandel erfolgreich zu gestalten. Und ob das Partner-Ökosystem rund um die Sovereign Solution schnell genug wächst, um dem Modell eine echte Marktbasis zu geben. Das liegt letztlich nicht nur an der Technologie.

Was sollten Kunden und Berater jetzt tun?

  • Bestandsaufnahme: Wie viele On-Premise-Deployments habt ihr, in welchen Versionen, mit welchen Integrationen?
  • Regulatorischen Bedarf prüfen: Shared SaaS, Preferred SaaS oder Sovereign Solution – das hängt vom Datenschutzbedarf ab, nicht von der Präferenz.
  • Partner für die Sovereign Solution selbst recherchieren: Ein kurzer Blick in das offizielle Omnissa Partner-Ökosystem reicht – und wer mehrere Anbieter vergleicht, ist besser aufgestellt als wer sich blind auf den ersten einlässt.
  • Migration planen, nicht improvisieren: Brownfield ist der bevorzugte Weg – aber auch der braucht einen dedizierten Tenant, saubere Vorbereitung und ausreichend Zeit.
  • Intune als Alternative ernsthaft evaluieren: Gerade für Unternehmen im M365-Ökosystem ohne KRITIS-Anforderungen ist das kein Tabu mehr – sondern eine legitime strategische Option.
  • Deadline 30. April 2027 nicht unterschätzen: Wer mit einem Security Audit, einer ISO-Zertifizierung oder einer BSI-Prüfung zu tun hat, sollte nicht im März 2027 noch auf einem ungesupporteten System sitzen.
  • An Berater und Systemhäuser: Schaut euch die Möglichkeit an, selbst Sovereign Solution Partner zu werden. Der Markt braucht euch.

Fazit: Ein Neuanfang unter Vorbehalt – und ein Markt der mehr Mitspieler braucht

Die Omnissa Sovereign Solution ist – technisch betrachtet – die richtige Antwort auf ein reales Problem. Datensouveränität ist in der EU kein Marketing-Buzzword mehr, sondern eine rechtliche und operative Notwendigkeit. Dass Omnissa hierfür einen konkreten, partnerbasierten Weg bietet, ist positiv.

Aber das Vertrauen ist angekratzt. Die Broadcom-Ära hat Spuren hinterlassen. Omnissa muss das jetzt durch Kontinuität, transparente Kommunikation und stabile Preismodelle zurückgewinnen. Und das Partner-Ökosystem muss wachsen – schnell. Ein Markt, der auf Datensouveränität setzt, darf nicht selbst in eine neue Abhängigkeit laufen, diesmal von einer Handvoll Service-Anbieter.

Für alle WS1-On-Premise-Kunden und ihre Berater gilt: Die Uhr tickt. April 2027 klingt weit weg, ist es aber nicht. Jetzt ist der Moment, die Strategie zu definieren – nicht zu warten, bis der Support-Ablauf zum operativen Notfall wird.

Ich bin gespannt auf eure Meinungen – gerade von denen die täglich in Kundenprojekten mit WS1 zu tun haben, oder von Beratern und SEs die überlegen, ob die Sovereign Solution für sie als Service-Angebot interessant wäre. Seid ihr Team „Sovereign Solution“, Team „Intune-Migration“ oder habt ihr ganz andere Pläne? Ran an die Kommentare! 😄

Workspace ONE UEM 2602: Ein ehrlicher Überblick zum großen Release

5. März 2026 / / Keine Kommentare

 

Workspace ONE UEM 2602: Ein ehrlicher Überblick zum großen Release

Die 2602er ist eine dieser Releases, bei denen Omnissa sein Selbstvertrauen zeigt – und das ist nicht ganz unbegründet (jeder von uns kennt sehr wahrscheinlich die Probleme der letzten Updates, welche immer so naja liefen Nicht amüsiert ). Mit dieser Version liefern sie eines ihrer ambitioniertesten Updates: vollständig aufgefrischte Admin Experience, innovative Android- und Apple-Management-Fähigkeiten, Game-Changing Windows Management und intelligentere Automation überall.

Lass mich die wichtigsten Punkte durchlaufen.

Feature-Übersichtstabelle: 2602 auf einen Blick

Feature Plattform Kategorie Status
Modernisierte Admin Console Cross-Plattform UI/UX Limited Availability
Phased App Deployments Cross-Plattform Automation GA
Advanced eSIM Management Android Connectivity GA
Erweiterte AMAPI-Policies Android Enterprise Control GA
Account-Driven Enrollment (vereinfacht) iOS/macOS Enrollment GA
Dynamic Mac Hardware Seeding macOS Automation GA
Intelligente Enrollment-Labels iOS/macOS Grouping GA
Intelligent Hub Managed Enrollment Windows Enrollment GA
Enterprise App Repository v2 (EARv2) Windows App Distribution GA
Automatisierte Windows App-Patching Windows App Management GA
Windows Agent Updates Dashboard Windows Visibility GA
Dropship Provisioning Bulk Import Windows Provisioning GA
Intel Chip-to-Cloud Logging Windows Troubleshooting GA
Granular App Retention Control Windows App Lifecycle GA
ADMX Profiles (Windows Server Preview) Windows Server Policy Limited Availability

Die wichtigsten Features im Detail

1. Modernisierte Admin Console – Limited Availability, aber vielversprechend

Omnissa kündigt eine modernisierte Konsole mit intuitiver Navigation, neu gestalteter Device List View und intelligenteren Workflows an, die Klicks reduzieren. Admins können sich schrittweise anmelden und jederzeit zurückwechseln.

Meine Analyse: Das ist nicht einfach eine Kosmetik-Operation. Eine frische Konsolen-UI ist bei MDM-Plattformen überraschend kritisch – die Funktion befindet sich derzeit in Limited Availability , also nicht hastig upgraden. Die Opt-in-Strategie ist smart: Admins können taste, backup-Plan bei Bedarf. Das respektiere ich.

2. Android: eSIM Management & erweiterte AMAPI-Policies

Workspace ONE UEM bietet jetzt fortgeschrittenes eSIM-Management für Android, mit dem IT-Teams die Geräteverbindung optimieren. Administratoren können eSIM-Profile remote bereitstellen, aktivieren, überwachen und entfernen – über die UEM Console oder REST API.

Zusätzlich: Workspace ONE weitet Android AMAPI-Unterstützung mit neuen Policies aus, die granulare Kontrolle über Bildschirmverhalten, Private Space und Google Play Protect bieten.

Praktische Bedeutung: Das ist ein echter Differentiator. eSIM ist nicht sexy, aber für GlobalPlayer mit großen Android-Flotten (Logistics, Telco) = essentiell. Die Private Space Policies sind auch clever – das passt zu Googles Android 15+ Richtung.

3. Apple: Enrollment vereinfacht, Automation kommt

Das Release vereinfacht zwei kritische Apple-Szenarien:

Account-Driven Enrollment (ADE):
Das Release vereinfacht Account-Driven Enrollments erheblich. Früher erforderte die Erstellung einer well-known-Datei manuelle Schritte und externes Hosting. Jetzt aktivieren Admins das Feature, und WS1 generiert die JSON-Datei automatisch via Apple Business Manager.

Mac Hardware Seeding:
Mac-Modell-Hardware-Seeding ist jetzt automatisiert. Mit automatisch erfassten und befüllten Mac-Modelldaten können Admins Smart Groups nutzen – mit Same-Day Support für neue Apple Hardware.

Kritisches Take: Das ist Micro-Automation, aber die Art, die deinen Alltag vereinfacht. Weniger manuelle Datei-Hosting-Fricktion = weniger Fehler = happier Admins. 👍

4. Windows: Das Game-Changer-Release (25+ Features!)

Das ist das Herzstück von 2602. Mit Next-Gen Windows Management in 2602 redefine Omnissa modernes Windows-Management – von Intelligent Hub managed mode über stärkere Desired-State-Controls bis zur verbesserten Enterprise App Repository.

Intelligent Hub Managed Enrollment:
Neue Enrollment-Option namens „Intelligent Hub Managed“ – als Übergangsmechanismus vom alten OMA-DM-Anbieter. Volle Intelligent Hub-Power, aber mit mehr Flexibilität.

Enterprise Application Repository v2 (EARv2):
Ihr könnt jetzt über 8.500 Enterprise-Apps browsen, konfigurieren und an Windows-Geräte pushen – direkt aus WS1 UEM. Noch besser: WS1 kann über 8.500 Apps automatisch patchen. Ihr konfiguriert den Plan einmal – WS1 kümmert sich um den Rest, Apps bleiben aktuell ohne manuelle Intervention.

Unified Application Sampling:
Besseres App-Reporting mit konsistenten Daten. Mit dem neuen Sampling-Framework werden App-Daten einheitlich über Intelligent Hub, UEM und DEX/DEEM erfasst.

Windows Agent Updates Dashboard:
Neues Dashboard für Echtzeit-Sichtbarkeit aller Intelligent Hub & SFD Agentversionen. Zwischen Agenten wechseln, Charts ansehen, zu Device-Listen drilldown – alles from one dashboard.

Intel Chip-to-Cloud Logging:
C2C-Events sind jetzt in dedizierter Log-Datei, ohne unrelated data. AMT-Interface-Aktivierung & Checking verbessert.

Granular App Retention:
Admins steuern jetzt, ob Apps beim Device-Wipe oder App-Unassign entfernt oder behalten werden.

Dropship Provisioning:
Bulk-Import von Geräte-Records – egal ob 1 oder 100 Devices auf einmal.

Meine Analyse: Das ist substantiell. 25+ Windows-Features sind nicht gequetscht, sondern strategisch: DeviceList-Visibility (Admin), App-Automation (Speed), Troubleshooting-Verbesserungen (Ops). EARv2 mit Automatic Patching ist besonders nice – Zero-Touch Patching für 8.500 Apps reduziert MSP-Intervention massiv.

⚠️ Warnung: Windows Server Management ist noch Limited Availability. Wenn ihr auf WS1 für Server-Flotten setzt – noch ein paar Releases warten.

Automation & Workflows: Smarter, nicht komplexer

Mit Phased Deployments könnt ihr Apps schrittweise ausrollen – mit kleiner Gruppe starten, Probleme früh catch, Rest der Fleet schützen. Ziel exakte Assignment Groups in jeder Phase, automatische oder manuelle Phase-Progression, Clear Phase-Level Insights.

Das ist LowCode-Orchestration im Best-Sense: nicht Freestyle, aber simpler als vor 2602.

Handlungsbedarfe & Deprecations: Was ist zu beachten?

⚠️ Console Modernization = Limited Availability

Die neue Admin Console ist noch nicht GA. Testet in Lab/Non-Prod, bevor ihr großflächig rolled. Die Opt-in Strategy ist gut, aber seids vorsichtig mit Critical Workflows.

⚠️ Windows Server = Not Yet Production-Ready

Windows Server Management ist derzeit in Limited Availability mit General Availability demnächst . Wenn ihr Windows Server managed, wartet noch.

⚠️ Apple Migration ohne App Preservation (noch)

WS1 UEM unterstützt derzeit keine App Preservation während Migration. Ihr müsst Apps vorab in WS1 aufsetzen. An diesem Feature wird gearbeitet.

⚠️ Legacy App Catalog Sunset: 30. April 2025

Wechselt zur neuen Enterprise App Repository – Legacy-Path wird deprecated.

Kurzer Vergleich zu Microsoft Intune

Ja, die Frage kommt. Hier meine ehrliche Sicht:

Wo WS1 2602 Intune schlägt:
– Cross-Device Management: Windows + Mac + Android + rugged aus einer Konsole. Intune braucht mehr Basteln.
– eSIM Management: Noch nicht in Intune, WS1 has it. Nice-Feature, aber strategisch.
– ADMX Profiles (kommend): Familiarität für Group Policy Admins.
– Enterprise App Repo (8.500+ Apps): Intune’s Win32 App Management ist granular, aber anstrengender.

Wo Intune Punkte macht:
– Microsoft Ecosystem Integration: Wenn ihr 100% Microsoft-Stack seid, Intune ist built-in.
– Conditional Access: WS1 ist gut, Intune’s AAD-Integration tighter.
– Community & Adoption: Intune-Adoption ist bei SMB größer (aktuell).

Fazit: 2602 macht WS1 für gemischte Umgebungen (Apple + Android + Windows + Rugged) attraktiver. Für rein Microsoft-Shops bleibt Intune einfacher. Für Enterprise Complexity: WS1.

Quellen & offizielle Dokumentation

Microsoft Intune Release 2602: Das ist neu (Woche 2. März 2026)

5. März 2026 / / Keine Kommentare

Microsoft Intune Release 2602: Das ist neu (Woche 2. März 2026)

Moin zusammen,

ich sitze hier gerade vor den Release Notes zur Woche 2. März 2026 – und ehrlich gesagt: Das ist eine Release, die zeigt, wohin die Reise geht. Microsoft macht hier ernsthaft ernst mit Apple’s Declarative Device Management (DDM). Das Legacy-Zeug wird eingestampft, die neuen Features sind gut durchdacht, und das Multi-Admin Approval Feature adressiert endlich ein Problem, das viele von euch im Enterprise haben.

Auch interessant: Autopatch Update Readiness kommt mit echtem Reporting-Zeugs statt nur „lädt gerade Update“ zu zeigen. Das spart euch Zeit beim Troubleshooting.

Lass mich die wichtigsten Punkte durchgehen – und wo ihr aufpassen müsst.

Release-Übersicht: Feature nach Kategorie

Feature Betroffen Kategorie Status
Apple DDM + Assignment Filters iOS, iPadOS, macOS Device Configuration ✅ Neu
Settings Catalog Updates (AirPlay, Defender) iOS, iPadOS, macOS Device Configuration ✅ Erweitert
Multi-Admin Approval für Policies iOS, iPadOS, macOS, Windows Device Management & Security ✅ Neu
Legacy MDM Software Updates deprecated iOS, iPadOS, macOS Device Security ⚠️ Breaking
Protected Apps: Jump, Mijn InPlanning Android App Management ✅ Neu
Autopatch Update Readiness Dashboard Windows Update Management ✅ Neu
Device Query Operators erweitert Alle Monitor & Troubleshoot ✅ Erweitert

Die wichtigsten Features im Detail

1. Apple Declarative Device Management (DDM) mit Assignment Filters 🎯

Das ist die Headline dieser Release.

Was ändert sich?
– Assignment Filters funktionieren jetzt auch mit DDM-basierten Konfigurationen (Software Updates, Policies)
– Bisher war das nur bei Legacy-Policies möglich
– Ermöglicht granulares Targeting: z.B. „Software Updates nur für Devices im Finance-Department mit iOS 24+“

Warum ist das wichtig?

Bei großen Umgebungen brauchst du Granularität. Mit Assignment Filters kannst du jetzt:
– Nach Azure AD Groups filtern
– Nach Device Attributes filtern (Owner Type, OS Version, Location)
– Nach User Attributes filtern

Praxisbeispiel:

Device Configuration → Create Policy (DDM-based)
→ Assign → Add Assignment Filter
→ "iOS >= 25 AND Department = Engineering"

Das reduziert Rollout-Komplexität erheblich – vor allem wenn ihr mehrere tenants oder heterogene Environments habt.

Gilt für: iOS/iPadOS, macOS

2. ⚠️ WARNUNG: Legacy Apple MDM Software Update Policies werden deprecated 🚨

Das ist wichtig. Sehr wichtig.

Microsoft und Apple beenden Support für die alten MDM Software Update Commands mit iOS 26, iPadOS 26 und macOS 26. Das bedeutet:

  • Legacy-Policies (die ihr vermutlich heute noch nutzt) funktionieren in Kürze nicht mehr
  • Apple hat diese alten Payloads aus dem MDM-Spec rausgenommen
  • Action Item für euch: Migration zu DDM-based Software Updates erforderlich

Was müsst ihr machen?

  1. Audit: Welche Legacy-Policies habt ihr aktuell deployed?
  2. Planning: Welche Geräte sind noch auf iOS < 25 / macOS < 25?
  3. Rollout: DDM Software Update Policies neu erstellen und testen
  4. Sunset: Legacy Policies systematisch deaktivieren

Zeitrahmen? Microsoft nennt kein genaues Datum, aber „soon“ ist im Tech-Speak nicht mehr fern. Ich würde Q2-Q3 2026 kalkulieren.

Ressource: Schaut euch den Intune Customer Success Blog an – da wird’s detailliert erklärt.

3. Multi-Administrator Approval für Device Configuration & Compliance Policies 👥

Das ist ein Security-Feature, das lange überfällig war.

Was ändert sich?
– Dual-Authorization für Policy-Änderungen ist jetzt auch für Settings Catalog Policies möglich
– Vorher war das nur für Compliance Policies relevant
– Jede Änderung (Create, Edit, Delete) muss von Admin #2 genehmigt werden

Warum?
– Verhindert versehentliche Breaking Changes (z.B. falsch konfigurierte VPN-Policies)
– Schützt vor Malicious Actions durch compromised Admin-Accounts
– Audit Trail für Compliance-Reviews (SOC 2, ISO 27001, etc.)

Wo stellt ihr das ein?

Intune Admin Center
→ Devices → Device Configuration oder Compliance
→ Create Policy
→ Policies (unter Access policies)
→ Require Multi Admin Approval: ON

Praktischer Hinweis: Das wird euer Change-Management verlangsamen. Ein Policy-Update dauert dann länger. Aber der Security Gewinn ist es wert – vor allem in Enterprise-Umgebungen.

Gilt für: iOS, iPadOS, macOS, Android, Windows

4. Settings Catalog Updates: AirPlay & Microsoft Defender 🎨

Microsoft hat die Settings Catalog (das zentrale Policy-Management-Tool) erweitert.

Neue Settings:

Setting Platform Use Case
AirPlay → Device Name iOS, iPadOS, macOS Custom Device-Naming für AirPlay
Microsoft Defender → Neue Policies macOS Advanced Threat Protection Config

Das klingt marginal, aber für Environments die AirPlay oder Defender managed endpoints haben: Jetzt könnt ihr das via Policy zentralisiert steuern statt manuell auf jedem Device.

Für macOS-Defender: Besonders interessant für Security Teams, die Microsoft Defender als Standard-AV eingerollt haben. Mehr Policy-Control = bessere Compliance.

5. Autopatch Update Readiness Dashboard 📊

Das ist für Windows-Teams ein großes Ding.

Was ist neu?
– Unified Dashboard für Update-Readiness (Intune + Windows Autopatch)
– Device Update Journey: Granulare Status pro Gerät
– Centralized Alerting: Failures, Policy Conflicts, Readiness Gaps
– Update Readiness Checker: Proaktive Risk-Evaluation
– OS Reinstall Trigger: Automatisches Remediating bei Blockern (z.B. Disk Space)

Konkret:

Autopatch Dashboard
→ Update Status: "In Progress" / "Failed" / "At Risk"
→ Reason: "Insufficient disk space (22 GB free, 30 GB required)"
→ Remediation: "Trigger OS reinstall" (mit Alerts & Reporting)

Wofür nutze ich das?
– Pre-Deployment Risk Assessment
– Quick Troubleshooting (warum stockt das Update?)
– Proactive Device Remediation

Das spart euch echte Stunden bei größeren Updates.

6. Protected Apps: Jump & Mijn InPlanning 📱

Zwei neue Apps sind jetzt auf der Intune Protected Apps Liste.

Jump by Accio Inc. – Scheduling/Planning App
Mijn InPlanning by Intus Workforce Solutions – Workforce Planning (Android)

Das bedeutet: Diese Apps kriegen automatisch Mobile App Protection Policies (MAMP) angeboten:
– Biometric Lock
– Data Encryption
– Clipboard Restrictions
– etc.

Relevant, wenn ihr diese Tools deployed und data protection braucht.

7. Device Query Operators – Erweiterte Abfragen 🔍

Für die Admin-Power-User da draußen:

Neue Join Types:
– leftsemi, rightsemi, leftanti, rightanti

Breaking Changes:
– on Device.DeviceId wird nicht mehr unterstützt → nutzt stattdessen on Device
– Device allein in distinct, summarize, order by geht nicht mehr → specific properties required

Bessere Error Messages + Devices als clickable Links in Query Results

Das ist ein UX-Upgrade für euer Troubleshooting, aber Achtung: Falls ihr custom KQL-Queries gebaut habt, müssen die angepasst werden.

Handlungsbedarfe & Warnungen 🚨

1. Legacy iOS/macOS Software Updates – Migration erforderlich

Item Details
Was? Legacy MDM Software Update Policies
Deadline Unklar, aber „soon“ – rechne Q2-Q3 2026
Action Audit + Rollout zu DDM-based Policies
Impact Breaking Change für iOS/macOS Updates

Meine Empfehlung: Startet noch diesen Monat mit der Audit & Test-Phase. DDM ist die Zukunft – besser proaktiv als reaktiv migrieren.

2. Multi-Admin Approval Performance-Impact

Wenn ihr das Feature enablet:
– Policy-Rollouts werden langsamer (Genehmigung erforderlich)
– Notfall-Changes brauchen schnelle Admin-Koordination

Lösung: Separate Approval-Policies für kritische vs. Standard-Changes einplanen.

3. Device Query Syntax-Änderungen

Falls ihr custom Queries nutzt:
– Alt: on Device.DeviceId → Neu: on Device
– Test eure Queries gegen die neuen Anforderungen

Fazit & Meine persönliche Einschätzung 💭

Diese Release ist solid und forward-looking. Drei Dinge fallen mir auf:

  1. Microsoft stellt Apple Legacy-Zeug konsequent ab – Das ist richtig. DDM ist moderner, sicherer, zuverlässiger. Wer noch auf Legacy-Policies läuft: Wake up call. Migration sollte jetzt starten.
  2. Multi-Admin Approval ist Enterprise-ready – Das Feature adressiert echte Security-Anforderungen. In großen Umgebungen unverzichtbar.
  3. Autopatch Update Readiness ist praktisch – Endlich echtes Troubleshooting-Tooling statt „lädt gerade“. Time Saver.

Quellenlinks

Intune Managed Home Screen: Neue RBAC-Permissions – kleines Feature, große Wirkung

4. März 2026 / / Keine Kommentare

Intune Managed Home Screen: Neue RBAC-Permissions – kleines Feature, große Wirkung

Manchmal sind es die kleinen Änderungen, die im Alltag den größten Unterschied machen. Microsoft hat mit dem Intune Februar-Release (2602) zwei neue RBAC-Permissions für den Managed Home Screen eingeführt:

TemporarilySuspendManagedHomeScreen | RestoreManagedHomeScreen

Klingt erstmal technisch und unspektakulär. Ist es aber nicht. Wer schon mal versucht hat, einen Android-Kiosk in einer Schule oder im Frontline-Worker-Umfeld zu supporten, ohne lokalen Admin-Zugriff aufs Gerät zu haben, wird beim Lesen dieser Zeilen vielleicht kurz aufatmen. Warum? Das erkläre ich hier.

Kurzer Auffrischungskurs: Was ist eigentlich der Managed Home Screen?

Für alle die noch nicht täglich mit Android-Enterprise-Deployments zu tun haben: Der Microsoft Managed Home Screen (kurz MHS) ist eine App aus dem Managed Google Play Store, die Microsoft Intune als Standard-Launcher für Android-Kiosk-Geräte verwendet.

Das bedeutet konkret: Statt dem normalen Android-Homescreen sieht der Nutzer nur das, was der Admin ihm erlaubt. Welche Apps, welche Einstellungen, welche Widgets – alles zentral gesteuert. MHS läuft dabei typischerweise auf:

  • Android Enterprise Dedicated Devices (Corporate-owned, kein User-Account) – klassisch für Kiosk, Shared Devices, Info-Terminals
  • Fully Managed Devices (Corporate-owned, user-affiliated) – z.B. Frontline Worker, Schüler-Tablets, Lagermitarbeiter

Der Vorteil ist klar: Kein Nutzer kommt aus dem Kiosk raus, installiert irgendwas, oder ändert die WLAN-Einstellungen. Das Gerät macht was es soll – und sonst nichts.

ℹ️ MHS in Kürze: Intune-verwalteter Android-Launcher | Kiosk-Modus für Dedicated & Fully Managed Devices | Konfigurierbar via App Configuration Policies oder Device Configuration Profiles | Unterstützt Android Enterprise ab OS 8.0 | Beliebt in Schulen, Logistik, Healthcare und Retail

Das Problem: Kiosk ist super – bis jemand Support braucht

Kiosk-Geräte sind im laufenden Betrieb wunderbar. Aber dann kommt der Moment, wo etwas nicht funktioniert. Eine App hängt sich auf, eine Policy greift nicht, das Gerät braucht ein Update das sich im Lock-Down nicht automatisch installiert. Oder – klassischer Schulkontext – ein Schüler hat irgendwas Kreatives angestellt und das Gerät verhält sich komisch.

Vor den neuen Permissions war die Situation für Help Desk Operators und Schuladmins in solchen Momenten nicht schön. Um aus dem MHS-Kiosk rauszukommen und auf die normale Android-Oberfläche zugreifen zu können, gab es im Wesentlichen drei Wege:

  • Den Kiosk-Exit-PIN verwenden – sofern konfiguriert und dem Supporter bekannt
  • Den Debug-Modus über das 15-malige Zurück-Drücken aktivieren – undurchsichtig, nutzerfeindlich, nicht skalierbar
  • Einen vollwertigen Intune-Admin einschalten – weil nur der die nötigen Berechtigungen hatte

Für große Organisationen mit vielen Geräten und einem gestaffelten Support-Modell (Tier 1 / Tier 2 / Tier 3) ist das ein echtes Problem. Ein Help Desk Operator der in einer Schule 300 iPads und 200 Android-Kiosks supportet, braucht operative Handlungsfähigkeit – ohne dass man ihm gleich globale Admin-Rechte geben will. Genau hier setzen die neuen Permissions an.

Die zwei neuen RBAC-Permissions im Detail

TemporarilySuspendManagedHomeScreen – Kiosk kurz auf Pause

Mit dieser Permission kann ein berechtigter Admin den Managed Home Screen vorübergehend aussetzen. Das Gerät verlässt damit den Kiosk-Modus und gibt temporär Zugriff auf die normale Android-Oberfläche – ohne dass der Kiosk dauerhaft deaktiviert wird oder irgendwas an der Konfiguration geändert werden muss.

Was das in der Praxis bedeutet: Der Help Desk kann aus der Ferne – oder direkt am Gerät via Intune Remote Action – den Kiosk kurz „parken“, das Problem lösen (App-Cache leeren, Update erzwingen, Einstellungen prüfen), und danach den MHS-Kiosk wieder aktivieren. Sauber, kontrolliert, ohne Admin-Eskalation.

💡 Praxisbeispiel Schule: Schüler-Tablet in Klasse 7b verhält sich komisch – App startet nicht, Lehrer ruft Support. Help Desk Operator suspendiert remote den MHS, sieht auf die vollständige Android-Oberfläche, stellt das Problem fest (abgelaufene App-Version), triggert ein Sync, aktiviert MHS wieder. Dauer: 5 Minuten. Ohne diese Permission: IT-Admin-Eskalation, Ticket-Ping-Pong, ggf. Gerät einschicken.

RestoreManagedHomeScreen – zurück in den Kiosk

Das ist die Gegenseite. Nachdem der MHS temporär suspendiert wurde, stellt diese Permission sicher, dass der Help Desk Operator den Kiosk-Modus wieder aktivieren kann – ohne auf einen vollständigen Intune-Admin angewiesen zu sein.

Das ist wichtiger als es klingt. Ein Suspend ohne kontrollierten Restore ist in einer Kiosk-Umgebung ein Sicherheitsrisiko. Ein Gerät das „aus Versehen“ dauerhaft aus dem Kiosk ist, ist im Schulkontext oder im Retail-Einsatz schnell ein Problem. Mit RestoreManagedHomeScreen hat der Help Desk die volle Kontrolle über den gesamten Suspend/Restore-Zyklus.

ℹ️ Wichtig: Die beiden Permissions sind als Paar gedacht. TemporarilySuspend ohne Restore ergibt keinen sicheren Support-Workflow. Microsoft hat sie deshalb auch gemeinsam in die Built-in-Rollen aufgenommen.

Wer bekommt die neuen Permissions – und warum genau diese Rollen?

Microsoft hat die beiden Permissions mit dem Februar-Release (2602) automatisch in zwei bestehende Built-in-Rollen integriert:

RBAC-Rolle Bisherige Kernaufgaben Neu hinzukommend
Help Desk Operator Remote-Tasks (Wipe, Lock, Retire), App/Policy-Zuweisung, User-Support TemporarilySuspend + RestoreManagedHomeScreen
School Administrator Apps & Settings für Gruppen, Remote-Lock/Restart/Retire, Intune for Education TemporarilySuspend + RestoreManagedHomeScreen

Die Wahl dieser beiden Rollen ist nicht zufällig. Der Help Desk Operator ist die typische Tier-1-bis-Tier-2-Support-Rolle in Unternehmen mit MHS-Deployments – Retail, Logistik, Healthcare, Frontline Worker. Und der School Administrator ist die dedizierte Rolle für Intune for Education-Umgebungen, wo Kiosk-Tablets und Shared Devices allgegenwärtig sind.

Beide Rollen haben gemeinsam, dass sie operativ nah an den Geräten dran sind – aber eben nicht die volle Intune-Admin-Power haben sollen. Genau deshalb macht es Sinn, ihnen die MHS-Suspend/Restore-Kontrolle zu geben: genug Handlungsspielraum für den Daily Support, ohne sicherheitskritische Berechtigungen wie Policy-Erstellung oder Enrollment-Management zu öffnen.

Kurzer RBAC-Exkurs: Warum das Prinzip so wichtig ist

Role-Based Access Control (RBAC) ist in Intune das zentrale Berechtigungsmodell. Statt jedem Admin die gleichen Rechte zu geben, definiert man Rollen mit klar begrenzten Berechtigungen – und weist diese Rollen dann an spezifische Personen oder Gruppen zu. Das Prinzip dahinter: Least Privilege – jeder bekommt genau die Rechte, die er für seine Aufgabe braucht. Nicht mehr, nicht weniger.

Microsoft empfiehlt ausdrücklich, für den täglichen Betrieb auf Built-in-Rollen zu setzen und Microsoft Entra ID-Rollen (die oft zu viel Zugriff haben) nicht als Standard-Admin-Rollen zu verwenden. Die neuen MHS-Permissions sind ein gutes Beispiel für diese Philosophie in der Praxis: Eine Aufgabe (Kiosk suspendieren) bekommt eine dedizierte Permission, die gezielt an die richtigen Rollen vergeben werden kann.

RBAC-Konzept Bedeutung für MHS-Deployments
Least Privilege Help Desk kann Kiosk managen ohne globale Admin-Rechte
Built-in Roles School Admin + Help Desk Operator bekommen die Permissions automatisch
Custom Roles Granulare Vergabe möglich: z.B. nur RestoreManagedHomeScreen ohne Suspend
Scope Tags Permissions können auf bestimmte Gerätegruppen oder Standorte begrenzt werden

Für Organisationen die Custom RBAC-Rollen nutzen: Die neuen Permissions können auch gezielt einzeln vergeben werden. Wer zum Beispiel einen noch engeren Tier-1-Support nur mit Restore-Recht ausstatten will (um zu verhindern dass jemand den Kiosk unberechtigt suspendiert), kann das über eine Custom Role abbilden.

Wie funktioniert das technisch – was passiert beim Suspend?

Wenn TemporarilySuspendManagedHomeScreen ausgelöst wird, passiert folgendes auf dem Gerät:

  • Der Managed Home Screen-Launcher gibt die Steuerung temporär ab
  • Das Android-System zeigt wieder den Standard-Launcher (oder einen anderen konfigurierten Launcher)
  • Der Nutzer/Admin hat Zugriff auf die vollständige Android-Oberfläche, System-Settings und alle installierten Apps
  • Die MHS-Konfiguration, Policies und App-Zuweisungen bleiben dabei vollständig erhalten – es wird nichts gelöscht oder geändert
  • Per RestoreManagedHomeScreen wird MHS wieder als aktiver Launcher gesetzt – der Kiosk-Modus ist sofort wiederhergestellt

Das ist der entscheidende Unterschied zur bisherigen „Exit Kiosk Mode“-Funktionalität über das Debug-Menü: Die neuen Permissions erlauben eine saubere, remote-auslösbare, auditierbare Aktion – keine Workarounds, kein manuelles Rumdrücken am Gerät, keine PIN-Weitergabe.

⚠️ Zu beachten: Die Suspend-Aktion gibt dem Nutzer temporär Vollzugriff auf das Android-System. In sensiblen Umgebungen (z.B. Healthcare, KRITIS) sollte der Suspend-Workflow dokumentiert und per Scope Tags auf berechtigte Admins begrenzt sein. Ein unbeaufsichtigtes Gerät im Suspend-Zustand ist de facto aus dem Kiosk – das sollte nicht dauerhafter Zustand sein.

Die konkreten Vorteile für den Admin-Alltag

1. Eskalationen werden seltener

Der häufigste Support-Aufwand bei MHS-Deployments ist die Kiosk-Intervention: Gerät hängt, App macht nicht mit, Update ist blockiert. Bisher musste in vielen Szenarien ein Intune-Admin eingreifen. Mit den neuen Permissions kann der Help Desk das selbst lösen – weniger Tickets, kürzere Lösungszeiten, weniger frustrierte Lehrer oder Schichtleiter.

2. Kein PIN-Sharing mehr

Die bisherige „Exit Kiosk“-Methode via Kiosk-PIN war ein Sicherheitsproblem in der Praxis: Entweder kannte der Help Desk den PIN nicht, oder er wurde geteilt und damit zum Sicherheitsrisiko. Mit den RBAC-Permissions ist das obsolet. Kein Pin-Sharing, kein Post-it an der Unterseite des Tablets. Die Aktion ist an die Rolle gebunden, nicht an ein Shared Secret.

3. Vollständige Auditierbarkeit

RBAC-Aktionen in Intune werden geloggt. Wer den MHS suspendiert hat, wann, auf welchem Gerät – das ist alles in den Intune-Audit-Logs nachvollziehbar. Für Compliance-Reports, ISO-Zertifizierungen oder einfach nur für den internen Überblick ist das ein echter Mehrwert gegenüber dem bisherigen PIN-basierten Zugang.

4. Kein Sicherheits-Downgrade nötig

Bisher war die pragmatische Lösung in manchen Organisationen: Help-Desk-Mitarbeitern mehr Intune-Rechte geben als eigentlich nötig, damit sie Kiosk-Probleme lösen können. Das ist klassisches Permission Creep – und ein Risiko. Die neuen granularen Permissions erlauben es, genau das zu vermeiden: Der Help Desk Operator bekommt MHS-Suspend-Rechte, aber eben keine Policy-Erstellungs- oder Enrollment-Rechte.

5. Perfekt für Schul- und Frontline-Umgebungen

Genau die Szenarien wo MHS am meisten eingesetzt wird – Schulen, Retail, Logistik, Healthcare – sind auch die Szenarien mit dem höchsten Support-Aufkommen und dem geringsten Admin-Personal vor Ort. Ein Schulleiter oder Schichtverantwortlicher mit Help-Desk-Operator-Rolle kann jetzt selbst eingreifen, ohne auf den zentralen IT-Admin warten zu müssen. Das ist in der Praxis ein erheblicher Effizienzgewinn.

Was müssen Admins jetzt tun?

Microsoft hat das klar kommuniziert: Es ist keine Admin-Aktion erforderlich. Die Permissions werden automatisch den Built-in-Rollen hinzugefügt. Aber „kein Handlungsbedarf“ heißt nicht „kein Nachdenken erforderlich“. Hier die Empfehlungen:

  • Rolle-Assignments reviewen: Wer hat bei euch die School Administrator- oder Help Desk Operator-Rolle zugewiesen bekommen? Diese Personen bekommen die neuen Permissions automatisch. Ist das in allen Fällen gewollt?
  • Dokumentation aktualisieren: Wenn ihr interne IT-Handbücher, Schulungsunterlagen oder SOPs für den Kiosk-Support habt, müssen diese aktualisiert werden. Der neue Workflow via Suspend/Restore sollte dokumentiert und kommuniziert sein.
  • Custom Roles prüfen: Wer Custom RBAC-Rollen nutzt, kann die neuen Permissions manuell hinzufügen – oder bewusst weglassen, wenn der engste Least-Privilege-Ansatz gewünscht ist.
  • Scope Tags einsetzen: Besonders in großen Organisationen mit verteilten Standorten: Scope Tags sicherstellen, dass Help Desk Operators nur die Geräte suspendieren können, für die sie auch zuständig sind.
  • Auslöser in Intune kennenlernen: Die Aktion wird in der Intune Admin Console als Remote Action auf dem Gerät auslösbar sein – ähnlich wie Remote Lock oder Sync. Den genauen Workflow für das eigene Team einmal durchspielen bevor es der erste echte Support-Fall erfordert.

Fazit: Klein, aber fein – und überfällig

TemporarilySuspendManagedHomeScreen und RestoreManagedHomeScreen sind keine Features die auf Konferenzen mit großem Tamtam vorgestellt werden. Aber für jeden der täglich MHS-Deployments in Schulen, im Frontline-Worker-Umfeld oder im Kiosk-Betrieb supporten muss, sind sie ein echter Lebensverbesserer.

Das Prinzip dahinter ist einfach und richtig: Wer Support machen darf, soll auch die Werkzeuge haben, um guten Support machen zu können – ohne dafür einen sicherheitskritischen Permission-Overhead zu bekommen. Granulares RBAC ist genau dafür gemacht. Und Microsoft setzt das hier konsequent um.

Wer schon MHS im Einsatz hat: Jetzt ist ein guter Zeitpunkt, die Role Assignments zu reviewen und den Suspend/Restore-Workflow in den internen Support-Prozess aufzunehmen. Und wer noch überlegt, MHS für ein Kiosk-Deployment einzusetzen: Diese Verbesserung macht es noch attraktiver – gerade wenn kein dediziertes Vor-Ort-Admin-Team zur Verfügung steht.

💡 Mein Fazit: Kleine Permissions, große Wirkung. Wer 100+ Kiosk-Geräte ohne dediziertes Admin-Team vor Ort supportet, wird diese Änderung lieben. Der Help Desk kann jetzt genau das tun, wofür er da ist – Probleme lösen – ohne bei jedem Kiosk-Issue einen Global Admin klingeln zu müssen.

🔗 Quellen & weiterführende Links:

• M365 Admin – Originalmeldung MC1213781: m365admin.handsontek.net

• Microsoft Learn – Configure Managed Home Screen App: learn.microsoft.com/intune/apps/app-configuration-managed-home-screen-app

• Microsoft Learn – RBAC with Microsoft Intune: learn.microsoft.com/intune/fundamentals/role-based-access-control

• Microsoft Tech Community – MHS Setup Guide (Kiosk Mode): techcommunity.microsoft.com

• Systunation – The Incredible Managed Home Screen: systunation.com/the-incredible-managed-home-screen-mhs-of-intune

iPhone & iPad für NATO-Verschlusssachen zugelassen: Was steckt wirklich hinter der Indigo-Zertifizierung?

2. März 2026 / / Keine Kommentare

iPhone & iPad für NATO-Verschlusssachen zugelassen: Was steckt wirklich hinter der Indigo-Zertifizierung?

In einem LinkedIn-Post am Wochenende bin ich auf diese Info gestoßen – und hab das Ganze direkt mal näher beleuchtet. Was ich da gelesen hab, ist tatsächlich ziemlich bemerkenswert. Also fangen wir mal von vorne an.

26. Februar 2026. Apple veröffentlicht eine Pressemitteilung, die in der MDM- und Security-Community sofort die Runde macht: iPhone und iPad sind die ersten – und bislang einzigen – Consumer-Endgeräte weltweit, die für den Umgang mit vertraulichen NATO-Informationen zugelassen sind. Keine Zusatz-Software. Keine Spezial-Hardware. Das Ding in deiner Hosentasche – ab sofort offiziell NATO-tauglich.

Als jemand der seit Jahren im Mobile Device Management unterwegs ist und täglich iOS-Deployments in Enterprise- und Behördenumgebungen begleitet, hat mich diese Nachricht aufhorchen lassen. Nicht wegen des Apple-Marketing-Texts – der ist erwartungsgemäß vollmundig – sondern wegen dem, was technisch dahintersteckt und was es für unsere Branche bedeutet.

In diesem Post schaue ich mir an, was die Indigo-Konfiguration wirklich ist, was das technisch und operativ bedeutet, wo die echten Chancen liegen – und wo ich als MDM-Praktiker trotzdem kritisch nachfragen würde.

Was ist passiert? Die Fakten auf den Punkt

ℹ️ Das Wichtigste in Kürze: iPhone und iPad mit iOS 26 / iPadOS 26 sind im NATO Information Assurance Product Catalogue (NIAPC) gelistet. Zertifizierungsstufe: NATO RESTRICTED – also „Nur für den Dienstgebrauch“. Keine Zusatz-Software nötig, nur MDM-Verwaltung im Supervised Mode. Technische Bewertung und Freigabe durch das BSI (Deutschland). Bezeichnung der Konfiguration: Indigo.

Die NATO hat eine Produktkategorie namens NATO RESTRICTED – das ist die unterste von vier NATO-Geheimhaltungsstufen. Darüber liegen NATO CONFIDENTIAL, NATO SECRET und COSMIC TOP SECRET. Wir reden also nicht über Atomwaffen-Codes auf dem iPhone 😄 – aber NATO RESTRICTED ist trotzdem eine staatlich anerkannte Sicherheitsstufe mit echten operativen Informationen in Militär, Behörden und Sicherheitsorganisationen. Und für die war bis heute kein Consumer-Device zugelassen – zumindest nicht ohne Sondersoftware, die es in der Vergangenheit gab und auch noch gibt. Aber die brachte immer einen riesigen Impact auf Budgetplanung und Administration mit. Halt: unsexy.

Die Grundlage für die NATO-Zertifizierung legte das BSI: Das Bundesamt für Sicherheit in der Informationstechnik hatte iOS und iPadOS bereits zuvor für die Verarbeitung von VS-NfD (Verschlusssache – Nur für den Dienstgebrauch) freigegeben – dem deutschen Äquivalent zu NATO RESTRICTED. Auf Basis dieser gründlichen Prüfung wurde die Zertifizierung auf alle 32 NATO-Mitgliedsstaaten ausgeweitet. Ab sofort sind iPhone und iPad mit iOS 26 und iPadOS 26 in allen NATO-Staaten offiziell zertifiziert.

Die Indigo-Konfiguration: Was steckt technisch dahinter?

„Indigo“ klingt nach einem speziellen Government-Fork von iOS – so eine Art geheimes Geheimdienstbetriebssystem. Ist es aber nicht. Apple hat das explizit klargestellt, und der offizielle NIAPC-Eintrag bestätigt es: Indigo ist kein separates OS, kein Custom-Build, kein proprietäres Sicherheits-Layer. Es ist schlicht der Name, den das BSI der Standard-iOS-Konfiguration im Rahmen seiner Sicherheitsevaluierung gegeben hat.

Was die Indigo-Konfiguration konkret ausmacht, ist im NIAPC-Eintrag offiziell dokumentiert. Ich übersetze das mal aus dem Behörden-Englisch ins IT-Deutsch:

Apple Silicon – die Hardware-Basis

Der Apple Silicon Chip arbeitet nahtlos mit iOS und iPadOS zusammen und liefert Security-Features direkt auf Hardware-Ebene. Die Secure Enclave ist dabei der Kern: Sie verschlüsselt und schützt User- und biometrische Daten und setzt Passcode-Policies direkt in Hardware durch – ohne dass das OS selbst überhaupt Zugriff auf die Schlüssel hat. Das ist eine fundamentale Architekturentscheidung, die Apple vom Wettbewerb unterscheidet – und die man nicht einfach per Software nachrüsten kann.

Touch ID und Face ID – mehr als nur Komfort

Biometrische Authentifizierung über Face ID oder Touch ID – schnell, sicher, ohne Passwort-Overhead. Im Enterprise- und Behördenkontext ist das besonders relevant, weil es den ewigen Security-Usability-Konflikt löst: Keine Post-its mit Passwörtern unter der Tastatur, keine „Passwort vergessen“-Tickets, kein Shoulder-Surfing im Großraumbüro. Und das Beste: Die biometrischen Daten verlassen nie die Secure Enclave – nicht mal Apple selbst hat darauf Zugriff.

Memory Integrity Enforcement (MIE) – das eigentliche Highlight

Das ist das Feature, das mich beim Lesen des NIAPC-Eintrags am meisten aufhorchen ließ. MIE kombiniert Apple Silicon Hardware mit fortschrittlicher OS-Security und liefert laut Apple „always-on memory safety für Geräte mit A19 und M5 Prozessoren“ – ohne Performance-Impact. Der offizielle NIAPC-Eintrag bezeichnet es als den größten Fortschritt in der Memory Safety für Consumer-Betriebssysteme überhaupt. Und das ist keine leere Marketingaussage.

Was MIE in der Praxis bedeutet: Klassische Speicherangriffe – Buffer Overflows, Use-After-Free, Return-Oriented Programming – werden auf Hardware-Ebene blockiert, bevor sie überhaupt zur Software-Schicht gelangen. Das klingt technisch, hat aber eine ganz einfache Konsequenz: Eine ganze Klasse von Angriffen, für die es in der Vergangenheit aufwendige Software-Patches brauchte, existiert auf diesen Geräten schlicht nicht mehr. Das ist der Grund, warum der NIAPC-Eintrag explizit A19- und M5-Geräte hervorhebt.

⚠️ Wichtig für die Praxis: MIE ist ausschließlich auf Geräten mit A19- und M5-Chip verfügbar – also der aktuellen iPhone 17-Serie und den neuesten iPad Pro/Air Modellen. Ältere Geräte fallen zwar unter iOS 26 und sind formal unter die Zertifizierung gefasst, erreichen aber nicht das gleiche Memory-Safety-Level. Wer sicherheitskritische Deployments plant, sollte das bei der Gerätebeschaffung berücksichtigen.

VPN und Secure Networking – kein Extra nötig

Apple Devices unterstützen VPN nativ – ohne Zusatz-App, ohne proprietären Client. iOS und iPadOS arbeiten direkt mit IKEv2, Cisco IPsec und L2TP over IPsec zusammen. Das stellt sicher, dass Daten auf dem Transportweg verschlüsselt bleiben – auch wenn die verwendete App selbst keine eigene Verschlüsselung mitbringt. Für Behörden, die ohnehin auf VPN-Infrastruktur setzen: nahtlose Integration, kein Mehraufwand.

Was die Konfiguration konkret verlangt – der MDM-Part

Und hier kommen wir zum entscheidenden operativen Punkt. Der NIAPC-Eintrag ist eindeutig: Indigo erfordert keine spezielle Zusatz-Software oder besondere Einstellungen – aber die Geräte müssen per MDM verwaltet und in den Supervised Mode versetzt werden. Kein Supervised Mode, keine Indigo-Zertifizierung. So einfach ist das.

Freigegebene Anwendungen in der Indigo-Konfiguration: Mail, Kalender und Kontakte – mit den nativen Apple-Apps. Genau die Kern-Tools des täglichen Dienstbetriebs. Keine Custom-App, kein proprietärer Mailclient. Die Standard-Apps reichen.

Die echten Vorteile – warum das mehr als Marketing ist

Security by Design – endlich offiziell bestätigt

Apple argumentiert seit Jahren: echte Sicherheit muss von Anfang an ins Produkt integriert sein. Kein nachträglicher Security-Layer, keine Compliance-Krücke. Schön und gut – das behaupten viele Hersteller. Aber das BSI ist keine Institution, die Zertifizierungen leichtfertig vergibt. Wenn das BSI nach umfassender technischer Prüfung bestätigt, dass Standard-iOS für VS-NfD geeignet ist, dann ist das eine fundierte, unabhängige Aussage – kein Gefälligkeitsgutachten.

Kein Sonderbau mehr – Standard-Hardware für klassifizierte Umgebungen

Das ist wohl der größte Paradigmenwechsel. Bislang brauchten Behörden für klassifizierte Informationen speziell gehärtete Devices – teuer, schwer zu updaten, operativ unbequem und – wie schon erwähnt – halt unsexy. Das iPhone ist jetzt ab Werk NATO-tauglich. Das senkt Beschaffungskosten dramatisch, vereinfacht das Lifecycle-Management und löst ein ganz praktisches Problem: Mitarbeiter schleppen keine zwei Geräte mehr mit sich rum.

MDM als zentraler Sicherheitsmechanismus – starkes Signal für die Branche

Aus meiner MDM-Perspektive ist das ein echtes Statement: Die einzige technische Voraussetzung für die NATO-Zertifizierung ist Supervised Mode via MDM. Kein weiterer proprietärer Layer, kein spezieller Security-Agent. Ein gut konfiguriertes Workspace ONE UEM oder Microsoft Intune mit dem richtigen Deployment-Profil liefert die technische Grundlage für den NATO-konformen Betrieb. Das ist eine massive Aufwertung für Standard-MDM-Infrastruktur in Behördenumgebungen – und ein starkes Argument in Kundengesprächen.

Apple öffnet sich eine Tür – hinter der richtig viel Budget liegt 📈

Das ist der wirtschaftliche Aspekt, den man nicht ignorieren sollte. Behörden, Militär, Sicherheitsorganisationen, KRITIS-Betreiber – das sind Märkte mit erheblichem Investitionsvolumen, langen Vertragslaufzeiten und einer historisch konservativen Beschaffungspolitik. Mit der NATO-Zertifizierung hat Apple ein überzeugendes Argument in genau diesen Märkten. Nicht nur für die Hardware, sondern für das gesamte Apple-Ökosystem: MDM via WS1 oder Intune, JAMF für macOS, iCloud in freigegebenen Kontexten.

💡 Strategische Einschätzung: Apple macht sich mit der Indigo-Zertifizierung eine Tür auf, hinter der richtig viel Budget liegt. Der öffentliche Sektor in NATO-Mitgliedsstaaten wird diese Zertifizierung als Grundlage für Beschaffungsentscheidungen nutzen – und das über Jahre hinweg. Für MDM-Berater und Systemhäuser im Public-Sector-Umfeld ist das ein echter Türöffner für neue Projekte.

Die kritischen Fragen – weil es sie gibt

NATO RESTRICTED ist die niedrigste Stufe – Kontext ist alles

Das muss man klar sagen: Die Zertifizierung gilt für NATO RESTRICTED – die unterste von vier Geheimhaltungsstufen. NATO CONFIDENTIAL, NATO SECRET und COSMIC TOP SECRET bleiben weiterhin spezialisierten, gehärteten Systemen vorbehalten. Die Berichterstattung hat das manchmal etwas dramatischer klingen lassen als es ist. Trotzdem: Für einen riesigen Teil der täglichen Behörden- und Militärarbeit ist NATO RESTRICTED die relevante Stufe. Der Großteil der Verschlusssachen im operativen Dienstbetrieb läuft auf genau dieser Ebene – und da ist die Zertifizierung absolut relevant.

Supervised Mode schließt BYOD vollständig aus

Die Zertifizierung gilt ausschließlich für vollständig MDM-verwaltete Corporate Devices im Supervised Mode. BYOD-Konzepte, Work-Profile-Ansätze oder MAM-only sind für klassifizierte Umgebungen damit nicht zulässig. Für Behörden mit BYOD-Programmen bedeutet das: zwei getrennte Device-Welten. Das ist operativ handhabbar – muss aber von Anfang an in der MDM-Architektur eingeplant werden.

Indigo ist kein Plug-and-Play – das Hausaufgabenheft bleibt offen

Trotz der simplen Bezeichnung ist Indigo kein Schalter, den man einfach umlegt. Es ist eine Betriebskonfiguration, die durch MDM-Policies umgesetzt werden muss – und die genauen Policy-Anforderungen sind bisher nicht vollständig öffentlich dokumentiert. Organisationen, die das ernsthaft umsetzen wollen, müssen das mit ihrem MDM-Anbieter, dem BSI und den jeweiligen nationalen Sicherheitsbehörden abstimmen. Was ich mir wünschen würde: eine öffentliche, BSI-endorsed Configuration Baseline – ähnlich wie NIST das für andere Plattformen publiziert. Das würde die Community wirklich weiterbringen.

Apple ist ein US-Konzern – der CLOUD Act bleibt ein Thema

Das kann man nicht einfach ignorieren. Apple ist ein US-amerikanisches Unternehmen, unterliegt US-Recht und theoretisch dem U.S. CLOUD Act. Die Secure Enclave ist hardwareseitig stark abgeschirmt, und Apple hat mehrfach betont, keine Backdoors eingebaut zu haben. Das BSI hat die Plattform gründlich geprüft und freigegeben – das ist ein starkes, unabhängiges Signal. Aber die Diskussion über digitale Souveränität und Abhängigkeit von US-Technologie bleibt politisch hochaktuell, gerade im europäischen Kontext.

Und Android? Die berechtigte Frage

Die Frage die sich viele Enterprise-Admins stellen werden: Wenn Apple es geschafft hat – warum nicht Android? Google hat mit Android Enterprise, dem Pixel-Portfolio und dem Android Ready SE Alliance-Programm ebenfalls erheblich in Hardware-Security investiert. Und trotzdem: Bisher ist kein einziges Android-Device im NIAPC gelistet. Das zeigt eindrucksvoll den Unterschied zwischen einem vertikal integrierten Ökosystem – Apple: eigener Chip, eigenes OS, eigene Sicherheitsarchitektur, alles aus einer Hand – und einem fragmentierten Ökosystem mit dutzenden OEMs, die alle unterschiedliche Hardware und unterschiedliche Update-Zyklen mitbringen. Für Android-lastige MDM-Umgebungen bleibt das eine offene und relevante Frage.

Was bedeutet das für MDM-Deployments in der Praxis?

Für alle, die das jetzt operativ umsetzen wollen oder müssen – hier die wichtigsten Anforderungen auf einen Blick:

Aspekt Anforderung / Implikation
iOS/iPadOS Version iOS 26 / iPadOS 26 – Mindestvoraussetzung, keine Ausnahme
Enrollment Supervised Mode via Apple Business Manager zwingend erforderlich
MDM-Plattform WS1 UEM oder Intune mit vollständiger iOS-Supervised-Unterstützung
Gerätehardware A19/M5 für MIE (always-on memory safety) – ältere HW formal konform, aber eingeschränkt
Freigegebene Apps Mail, Kalender, Kontakte (native Apple Apps) – explizit bestätigt
Netzwerk VPN nativ: IKEv2, Cisco IPsec, L2TP over IPsec – kein Zusatz-Client nötig
BYOD Nicht zulässig – ausschließlich vollständig verwaltete Corporate Devices
Policy-Anforderungen Abstimmung mit BSI / nationaler Sicherheitsbehörde erforderlich
Updates Konsequentes iOS-Update-Management zwingend – veraltetes OS = keine Konformität

Für WS1-Umgebungen: Die Kombination aus Apple Business Manager, WS1 UEM und der Indigo-Konfiguration ergibt ein kohärentes, nachvollziehbares Sicherheits-Stack – und ist ein starkes Argument für den Verbleib in der Apple-WS1-Welt, wenn Public-Sector-Kontexte eine Rolle spielen. Für Intune gilt das gleiche: Supervised iOS wird vollständig unterstützt, die nötigen Baseline-Policies lassen sich sauber ausrollen.

Fazit: Echter Meilenstein – mit offenem Hausaufgabenheft

Ich sag’s klar: Das ist ein echter Meilenstein. Nicht wegen dem vollmundigen Apple-Marketing, sondern weil das BSI eine der anspruchsvollsten Sicherheitsbewertungsbehörden weltweit ist. Wenn das BSI Standard-iOS für VS-NfD freigibt, wurde das ernsthaft geprüft – und das Ergebnis hat Gewicht.

Die Implikationen für unsere Branche sind erheblich. Erstmals ist ein Consumer-Betriebssystem offiziell als sicher genug für klassifizierte staatliche Informationen eingestuft. Das verändert die Benchmark – für Apple, für die Konkurrenz und für die Art wie wir über mobile Sicherheitsarchitekturen nachdenken. Security by Design ist keine leere Marketing-Phrase mehr, sondern eine extern bestätigte Tatsache.

Für MDM-Admins und Berater im Public-Sector-Umfeld: Das ist ein Türöffner. Nicht nur für iOS-Deployments, sondern für das gesamte Gespräch rund um Standard-Hardware in sicherheitskritischen Umgebungen. Wer bisher gegen den Widerstand von IT-Sicherheitsbeauftragten ankämpfen musste, hat jetzt ein starkes Argument in der Hand.

Was ich mir noch wünsche: eine öffentliche, BSI-endorsed Configuration Baseline, die konkret dokumentiert welche MDM-Policies die Indigo-Konfiguration ausmachen. Das würde die operative Umsetzung deutlich vereinfachen und der Community echten Mehrwert liefern. Bis dahin: selbst recherchieren & BSI-Dokumente lesen. 😄

Workspace ONE vs. Microsoft Intune: Mein ehrlicher MDM-Vergleich nach 16+ Jahren im Feld

1. März 2026 / / Keine Kommentare

Workspace ONE vs. Microsoft Intune: Mein ehrlicher MDM-Vergleich nach 16+ Jahren im Feld

Also, lasst mich direkt loslegen – kein Blabla vorneweg. Ich bin seit 26 Jahren in der IT, die letzten 16+ davon speziell im Mobile Device Management. iOS, Android und in den letzten 7 Jahren dazu noch der Fokus auf Zebra-Rugged-Devices, Honeywell MDE. Dabei hab‘ ich schon so ziemlich alles gesehen, was die Branche zu bieten hat. Und die beiden Systeme, die mich dabei am längsten begleiten: VMware Workspace ONE (WS1) und Microsoft Intune. Beide stark. Beide mit Ecken und Kanten. Und beide für bestimmte Szenarien einfach die richtige Wahl.

In diesem Post zeige ich euch keinen Marketing-Vergleich, sondern meinen ehrlichen Blick aus dem Admin-Alltag. Kein Sieger, kein Verlierer – nur Fakten, Erfahrungen und ein bisschen Meinung. Los geht’s!

Ein kurzer Blick zurück: Wie haben sich WS1 und Intune entwickelt?

Wer lange genug dabei ist, erinnert sich noch an AirWatch. Damals – so ab 2012/2013 – war das die Referenz im MDM-Markt. VMware hat AirWatch 2014 übernommen und daraus Workspace ONE gemacht, ein vollintegriertes Digital Workspace-Ökosystem. Der Ansatz: Ein Ökosystem für alles – MDM, Identity, App-Management, Conditional Access. Klingt gut, und ist es auch – wenn man bereit ist, etwas Zeit zu investieren.

Microsoft Intune startete ungefähr zur gleichen Zeit als eher schlichter MDM-Dienst in der Azure-Cloud. Lange Zeit war es ehrlich gesagt… okay-ish. Aber mit der Einführung von Microsoft Endpoint Manager (MEM) und der späteren Umbenennung und Neuausrichtung als Intune innerhalb des Microsoft 365-Ökosystems hat sich das massiv verändert. Heute ist Intune ein ernstzunehmender Konkurrent – gerade wenn man sowieso tief im Microsoft-Stack steckt.

iOS-Management: Wer macht’s besser?

Workspace ONE

WS1 und iOS – das war lange die Traumehe im Enterprise-Umfeld. Supervised Mode, Apple Business Manager Integration, Custom Payloads, granulare Richtlinien für jede erdenkliche Einstellung: Workspace ONE hat hier jahrelang die Benchmark gesetzt. Besonders bei komplexen Enrollment-Szenarien (Zero-Touch via DEP, Shared Device Mode, etc.) ist WS1 stark.

Was ich persönlich schätze: Die Flexibilität bei Custom Profiles. Wenn Apple mal wieder eine Einstellung nicht offiziell im MDM-Standard freigibt, kann man mit WS1 via Custom XML Payload trotzdem rankommen. Das ist für erfahrene Admins Gold wert.

Zusätzlich ist der Workspace ONE Intelligent Hub unter iOS die Steuerzentrale & bietet dem Anwender über die Umsetzung der Policy, Verteilung der Apps bis hin zu Pushnachrichten, alles was benötigt wird.

Microsoft Intune

Intune hat in den letzten Jahren enorm aufgeholt. ADE (Automated Device Enrollment), Apple Business Manager-Integration, SCEP-Zertifikate (okay okay, hier gibt es so manche Use-Cases, da kann man nur mit dem Kopf drüber schütteln), Conditional Access – das läuft mittlerweile alles rund. Für Organisationen, die primär Microsoft 365 nutzen, ist die Integration einfach nahtlos. Ein Klick in Azure AD, und der Mac (Ja ja, JAMF ist the King, but don’t judge me 😉) oder das iPhone ist im Unternehmensnetzwerk.

Wo Intune noch hinterherhinkt: Bei sehr spezifischen, tief greifenden iOS-Konfigurationen kommt man schneller an Grenzen als bei WS1. Custom Profiles gehen auch hier, aber die Dokumentation und der Support sind nicht immer auf dem gleichen Level.

Kriterium Workspace ONE Microsoft Intune
Apple Business Manager ✅ Stark, tiefe Integration ✅ Gut, nahtlos mit M365
Supervised Mode ✅ Vollständig unterstützt ✅ Vollständig unterstützt
Custom Profiles (XML) ✅ Sehr flexibel ⚠️ Möglich, aber weniger komfortabel
Zero-Touch Enrollment ✅ Excellent ✅ Gut
Conditional Access ✅ Via Workspace ONE Intelligence ✅ Nativ in Azure AD

Android-Management: Enterprise-tauglich oder Bastelbude?

Android for Enterprise (AfE) – die Grundlage

Seit Google Android for Enterprise eingeführt hat, ist Android im Enterprise-Umfeld erwachsen geworden. Beide Systeme unterstützen die gängigen AfE-Enrollment-Methoden: Work Profile, Fully Managed, Dedicated Device. Der Unterschied liegt – wie so oft – im Detail.

Workspace ONE bei Android

WS1 ist im Android-Segment extrem stark, gerade wenn es um Fully Managed Devices oder Dedicated Devices (Kiosk-Mode) geht. Ich hab das in Projekten mit Samsung Knox & Zebra Devices immer wieder erlebt: WS1 gibt dir einfach mehr Hebel. OEM Config-Support, tiefe Knox Integration, granulare App-Verwaltung über Managed Google Play – das sitzt. Auch wenn ich da nochmal sagen muss, Knox und Ich, naja das wird nie eine richtige Freundschaft 😏

Ein echtes Highlight: der Workspace ONE Intelligent Hub. Der Agent macht auf Android deutlich mehr als nur MDM-Policies zu verteilen. Self-Service, App Catalog, Benachrichtigungen – das fühlt sich für den User weniger nach „Kontrolle“ an und mehr nach „Tool“.

Microsoft Intune bei Android

Intune hat bei Android in den letzten Jahren ebenfalls stark nachgelegt. Work Profile Enrollment läuft smooth (okay, wenn wir realistisch sind, kommt es auch hier manchmal auf die Laune von Microsoft an & man darf den einen oder anderen Kaffee trinken, bis das System es richtig umsetzt), MAM (Mobile App Management) ohne Enrollment ist für BYOD-Szenarien oft die smartere Wahl – und hier glänzt Intune wirklich. Die Integration mit Microsoft Apps (Outlook, Teams, Edge) via App Protection Policies ist einfach unschlagbar komfortabel.

Bei Dedicated Devices und komplexen Kiosk-Setups merkt man aber schneller die Grenzen. Hier fehlt Intune die Tiefe, die WS1 mitbringt – vor allem wenn OEM-spezifische Features gefragt sind.

Kriterium Workspace ONE Microsoft Intune
Work Profile (BYOD) ✅ Gut ✅ Sehr gut, bes. mit MAM
Fully Managed Devices ✅ Exzellent ✅ Gut
Dedicated/Kiosk Mode ✅ Sehr flexibel ⚠️ Eingeschränkt
OEM Config (Zebra/Samsung) ✅ Tiefe Integration ⚠️ Basis-Support
MAM ohne Enrollment (BYOD) ✅ Vorhanden ✅ Best-in-Class
Knox Integration ✅ Exzellent ⚠️ Eingeschränkt

Rugged Devices: Zebra, Honeywell & Co. – das oft vergessene Segment

Das ist das Thema, das in 80% der MDM-Blogposts völlig ignoriert wird – aber in den letzten über 7 Jahren durfte ich in meiner täglichen Arbeit einige Erfahrungen sammeln. Zebra TC-Serie, Honeywell CT-Serie, MDE-Devices für Logistik, Produktion, Einzelhandel – das sind Tiere für sich.

Workspace ONE hat hier einen klaren Vorteil: Die Zebra OEM Config-Unterstützung ist exzellent. StageNow-Integration, SOTI-ähnliche Konfigurationsmöglichkeiten via WS1, spezifische Hardware-Profile für Barcode-Scanner, PTT-Tasten, Display-Helligkeit unter bestimmten Bedingungen – das alles lässt sich über WS1 granular steuern.

Intune verbessert sich hier, aber wenn ihr ernsthaft in der Welt der Rugged Devices unterwegs seid, werdet ihr mit Intune allein oft nicht glücklich. Hier braucht man entweder WS1 oder spezialisierte EMM-Lösungen wie SOTI MobiControl. Manche Kunden kombinieren das auch – Intune für Standard-Devices, WS1 oder SOTI für den Rugged-Bereich.

Administration: Wo macht’s mehr Spaß (oder weniger Frust)?

Die WS1-Konsole

Ich sag’s ehrlich: WS1 ist mächtig. Und mit Macht kommt Komplexität. Die Admin-Konsole ist funktionsreich bis an die Grenze des Überwältigenden. Wenn du weißt, was du tust, kannst du quasi alles konfigurieren. Wenn du neu bist, kannst du dich erstmal eine Weile in den Menüs verlieren.

Mit dem Umstieg auf Workspace ONE UEM Cloud und dem neueren UI hat VMware / Broadcom einiges verbessert. Trotzdem: Die Lernkurve ist real. Ich empfehle hier immer eine gute Schulung (auch wenn die nur auf Labs wie bei allen großen besteht) oder – noch besser – jemanden mit Erfahrung an Bord zu holen.

Die Intune-Konsole (aka Microsoft Intune Admin Center)

Wer regelmäßig im Azure-Portal unterwegs ist, fühlt sich in Intune schnell zuhause. Das Layout folgt Microsoft-Logik, die Dokumentation ist umfangreich und auf Microsoft Learn sehr gut aufbereitet. Für Admins, die bereits mit Azure AD, Conditional Access oder Defender for Endpoint arbeiten, ist das ein echter Vorteil – alles spielt zusammen.

Was mich bei Intune manchmal wahnsinnig macht: Einstellungen, die sich an drei verschiedenen Stellen befinden können (Device Configuration, Security Baselines, Endpoint Security…). Das sorgt für „Wo war das nochmal?“-Momente, die man kennt, wenn man Intune schon länger nutzt.

Security: Wer schläft ruhiger?

Security ist das Herzstück jedes MDM-Systems, und hier spielen beide in der obersten Liga – auf unterschiedliche Weise.

Workspace ONE Intelligence & Trust Network

WS1 bringt mit Workspace ONE Intelligence eine eigene SIEM-ähnliche Analyse- und Automatisierungsschicht mit. Ich kann Policies definieren, die automatisch auf Geräte reagieren (z.B.: Device ohne aktuelles OS-Update → Zugriff auf Unternehmensressourcen sperren). Das Trust Network integriert Security-Drittanbieter – hier möchte ich einfach keine Namen nennen, dort gilt: try and error. Für komplexe Enterprise-Security-Setups ist das richtig stark.

Microsoft Defender + Conditional Access

Microsoft spielt seine Stärken hier aus: Microsoft Defender for Endpoint ist direkt in Intune integriert. Conditional Access in Azure AD ist für viele Szenarien der Standard-Ansatz – und das aus gutem Grund. Wenn ihr M365 E5 oder ähnliche Lizenzen habt, bekommt ihr Security-Features, für die ihr bei WS1 extra zahlen würdet.

Für reine Microsoft-Shops ist das Sicherheits-Stack von Microsoft schwer zu schlagen. Für heterogene Umgebungen mit vielen Nicht-Microsoft-Produkten hat WS1 mehr Flexibilität.

Flexibilität & Skalierbarkeit: Wächst das System mit?

Workspace ONE: Extrem skalierbar, extrem flexibel – und extrem komplex wenn man’s falsch angeht. WS1 kann On-Premise, Cloud oder Hybrid betrieben werden. Das ist in regulated industries (KRITIS, Banken, Healthcare) ein echtes Argument.

Und genau für diese regulierten Umgebungen gibt es seit kurzem eine weitere spannende Option: die Omnissa Sovereign Solution für Workspace ONE. Das ist kein klassisches On-Premise mehr im alten Sinne, sondern ein partner-gehostetes SaaS-Modell – sprich, ein zertifizierter Partner betreibt die WS1 UEM-Umgebung in seinem eigenen privaten, lokalen Rechenzentrum. Damit bekommt man die Vorteile einer modernen SaaS-Architektur, ohne die Daten in eine internationale Public Cloud geben zu müssen. Für KRITIS, Behörden oder stark regulierte Branchen kann das ein echter Game-Changer sein – und ist definitiv ein Thema, dem ich hier auf dem Blog noch einen eigenen Post widmen werde!

Intune: Cloud-first, kein On-Premise. Das ist für die meisten Unternehmen heutzutage kein Problem – kann aber in stark regulierten Umgebungen zum Showstopper werden. Dafür ist der Betrieb operativ günstiger und einfacher.

Kriterium Workspace ONE Microsoft Intune
Deployment-Option Cloud, On-Premise, Hybrid, Sovereign Cloud-only
Skalierbarkeit Sehr hoch Hoch
API-Integration Umfangreiche REST APIs Microsoft Graph API
Multi-Tenant ✅ ✅
Lizenzkosten Höher, modular In M365 oft inkludiert
Community & Docs VMware Tech Zone / Broadcom Docs Microsoft Learn (sehr gut)

Das Broadcom-Thema: Der Elefant im Raum

Ich wäre kein ehrlicher MDM-Blogger, wenn ich das nicht ansprechen würde: Broadcom hat VMware übernommen – und das hat die WS1-Welt ordentlich durchgeschüttelt. Lizenzstruktur-Änderungen, Partner-Ökosystem-Unsicherheiten, Support-Fragen… Das sind reale Themen, die Kunden zu Recht beschäftigen.

Ich sage nicht, dass WS1 deshalb keine gute Wahl mehr ist. Aber wer heute eine Entscheidung treffen muss, sollte das Broadcom-Thema in der Bewertung nicht ignorieren. Es hat viele Unternehmen dazu gebracht, ihre MDM-Strategie zu überdenken – und nicht wenige davon landen gerade bei Intune oder evaluieren Alternativen wie Jamf (für Apple-only) oder SOTI.

Für wen ist was die bessere Wahl?

Jetzt wird’s meinungsstark – aber ohne Sieger. Es gibt kein „besser“ ohne Kontext. Hier meine Einschätzung:

  • Du bist tief im Microsoft 365-Ökosystem, nutzt Azure AD, Defender und Teams? → Intune ist dein Weg.
  • Du hast eine heterogene Umgebung mit iOS, Android und Rugged Devices von Zebra oder Honeywell? → WS1 hat die tiefere Feature-Abdeckung.
  • Du bist ein kleines bis mittelständisches Unternehmen ohne dediziertes MDM-Team? → Intune ist einsteigerfreundlicher und günstiger.
  • Du brauchst On-Premise, Hybrid oder Sovereign-Deployment aus regulatorischen Gründen? → WS1 (inkl. Omnissa Sovereign Solution) ist dein einziger Kandidat der beiden.
  • BYOD-Strategie mit Android und minimaler Eingriff auf Privatgeräte? → Intune MAM ist hier das Mittel der Wahl.
  • Komplexe Enterprise-Security mit Drittanbieter-Integration? → WS1 Intelligence bietet hier mehr Flexibilität.

Fazit: Zwei Welten, eine Entscheidung

Nach 16+ Jahren MDM kann ich euch sagen: Es gibt kein universell „besseres“ System. Workspace ONE ist das Schweizer Taschenmesser – mächtig, flexibel, aber komplex. Microsoft Intune ist der verlässliche Werkzeugkasten für alle, die schon tief im Microsoft-Stack stecken.

Was ich euch mitgeben will: Evaluiert ehrlich eure eigene Umgebung. Welche Devices, welche Nutzungsszenarien, welche internen Skills habt ihr? Und schaut euch die Lizenzkosten ganzheitlich an – Intune ist oft schon in euren M365-Lizenzen drin, WS1 kostet extra.

Aber eins ist klar: Es bleibt spannend und der Bereich entwickelt sich und entwickelt sich. Man darf sich hier einfach weiter drauf freuen, wie es weitergeht – und wer weiß, vielleicht kommt ja noch einer der underated Underdogs aus dem Untergrund wieder hoch. 😄

Ich freue mich auf eure Erfahrungen in den Kommentaren – seid ihr Team WS1, Team Intune, oder habt ihr eine ganz andere Lösung gefunden? Immer her damit! 😄