Kategorie: iOS

Microsoft Intune Release 2603: DDM für Apple, Recovery Lock für macOS und Linux Support

Microsoft Intune Release 2603: DDM für Apple, Recovery Lock für macOS und Linux Support

Schon wieder März – und wieder eine Release, die zeigt, wo Microsofts Reise hingeht. Diesmal hat man sich besonders Zeit für Apple DDM genommen, und das ist bedeutsam. Als jemand, der schon länger im MDM-Umfeld unterwegs ist, sehe ich hier einen wichtigen Shift: Apple zieht mit Declarative Device Management aus dem klassischen MDM-Modus raus. Das ist nicht einfach nur „noch ein Feature“ – das ändert, wie wir iOS/iPadOS Apps deployen.

Gleichzeitig bekommt macOS endlich ordentliche Recovery Lock Features, Android Enterprise kriegt neuen OEM-Support, und Linux wird erwachsen. Lass mich die wichtigsten Punkte durchgehen.


Übersichtstabelle: Was ändert sich in 2603?

Feature Plattform Kategorie Status
Declarative Device Management (DDM) für Line-of-Business Apps iOS/iPadOS 18+ App Management ✅ Verfügbar
Recovery Lock mit Password Rotation macOS Device Configuration 🔄 Rollout (bis Ende April)
Inventus OEMConfig Integration Android Enterprise OEMConfig ✅ Verfügbar
Disable Cross Device Resume Policy Windows 10/11 Settings Catalog ✅ Windows Insiders
Remove Microsoft Copilot App Policy Windows 10/11 Settings Catalog ✅ Verfügbar
Apple Intelligence & AI Settings (DDM) iOS/iPadOS, macOS Settings Catalog ✅ Verfügbar
Remote Help Connectivity Endpoint Windows Device Management ✅ Verfügbar
RHEL 9 LTS & 10 LTS Support Linux Enrollment ✅ Verfügbar
Microsoft Identity Broker für Linux Linux Authentication ✅ Verfügbar

1. Declarative Device Management für Apple – Das große Ding

Was ist DDM und warum sollte dich das interessieren?

Seit iOS 18 und iPadOS 18 können wir Apple DDM nutzen, um Line-of-Business Apps zu verwalten. Das ist ein großer Unterschied zur klassischen MDM-Verwaltung:

Klassisches MDM:
– Reaktive Verwaltung (Befehl → Antwort)
– Höhere Latenz bei App-Installationen
– Limitierte Per-App-Optionen

Apple DDM:
Deklarativ (Zielzustand definieren, Apple macht den Rest)
– Echte Echtzeit-App-Status
– Associated Domains Support
– Bessere Delivery Efficiency

Praktisch im Intune Admin Center:

  1. DevicesApps → Deine iOS/iPadOS Line-of-Business App öffnen
  2. App Information → Management Type auf Declarative Device Management setzen
  3. Neue Per-App-Optionen konfigurieren (z.B. Associated Domains)
  4. Deployment starten

Was dich erwartet:

✅ Schnellere App-Bereitstellung
✅ Bessere App-Status-Transparenz
✅ Neue Security Features via Associated Domains
❌ Nur für iOS/iPadOS 18+ (Versionsprüfung nötig)

Meine Einschätzung: Das ist ein echter Game-Changer für Unternehmen mit großen iOS-Flotten. Wenn du noch auf iOS 17 bist, solltest du jetzt deinen Update-Plan prüfen.


2. Recovery Lock für macOS – Sicherheit auf neuer Ebene

Das Problem, das Recovery Lock löst:

Ein User mit lokalen Admin-Rechten kann sich in Recovery Mode booten, die Festplatte neuformatieren und dein MDM-Management umgehen. Damit ist Schluss.

Was ist Recovery Lock?

Ein Recovery OS Password, der verhindert:
– Booten in Recovery Mode
– macOS Neuinstallation ohne Admin-Genehmigung
– Umgehen der Remote Management

Zwei Wege zur Umsetzung:

Option 1: Settings Catalog Policy

