Was ist deklaratives Gerätemanagement? (2026)

Declarative Device Management (DDM) ist Apples Framework, mit dem Geräte ihre eigenen Konfigurationen lokal durchsetzen können, ohne auf Anweisungen vom Server warten zu müssen. Es wurde auf der WWDC 2021 vorgestellt und verändert das Kommunikationsmodell zwischen Ihrem MDM-Server und Ihrer Apple-Geräteflotte grundlegend.

Wenn Sie macOS-, iOS- oder iPadOS-Geräte in nennenswertem Umfang verwalten, ist DDM die bedeutendste architektonische Veränderung in der Apple-Geräteverwaltung seit der Einführung von MDM im Jahr 2010. Dieser Leitfaden erklärt, was DDM ist, wie es technisch funktioniert, wie es sich in das bestehende MDM-System einfügt und was Sie unternehmen müssen, bevor Apples Zeitplan für die Auslaufphase Sie zum Handeln zwingt.

Warum herkömmliches MDM Skalierungsprobleme hat

Um zu verstehen, warum es DDM gibt, muss man verstehen, was an dem Protokoll, das es ersetzt, nicht funktioniert. Herkömmliches MDM basiert auf einem Polling-Modell. Der Server sendet einen Befehl, das Gerät führt ihn aus, das Gerät meldet sich zurück, der Server sendet den nächsten Befehl. Jede Statusabfrage, jede Konfigurationsübertragung, jeder Befehl für ein Software-Update durchläuft diese Anfrage-Antwort-Schleife.

Bei 50 Geräten ist das kein Problem. Bei 5.000 Geräten muss der Server Tausende gleichzeitiger Abfragen bewältigen. Bei 50.000 Geräten verwaltet man die Infrastruktur nur noch, um die Infrastruktur zu verwalten. Das Modell führt zudem zu Compliance-Lücken: Ein Gerät, das den MDM-Server nicht erreichen kann, aktualisiert seine Konfiguration einfach nicht, und der Server erfährt erst beim nächsten erfolgreichen Check-in von der Abweichung.

Es gibt noch ein subtileres Problem. Herkömmliches MDM ist aus Sicht des Geräts zustandslos. Das Gerät „weiß“ nicht, wie sein Sollzustand aussieht. Es führt lediglich Befehle aus, sobald diese eintreffen. Wenn ein Benutzer zwischen zwei MDM-Check-ins eine Einstellung ändert, befindet sich das Gerät in einem nicht konformen Zustand, bis der Server erneut abfragt und eine Korrektur veranlasst.

Um zu verstehen, wie die Geräteverwaltung auf Protokollebene funktioniert: Diese Abfragearchitektur ist die zentrale Einschränkung, die DDM beseitigen soll.

So funktioniert deklaratives Gerätemanagement

DDM kehrt das Verwaltungsmodell um. Anstatt dass der Server dem Gerät Schritt für Schritt vorschreibt, was zu tun ist, sendet der Server dem Gerät eine vollständige Beschreibung seines Sollzustands. Das Gerät speichert diese Beschreibung lokal und setzt sie autonom durch, auch ohne aktive Serververbindung.

So sieht das in der Praxis aus: Beim herkömmlichen MDM erfordert die Installation eines Konfigurationsprofils, dass der Server einen Befehl sendet, auf die Bestätigung durch das Gerät wartet, die Installation des Profils bestätigt und eventuelle Fehler behandelt. Bei DDM sendet der Server eine Deklaration mit dem Inhalt: „Dieses Gerät sollte diese Konfiguration haben.“ Das Gerät übernimmt die Verantwortung dafür, diesen Zustand zu verwirklichen und langfristig aufrechtzuerhalten.

Wenn ein Benutzer eine verwaltete Einstellung entfernt, stellt das Gerät diese sofort wieder her, ohne auf den Server zu warten. Ist das Gerät drei Tage lang offline, setzt es die Durchsetzung des deklarierten Zustands fort. Bei der erneuten Verbindung meldet es über den Statuskanal, was während der Unterbrechung geschehen ist.

Die drei Säulen: Deklarationen, Statuskanal und Erweiterbarkeit

Die DDM-Architektur von Apple basiert auf drei Komponenten. Jeder IT-Administrator, der mit Apple-Geräten arbeitet, muss alle drei verstehen.

Deklarationen

Deklarationen sind strukturierte JSON-Dokumente, die beschreiben, wie ein Gerät beschaffen sein und was es tun soll. Es gibt vier Arten von Deklarationen:

