What Is Declarative Device Management? (2026)

Declarative device management (DDM) is Apple's framework that lets devices enforce their own configurations locally, without waiting for server instructions. Introduced at WWDC 2021, it fundamentally changes the communication model between your MDM server and your Apple fleet.

If you manage macOS, iOS, or iPadOS devices at any meaningful scale, DDM is the most significant architectural shift in Apple device management since MDM was introduced in 2010. This guide covers what it is, how it works technically, where it fits alongside legacy MDM, and what you need to do about it before Apple's deprecation timeline forces your hand.

Why Traditional MDM Has Scaling Problems

To understand why DDM exists, you need to understand what's wrong with the protocol it's replacing. Traditional MDM works on a polling model. The server sends a command, the device executes it, the device reports back, the server sends the next command. Every status check, every configuration push, every software update instruction moves through this request-response loop.

At 50 devices, this is fine. At 5,000 devices, the server is fielding thousands of concurrent check-ins. At 50,000 devices, you're managing infrastructure just to manage your infrastructure. The model also creates compliance gaps: a device that can't reach the MDM server simply doesn't update its configuration, and the server won't know about the drift until the next successful check-in.

There's a more subtle problem too. Traditional MDM is stateless from the device's perspective. The device doesn't "know" what its intended state is. It just runs commands as they arrive. If a user changes a setting between MDM check-ins, the device sits in a non-compliant state until the server polls again and issues a correction.

To understand how device management works at the protocol level, this polling architecture is the core constraint DDM is designed to eliminate.

How Declarative Device Management Works

DDM inverts the management model. Instead of the server telling the device what to do step by step, the server sends the device a complete description of its intended state. The device stores that description locally and enforces it autonomously, even without a live server connection.

Here's what that looks like in practice. With traditional MDM, installing a configuration profile requires the server to send a command, wait for the device to acknowledge it, confirm the profile installed, and handle any errors. With DDM, the server sends a declaration that says "this device should have this configuration." The device takes ownership of making that true and maintaining it over time.

If a user removes a managed setting, the device restores it immediately, without waiting for the server. If the device is offline for three days, it continues enforcing its declared state. When it reconnects, it reports what happened during the gap through the status channel.

The Three Pillars: Declarations, Status Channel, and Extensibility

Apple's DDM architecture rests on three components. Every IT admin working with Apple devices needs to understand all three.

Declarations

Declarations are structured JSON documents that describe what a device should be and do. There are four declaration types:

• Configuration declarations: Define specific settings on the device, equivalent to configuration profiles in legacy MDM but stored and enforced locally. Examples include passcode policies, Wi-Fi settings, and VPN configurations.
• Asset declarations: Reference external resources that declarations depend on, such as credentials or certificates needed to activate a configuration.
• Activation declarations: Define predicates that determine when a configuration should apply. For example, "enforce FileVault only if the device is enrolled in the corporate identity provider." This conditional logic runs on the device, not the server.
• Management declarations: Handle enrollment-level information, including the device's enrollment properties and MDM service configuration.

The predicate system in activation declarations is one of DDM's most powerful and underappreciated features. Instead of the server running logic to decide which devices get which configurations, you push that logic to the device itself. A device enrolled in your finance department's scope can autonomously apply stricter encryption settings than a device in general operations, based on criteria evaluated locally.

Status Channel

The status channel is DDM's asynchronous reporting mechanism. Devices send status reports to the server when something meaningful changes, not on a polling schedule. If a device applies a declaration successfully, it reports that. If an activation predicate changes state, it reports that. If a software update installs, it reports that.

For IT teams, this changes how you think about fleet visibility. Instead of pulling status on a schedule, you receive a stream of change events. Your device inventory stays current in near real-time without generating server load proportional to fleet size. A 10,000-device fleet generates status traffic when things change, not 10,000 check-ins every 15 minutes.

This also transforms compliance monitoring. With legacy MDM, you discover drift at check-in. With DDM's status channel, the device tells you it detected and corrected drift, or that it detected drift it can't self-correct, immediately after it happens.

Extensibility

Extensibility allows the DDM framework to support new declaration types as Apple adds them across OS releases. Rather than requiring protocol changes each time Apple introduces new management capabilities, extensibility provides a standardized mechanism to add new configuration and status types.

This matters for long-term planning. As Apple continues expanding DDM support, your MDM platform can adopt new declaration types without requiring fundamental architectural changes. For IT teams evaluating MDM vendors, a platform with native DDM support built on extensibility principles will be significantly easier to maintain as Apple's management APIs evolve.

Declarative Device Management vs. Traditional MDM

The practical differences between DDM and traditional MDM affect daily operations in ways that matter to IT teams managing real fleets.

It's worth being clear about coexistence: DDM does not replace legacy MDM entirely, at least not yet. The two protocols run in parallel on enrolled devices. MDM commands still handle certain actions, enrollment flows still use traditional MDM channels, and some features haven't migrated to DDM yet. Apple has signaled that legacy commands for software updates, restrictions, and certain configurations will be deprecated in iOS/macOS 26 and later, making DDM the required path for those functions going forward.

OS Version Requirements for DDM

DDM support is tied to specific Apple OS releases. Before you build any management workflows around DDM, confirm your fleet's OS distribution:

• iOS 15 / iPadOS 15 / macOS 12 Monterey: Initial DDM support introduced
• iOS 16 / iPadOS 16 / macOS 13 Ventura: Expanded declaration types, software update management via DDM
• iOS 17 / iPadOS 17 / macOS 14 Sonoma: Additional configuration declarations, improved status reporting
• iOS 18 / iPadOS 18 / macOS 15 Sequoia: Continued expansion; additional legacy MDM commands flagged for deprecation
• iOS/macOS 26 and later: Significant legacy MDM command deprecations; DDM becomes the required path for software update enforcement and additional configuration types