Devices → Configuration profiles → Create profile
→ macOS → Settings Catalog
→ Recovery Lock
  • Feature aktivieren
  • Password Rotation Schedule setzen (z.B. alle 90 Tage)
  • Speichern

Option 2: Remote Device Action (Manuelle Rotation)

Devices → All devices
→ [Device auswählen]
→ ... → Remote tasks
→ Recovery Lock rotation → Starten

Wichtig: RBAC für Passwords

⚠️ Handlungsbedarf: Admins brauchen explizit die Berechtigung:

Remote tasks/View macOS recovery lock password

Das stellst du unter Roles & Admins → Custom Role → Permissions ein.

Verfügbarkeit:

🔄 Graduelle Rollout bis Ende April 2026 – nicht sofort in allen Tenants verfügbar.


3. Android Enterprise: Inventus OEMConfig

Neu: Inventus com.inventus.oemconfig.gen

Für Admin, die mit Inventus-Rugged-Devices arbeiten (stark in der Logistik/Warehouse), ist das relevant.

OEMConfig erlaubt es, OEM-spezifische Features direkt über Intune zu verwalten:

Devices → Configuration profiles → Create
→ Android Enterprise
→ OEMConfig
→ Inventus (com.inventus.oemconfig.gen)
→ OEM-spezifische Settings konfigurieren

Für wen relevant: Unternehmen mit Zebra/Honeywell/Inventus Devices im Warehouse/Retail.


4. Windows Settings Catalog – Zwei neue Policies mit Bedeutung

Policy 1: Disable Cross Device Resume

Scenario: Der User startet etwas auf seinem iPhone und will es auf dem PC fortsetzen. Security-Policy sagt: Nein.

Devices → Configuration profiles → Create
→ Windows 10 and later
→ Settings Catalog
→ Connectivity
→ Disable Cross Device Resume: Select "Disabled"

Effekt: Keine „Resume from your phone“ Prompts mehr.

Status: ⚠️ Nur für Windows Insiders (Preview-Feature)

Policy 2: Remove Microsoft Copilot App

Szenario: Copilot ist vorinstalliert, aber deine Security Policy sagt: Nicht auf unternehmenseigenen Devices.

Settings Catalog
→ Windows AI
→ Remove Microsoft Copilot App: Enable

Bedingungen (automatisch prüfbar):
– Beide Copilot Apps sind installiert
– User hat die App nicht selbst installiert
– App wurde in letzten 14 Tagen nicht geöffnet

Effekt: App wird deinstalliert (User kann sie später neu installieren).

Status: ✅ Sofort verfügbar


5. Apple Settings Catalog – DDM erweitert sich massiv

DDM x Apple Intelligence Settings (Neu!)

Mit iOS 18 / macOS Sonoma kommt Apple Intelligence. Intune kann jetzt granular kontrollieren:

iOS/iPadOS DDM Settings (neu):
– External Intelligence: Sign In, Workspace IDs
– Apple Intelligence: Report, Genmoji, Image Playground, Visual Intelligence Summary
– Mail: Smart Replies, Summary
– Notes: Transcription, Summary
– Safari: Summary
– Keyboard: Definition Lookup, Auto-Correction, Dictation, Predictive Text, etc.
– Siri: User Generated Content, While Locked, Profanity Filter

macOS DDM Settings (neu):
– File Provider: Remote Syncing, External Volume Syncing, Domain Auto-Enablement
– Rosetta Usage Awareness (für ARM-Transition)

Praktisch:

Devices → Configuration profiles → Create
→ iOS or macOS
→ Settings Catalog
→ Declarative Device Management
→ Intelligence Settings
→ z.B. "Allow Apple Intelligence Report" = Toggle

Security-Tipp: Wenn deine Compliance-Policy Says „Keine Cloud-Datenanalyse“, stellst du hier alle AI-Features auf Disabled.


6. Remote Help – Neue Connectivity-Anforderung ⚠️

Firewall-Update erforderlich!

Microsoft hat einen neuen Endpoint für Remote Help (Launch Remote Help in Admin Center) hinzugefügt:

*.trouter.communications.svc.cloud.microsoft