• Konfigurationsdeklarationen: Definieren spezifische Einstellungen auf dem Gerät, vergleichbar mit Konfigurationsprofilen in älteren MDM-Systemen, werden jedoch lokal gespeichert und durchgesetzt. Beispiele hierfür sind Passwortrichtlinien, WLAN-Einstellungen und VPN-Konfigurationen.
• Asset-Deklarationen: Verweisen auf externe Ressourcen, von denen Deklarationen abhängen, wie beispielsweise Anmeldedaten oder Zertifikate, die zur Aktivierung einer Konfiguration benötigt werden.
• Aktivierungsdeklarationen: Definieren Prädikate, die festlegen, wann eine Konfiguration gelten soll. Zum Beispiel: „FileVault nur erzwingen, wenn das Gerät beim Identitätsanbieter des Unternehmens registriert ist.“ Diese bedingte Logik wird auf dem Gerät und nicht auf dem Server ausgeführt.
• Verwaltungsdeklarationen: Verwalten Informationen auf Registrierungsebene, einschließlich der Registrierungseigenschaften des Geräts und der MDM-Dienstkonfiguration.

Das Prädikatsystem in Aktivierungsdeklarationen ist eine der leistungsstärksten und am meisten unterschätzten Funktionen von DDM. Anstatt dass der Server die Logik ausführt, um zu entscheiden, welche Geräte welche Konfigurationen erhalten, verlagern Sie diese Logik auf das Gerät selbst. Ein Gerät, das im Bereich Ihrer Finanzabteilung registriert ist, kann auf der Grundlage lokal ausgewerteter Kriterien eigenständig strengere Verschlüsselungseinstellungen anwenden als ein Gerät im allgemeinen Betrieb.

Statuskanal

Der Statuskanal ist der asynchrone Berichtsmechanismus von DDM. Geräte senden Statusberichte an den Server, sobald sich etwas Wesentliches ändert – nicht nach einem festgelegten Abfragezeitplan. Wenn ein Gerät eine Deklaration erfolgreich anwendet, meldet es dies. Wenn sich der Status eines Aktivierungsprädikats ändert, meldet es dies. Wenn ein Software-Update installiert wird, meldet es dies.

Für IT-Teams verändert dies die Sichtweise auf die Transparenz des Gerätebestands. Anstatt den Status nach einem festen Zeitplan abzufragen, erhalten Sie einen Strom von Änderungsereignissen. Ihr Gerätebestand bleibt nahezu in Echtzeit auf dem neuesten Stand, ohne dass dabei eine der Geräteflottengröße proportionale Serverlast entsteht. Eine Flotte mit 10.000 Geräten erzeugt Statusdatenverkehr, wenn sich etwas ändert – und nicht 10.000 Abfragen alle 15 Minuten.

Dies verändert auch die Überwachung der Compliance. Bei herkömmlichen MDM-Lösungen werden Abweichungen erst beim Check-in entdeckt. Über den Statuskanal von DDM teilt Ihnen das Gerät unmittelbar nach dem Auftreten mit, dass es eine Abweichung erkannt und korrigiert hat – oder dass es eine Abweichung erkannt hat, die es nicht selbst korrigieren kann.

Erweiterbarkeit

Dank der Erweiterbarkeit kann das DDM-Framework neue Deklarationstypen unterstützen, sobald Apple diese in neuen Betriebssystemversionen hinzufügt. Anstatt bei jeder Einführung neuer Verwaltungsfunktionen durch Apple Protokolländerungen zu erfordern, bietet die Erweiterbarkeit einen standardisierten Mechanismus zum Hinzufügen neuer Konfigurations- und Statustypen.

Dies ist für die langfristige Planung von Bedeutung. Da Apple die DDM-Unterstützung kontinuierlich ausbaut, kann Ihre MDM-Plattform neue Deklarationstypen übernehmen, ohne dass grundlegende architektonische Änderungen erforderlich sind. Für IT-Teams, die MDM-Anbieter evaluieren, wird eine Plattform mit nativer DDM-Unterstützung, die auf Erweiterbarkeitsprinzipien basiert, im Zuge der Weiterentwicklung der Verwaltungs-APIs von Apple deutlich einfacher zu warten sein.

Deklaratives Gerätemanagement vs. traditionelles MDM