If your fleet has devices running older OS versions, you'll need a hybrid approach during the transition period. Any device below iOS 15 or macOS 12 cannot use DDM at all and will require legacy MDM commands indefinitely, or you'll need to plan those devices out of your supported hardware.

Security Implications of DDM for Enterprise Compliance

DDM's autonomous enforcement model has direct implications for security posture that aren't obvious from a pure device management perspective.

With traditional MDM, a device's compliance state is a snapshot from the last check-in. A device that modifies a security configuration at 9am and checks in at 9pm has been non-compliant for 12 hours. In regulated environments operating under frameworks like NIST SP 800-53 or CIS Benchmarks for macOS, that gap is a control failure, even if it's temporary.

DDM closes that gap. Because the device enforces its own declared state continuously, the window between non-compliance and remediation is measured in seconds, not hours. The status channel records the event, giving you an audit trail that shows the deviation and the correction with timestamps.

For zero-trust architectures that rely on device posture signals to grant or deny access, this matters significantly. A device asserting compliance to a policy engine like an identity provider or SSO gateway needs to be providing accurate posture data. DDM's continuous local enforcement, combined with real-time status reporting, makes device posture signals more reliable than polling-based checks can achieve.

This ties directly into broader endpoint security strategy. If you're thinking about device management and security as integrated disciplines rather than separate functions, DDM's architecture is designed for that integrated model.

Software Update Enforcement with DDM

Software update management is where DDM's advantages are most immediately visible for enterprise IT teams and where Apple's deprecation timeline creates the most urgency.

With legacy MDM, enforcing a specific macOS version involves the server sending an update command, the device acknowledging it, the device downloading and staging the update, and the server polling to confirm success. If the device is offline during the scheduled window, the update doesn't happen. If a user defers, you're back to the server pushing another command.

DDM handles software updates through the Software Update configuration declaration. You declare the minimum acceptable OS version. The device evaluates its current state against that declaration, initiates the update process autonomously when conditions are met, and reports status through the status channel. A device that goes offline and reconnects picks up where it left off without the server needing to re-issue commands.

For fleet-wide update campaigns, this means you're not managing a queue of pending MDM commands. You declare intent once, and devices converge toward compliance on their own timelines within the parameters you set.

DDM in Context: Identity Providers and SSO Integration

One area where DDM's predicate system offers significant enterprise value is conditional configuration based on identity context. Traditional MDM scoping is relatively coarse: you assign profiles to device groups or user groups. DDM activations can evaluate more granular conditions.

Practical examples for enterprise environments:

• Apply stricter passcode requirements on devices where the user account has privileged access, evaluated based on directory attributes
• Enforce certificate-based authentication configurations only when a specific enterprise CA certificate asset is present
• Activate VPN configuration declarations based on whether the device is joined to a specific network segment

These conditional behaviors run on the device. They don't require the server to re-evaluate scope assignments every time a condition changes. The device tracks the condition, re-evaluates the predicate, and adjusts its configuration autonomously.

How Iru Approaches Declarative Device Management

Iru's implementation of DDM is native, not retrofitted. Because Iru was built around Apple's management APIs, DDM declarations are a core part of how the platform delivers configurations, not an add-on feature layered over a legacy MDM engine.

For teams managing thousands of Mac, iPhone, and iPad devices, this makes a practical difference in a few specific areas.

First, software update enforcement through Iru uses DDM declarations for supported OS versions, which means update campaigns don't generate linear server load as fleet size grows. At 10,000+ devices, the difference between polling-based update management and DDM-based update management is measurable in infrastructure cost and IT team time.

Second, Iru's compliance engine uses DDM's status channel as a data source for device posture. When a device reports a configuration change through the status channel, that signal feeds into compliance dashboards in near real-time. Security teams get accurate posture data without waiting for scheduled check-ins.

Third, Iru's approach to the DDM and legacy MDM transition period is to run both protocols in parallel, using DDM where Apple supports it and legacy commands where they're still required, without requiring IT teams to manage that distinction manually. As Apple deprecates legacy commands in iOS/macOS 26 and later, Iru's DDM-native architecture means the transition requires configuration changes, not platform changes.

For teams also thinking about the broader migration path, the Apple MDM migration considerations around DDM support are worth evaluating carefully when assessing any MDM platform.

What IT Teams Should Do Now to Prepare for DDM

If you're managing an Apple fleet today and haven't started incorporating DDM into your management strategy, here's where to focus.

Audit your OS distribution. DDM requires iOS 15 / macOS 12 or later. Devices below that threshold need a separate management path. Get a clear picture of how many devices you're dealing with and their current OS versions. This directly affects your hardware inventory management process.

Identify your highest-priority DDM use cases. Software update enforcement and continuous security configuration are the strongest starting points. These are areas where DDM's autonomous enforcement model provides immediate, measurable value.

Evaluate your MDM platform's DDM maturity. Ask specific questions: Does the platform use DDM declarations natively for software updates? Does the status channel feed into compliance dashboards in real-time? How does the platform handle the hybrid period where some devices support DDM and some don't? How is the platform preparing for Apple's legacy command deprecations in iOS/macOS 26?

Plan your predicate logic. The shift to device-side conditional logic requires thinking about configuration scoping differently. Instead of "which group does this device belong to," you're designing predicates that the device evaluates locally. Map your existing policy structure to DDM declaration logic before you start building.

Don't wait for full DDM coverage. DDM and legacy MDM coexist today. Start using DDM where it's available and provides value. Waiting for complete DDM parity with legacy MDM means missing the operational benefits available now.

Iru's DDM-native platform is built to support this transition at enterprise scale. If you want to see how declarative configurations work in practice for a fleet your size, start a conversation with Iru.