Handlungsbedarf:
1. ✅ Aktualisiere deine Firewall-Regeln
2. ✅ Prüfe Proxy-Konfiguration
3. ✅ Teste Remote Help mit Windows-Device nach Update

Neues Log-File:
NotificationInfra.log (Intune Management Extension)
– Trackt Real-Time-Communication-Notifications
– Hilfreich für Troubleshooting

Ort: C:\Program Files (x86)\Microsoft Intune Management Extension\Logs\


7. Linux Support – RHEL wird erwachsen

Support-Änderung:

Version Status Aktion
RHEL 8 LTS ❌ End of Support Bestehende Devices bleiben enrollt, aber kein Support mehr
RHEL 9 LTS ✅ Neu unterstützt Production-Ready
RHEL 10 LTS ✅ Neu unterstützt Production-Ready

Handlungsbedarf für dich:

  1. Identify RHEL 8 Devices:
Intune Admin Center
→ Devices → All devices
→ Filter: OS = Linux
→ Add Column: OS Version
  1. User Notification:
    – E-Mail an Admins mit RHEL 8-Devices
    – Upgrade-Plan für Q2/Q3 2026
  2. Enrollment Verification:
    – Neue Enrollments nur auf RHEL 9+ akzeptieren
    – Enrollment Restrictions prüfen

Microsoft Intune App für Linux – Identity Broker Integration

Die neue Version der Intune-App für Linux unterstützt jetzt Microsoft Identity Broker, was bedeutet:
– SSO zwischen Linux-Apps und Browser
– Bessere Token-Verwaltung
– Sicherere Authentication Flow


🚨 Kritische Handlungsbedarfe

Punkt Kritikalität Deadline Aktion
Firewall Update (Remote Help Endpoint) 🔴 Hoch Sofort *.trouter.communications.svc.cloud.microsoft allowlisten
RHEL 8 Geräte identifizieren 🟡 Mittel Bis Juni 2026 Inventory + Upgrade-Plan
Recovery Lock RBAC Setup 🟡 Mittel Bis Ende April Berechtigungen für Admin-Rollen anpassen
iOS 18 DDM Readiness Check 🟡 Mittel Vor Rollout Device-Kompatibilität prüfen (iOS 18+)
Windows Insider Copilot Policy Testen 🟢 Niedrig Optional In Test-Ring deployen

Meine persönliche Einschätzung

Diese Release 2603 ist solider mittlerer Release – nicht revolutionär, aber substanziell:

Positiv:
– Apple DDM für LOB Apps ist längst überfällig und wird Deployment-Performance spürbar verbessern
– Recovery Lock für macOS schliesst echte Security-Lücke
– Linux Support mit RHEL 9/10 macht Sinn (Zukunftsicherung)
– AI Settings Katalog zeigt, dass Microsoft ernst mit Apple Intelligence-Management meint

⚠️ Vorsichtig:
– Recovery Lock ist nur graduelle Rollout (bis Ende April) – nicht ideal für große Deployments
– Cross-Device Resume Policy ist noch Insider-only (zu nischig?)
– Copilot Removal braucht spezifische Bedingungen (14 Tage nicht geöffnet – kann frustrierend sein)

🔔 Wichtigste Action: Firewall-Update für Remote Help. Das übersehen viele und dann funktioniert Remote Help plötzlich nicht.


Quellen & Dokumentation

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

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
Vollständiges Inventar aller Geräte exportieren – Seriennummern, OS-Version, Enrollment-Status Pflicht
Alle Konfigurationsprofile dokumentieren: Wi-Fi, VPN, Zertifikate, Restrictions, E-Mail Pflicht
Compliance-Policies, Security-Baselines und Scripts erfassen Pflicht
App-Deployment dokumentieren: Welche Apps, VPP oder direkt, welche Managed Configs Pflicht
Neues MDM vollständig konfigurieren: APNs, ABM-Token, Enrollment Profile, alle Profile nachbauen Pflicht
VPP Content Token: Aus altem MDM entfernen, neues Token im neuen MDM registrieren Kritisch
Pilot-Gruppe definieren (5–10 Geräte) für Testlauf vor Massenrollout Empfohlen
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.

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

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. 😄