Die praktischen Unterschiede zwischen DDM und traditionellem MDM wirken sich auf den täglichen Betrieb in einer Weise aus, die für IT-Teams, die reale Geräteflotten verwalten, von Bedeutung ist.

Es lohnt sich, Klarheit über die Koexistenz zu schaffen: DDM ersetzt das herkömmliche MDM nicht vollständig – zumindest noch nicht. Die beiden Protokolle laufen auf registrierten Geräten parallel. Bestimmte Aktionen werden weiterhin über MDM-Befehle abgewickelt, Registrierungsabläufe nutzen nach wie vor traditionelle MDM-Kanäle, und einige Funktionen wurden noch nicht auf DDM migriert. Apple hat angekündigt, dass ältere Befehle für Software-Updates, Einschränkungen und bestimmte Konfigurationen ab iOS/macOS 26 und höher nicht mehr unterstützt werden, sodass DDM künftig der erforderliche Weg für diese Funktionen sein wird.

Anforderungen an die Betriebssystemversion für DDM

Die DDM-Unterstützung ist an bestimmte Apple-Betriebssystemversionen gebunden. Bevor Sie Verwaltungsabläufe rund um DDM aufbauen, überprüfen Sie die Betriebssystemverteilung Ihrer Geräteflotte:

• iOS 15 / iPadOS 15 / macOS 12 Monterey: Erste DDM-Unterstützung eingeführt
• iOS 16 / iPadOS 16 / macOS 13 Ventura: Erweiterte Deklarationstypen, Verwaltung von Software-Updates über DDM
• iOS 17 / iPadOS 17 / macOS 14 Sonoma: Zusätzliche Konfigurationsdeklarationen, verbesserte Statusberichte
• iOS 18 / iPadOS 18 / macOS 15 Sequoia: Weitere Erweiterung; zusätzliche veraltete MDM-Befehle, deren Verwendung eingestellt wird
• iOS/macOS 26 und höher: Umfangreiche Auslaufmaßnahmen für ältere MDM-Befehle; DDM wird zum obligatorischen Weg für die Durchsetzung von Software-Updates und zusätzliche Konfigurationstypen

Wenn Ihre Geräteflotte Geräte mit älteren Betriebssystemversionen umfasst, benötigen Sie während der Übergangsphase einen hybriden Ansatz. Geräte mit einer Version unter iOS 15 oder macOS 12 können DDM überhaupt nicht nutzen und benötigen auf unbestimmte Zeit veraltete MDM-Befehle, oder Sie müssen diese Geräte aus Ihrer unterstützten Hardware herausplanen.

Sicherheitsauswirkungen von DDM auf die Compliance in Unternehmen

Das autonome Durchsetzungsmodell von DDM hat direkte Auswirkungen auf die Sicherheitslage, die aus rein geräteverwaltungstechnischer Sicht nicht offensichtlich sind.

Bei herkömmlichem MDM entspricht der Compliance-Status eines Geräts einer Momentaufnahme zum Zeitpunkt der letzten Überprüfung. Ein Gerät, das um 9 Uhr morgens eine Sicherheitskonfiguration ändert und sich erst um 21 Uhr meldet, war 12 Stunden lang nicht konform. In regulierten Umgebungen, die nach Rahmenwerken wie NIST SP 800-53 oder den CIS-Benchmarks für macOS betrieben werden, stellt diese Lücke einen Kontrollversagen dar – selbst wenn sie nur vorübergehend ist.

DDM schließt diese Lücke. Da das Gerät seinen eigenen deklarierten Status kontinuierlich durchsetzt, wird das Zeitfenster zwischen Nichteinhaltung und Behebung in Sekunden und nicht in Stunden gemessen. Der Statuskanal zeichnet das Ereignis auf und liefert Ihnen einen Prüfpfad, der die Abweichung und die Korrektur mit Zeitstempeln dokumentiert.

Für Zero-Trust-Architekturen, die sich auf Signale zum Gerätestatus stützen, um Zugriff zu gewähren oder zu verweigern, ist dies von großer Bedeutung. Ein Gerät, das die Einhaltung einer Richtlinie gegenüber einer Policy-Engine wie einem Identitätsanbieter oder einem SSO-Gateway geltend macht, muss genaue Statusdaten liefern. Die kontinuierliche lokale Durchsetzung durch DDM in Kombination mit Echtzeit-Statusberichten macht Signale zum Gerätestatus zuverlässiger, als dies bei abfragebasierten Überprüfungen möglich ist.

Dies fügt sich nahtlos in eine umfassendere Endpunkt-Sicherheitsstrategie ein. Wenn Sie Gerätemanagement und Sicherheit als integrierte Disziplinen und nicht als getrennte Funktionen betrachten, ist die Architektur von DDM genau auf dieses integrierte Modell ausgelegt.

Durchsetzung von Software-Updates mit DDM

Im Bereich des Software-Update-Managements zeigen sich die Vorteile von DDM für IT-Teams in Unternehmen am unmittelbarsten, und hier sorgt Apples Zeitplan für die Einstellung von Support für die größte Dringlichkeit.

Bei herkömmlichen MDM-Lösungen umfasst die Durchsetzung einer bestimmten macOS-Version folgende Schritte: Der Server sendet einen Update-Befehl, das Gerät bestätigt diesen, lädt das Update herunter und bereitet es vor, und der Server führt eine Abfrage durch, um den Erfolg zu bestätigen. Ist das Gerät während des geplanten Zeitfensters offline, findet das Update nicht statt. Wenn ein Benutzer das Update aufschiebt, muss der Server erneut einen Befehl senden.

DDM verwaltet Software-Updates über die Konfigurationsanweisung „Software-Update“. Sie legen die minimal akzeptable Betriebssystemversion fest. Das Gerät gleicht seinen aktuellen Zustand mit dieser Vorgabe ab, leitet den Update-Prozess selbstständig ein, sobald die Bedingungen erfüllt sind, und meldet den Status über den Statuskanal. Ein Gerät, das offline geht und sich wieder verbindet, setzt den Vorgang an der Stelle fort, an der es aufgehört hat, ohne dass der Server erneut Befehle ausgeben muss.

Für flottenweite Update-Kampagnen bedeutet dies, dass Sie keine Warteschlange mit ausstehenden MDM-Befehlen verwalten müssen. Sie legen die Absicht einmal fest, und die Geräte passen sich innerhalb der von Ihnen festgelegten Parameter nach ihrem eigenen Zeitplan an die Vorgaben an.

DDM im Kontext: Identitätsanbieter und SSO-Integration

Ein Bereich, in dem das Prädikatssystem von DDM einen erheblichen Mehrwert für Unternehmen bietet, ist die bedingte Konfiguration auf Basis des Identitätskontexts. Der traditionelle Anwendungsbereich von MDM ist relativ grob: Sie weisen Profilgruppen Gerätegruppen oder Benutzergruppen zu. DDM-Aktivierungen können detailliertere Bedingungen auswerten.

Praktische Beispiele für Unternehmensumgebungen:

• Wenden Sie strengere Passwortanforderungen auf Geräte an, bei denen das Benutzerkonto über privilegierten Zugriff verfügt, wobei die Bewertung auf der Grundlage von Verzeichnisattributen erfolgt
• Erzwingen Sie zertifikatsbasierte Authentifizierungskonfigurationen nur, wenn ein bestimmtes Zertifikat der Unternehmens-Zertifizierungsstelle vorhanden ist
• Aktivieren Sie VPN-Konfigurationsanweisungen je nachdem, ob das Gerät mit einem bestimmten Netzwerksegment verbunden ist

Diese bedingten Verhaltensweisen werden auf dem Gerät ausgeführt. Sie erfordern nicht, dass der Server die Geltungsbereichszuweisungen bei jeder Änderung einer Bedingung neu auswertet. Das Gerät verfolgt die Bedingung, wertet das Prädikat neu aus und passt seine Konfiguration eigenständig an.

Wie Iru das deklarative Gerätemanagement angeht

Die DDM-Implementierung von Iru ist nativ und keine nachträgliche Anpassung. Da Iru auf den Verwaltungs-APIs von Apple basiert, sind DDM-Deklarationen ein zentraler Bestandteil der Konfigurationsbereitstellung durch die Plattform und keine Zusatzfunktion, die auf einer veralteten MDM-Engine aufgesetzt ist.

Für Teams, die Tausende von Mac-, iPhone- und iPad-Geräten verwalten, macht dies in einigen spezifischen Bereichen einen praktischen Unterschied.

Erstens nutzt die Durchsetzung von Software-Updates über Iru DDM-Deklarationen für unterstützte Betriebssystemversionen, was bedeutet, dass Update-Kampagnen keine linear steigende Serverauslastung verursachen, wenn die Geräteflotte wächst. Bei mehr als 10.000 Geräten ist der Unterschied zwischen polling-basiertem und DDM-basiertem Update-Management in Bezug auf Infrastrukturkosten und Zeitaufwand für das IT-Team messbar.

Zweitens nutzt die Compliance-Engine von Iru den Statuskanal von DDM als Datenquelle für den Gerätestatus. Wenn ein Gerät über den Statuskanal eine Konfigurationsänderung meldet, fließt dieses Signal nahezu in Echtzeit in die Compliance-Dashboards ein. Sicherheitsteams erhalten präzise Statusdaten, ohne auf geplante Überprüfungen warten zu müssen.

Drittens besteht der Ansatz von Iru für die Übergangsphase von DDM zu älteren MDM-Systemen darin, beide Protokolle parallel zu betreiben: DDM wird dort eingesetzt, wo Apple es unterstützt, und ältere Befehle dort, wo sie noch erforderlich sind – ohne dass IT-Teams diese Unterscheidung manuell verwalten müssen. Da Apple die alten Befehle in iOS/macOS 26 und höher auslaufen lässt, bedeutet die DDM-native Architektur von Iru, dass der Übergang Konfigurationsänderungen erfordert, nicht jedoch einen Plattformwechsel.

Für Teams, die auch über einen umfassenderen Migrationspfad nachdenken, lohnt es sich, die Überlegungen zur Apple-MDM-Migration im Zusammenhang mit der DDM-Unterstützung bei der Bewertung einer MDM-Plattform sorgfältig zu prüfen.

Was IT-Teams jetzt tun sollten, um sich auf DDM vorzubereiten

Wenn Sie derzeit eine Apple-Geräteflotte verwalten und noch nicht damit begonnen haben, DDM in Ihre Verwaltungsstrategie zu integrieren, sollten Sie sich auf folgende Punkte konzentrieren.

Überprüfen Sie Ihre Betriebssystemverteilung. DDM erfordert iOS 15 / macOS 12 oder höher. Geräte unterhalb dieser Schwelle benötigen einen separaten Verwaltungsweg. Verschaffen Sie sich einen klaren Überblick darüber, mit wie vielen Geräten Sie es zu tun haben und welche Betriebssystemversionen diese derzeit nutzen. Dies wirkt sich direkt auf Ihren Prozess zur Hardware-Bestandsverwaltung aus.

Identifizieren Sie Ihre DDM-Anwendungsfälle mit höchster Priorität. Die Durchsetzung von Software-Updates und die kontinuierliche Sicherheitskonfiguration sind die besten Ansatzpunkte. Dies sind Bereiche, in denen das autonome Durchsetzungsmodell von DDM einen unmittelbaren, messbaren Mehrwert bietet.

Bewerten Sie den DDM-Reifegrad Ihrer MDM-Plattform. Stellen Sie konkrete Fragen: Nutzt die Plattform DDM-Deklarationen nativ für Software-Updates? Fließen die Statusmeldungen in Echtzeit in Compliance-Dashboards ein? Wie geht die Plattform mit der Übergangsphase um, in der einige Geräte DDM unterstützen und andere nicht? Wie bereitet sich die Plattform auf die Abschaffung veralteter Befehle durch Apple in iOS/macOS 26 vor?

Planen Sie Ihre Prädikatslogik. Die Umstellung auf geräteseitige bedingte Logik erfordert eine andere Herangehensweise an den Konfigurationsumfang. Anstelle der Frage „Zu welcher Gruppe gehört dieses Gerät?“ entwerfen Sie Prädikate, die das Gerät lokal auswertet. Ordnen Sie Ihre bestehende Richtlinienstruktur der DDM-Deklarationslogik zu, bevor Sie mit der Umsetzung beginnen.

Warten Sie nicht auf eine vollständige DDM-Abdeckung. DDM und veraltetes MDM existieren heute nebeneinander. Beginnen Sie damit, DDM dort einzusetzen, wo es verfügbar ist und einen Mehrwert bietet. Wenn Sie darauf warten, dass DDM in allen Punkten mit veraltetem MDM gleichwertig ist, verpassen Sie die betrieblichen Vorteile, die bereits jetzt verfügbar sind.

Die DDM-native Plattform von Iru wurde entwickelt, um diesen Übergang im Unternehmensmaßstab zu unterstützen. Wenn Sie sehen möchten, wie deklarative Konfigurationen in der Praxis für eine Geräteflotte Ihrer Größe funktionieren, nehmen Sie Kontakt mit Iru auf.