Deep Dive: Understanding Declarative Device Management – The Future of Apple MDM

Apple in Business, Device Deployment & Management / Leave a Comment

Introduction: The Evolution and Urgency of Apple Device Management

Apple’s Declarative Device Management (DDM) represents the most significant shift in enterprise Apple device management since the introduction of the Mobile Device Management (MDM) framework in iOS 4. For organizations managing Apple devices through Workspace ONE UEM, understanding and implementing DDM is no longer optional—it’s critical for continued operations.

⚠️ Mandatory Migration Deadline

Apple announced at WWDC 2025 that legacy MDM software update commands are deprecated in OS 26 (releasing September 2026) and will be completely removed in 2027 OS versions. Organizations must migrate software update management to DDM immediately. This gives enterprises approximately 12-18 months to complete their migration before traditional MDM update methods stop functioning entirely.

This article explores what DDM means for enterprise Workspace ONE UEM environments, how it fundamentally differs from traditional MDM, and provides step-by-step implementation procedures to prepare your organization for this mandatory transition.

What is Declarative Device Management?

Understanding the Paradigm Shift

Traditional MDM operates on a reactive, command-response model. The management server sends individual commands to devices, waits for acknowledgment, and continuously polls devices to maintain current status information. This approach has served enterprises for over a decade but creates significant limitations:

Traditional MDM Limitations DDM Improvements
Constant network connectivity required Works effectively offline or with intermittent connectivity
Server continuously polls thousands of devices Event-driven reporting only when state changes
Devices cannot make intelligent decisions Device autonomy with local decision-making
Configuration drift when disconnected Self-healing maintains desired state continuously
High server load and network overhead 70-80% reduction in server-device traffic
Delayed policy application Immediate configuration with intelligent timing

The Declarative Approach

DDM fundamentally changes this model by shifting from “how to configure” to “what the desired state should be.” Instead of sending step-by-step commands, administrators declare the desired device state, and devices autonomously work to achieve and maintain that state.

Think of it like this:

  • Traditional MDM: “Install this certificate, then configure the VPN with these settings, then enable FileVault, then report back each step’s status”
  • Declarative DDM: “Here’s the desired state: certificate installed, VPN configured, FileVault enabled. Device, make it happen and report when complete or if problems occur”

The device becomes an intelligent agent that:

  • Applies configurations independently based on its current state
  • Self-heals when configurations drift from desired state
  • Reports status changes asynchronously only when relevant events occur
  • Operates effectively even when offline or with intermittent connectivity
  • Re-evaluates policies automatically when device state changes

Apple’s Three Pillars of Declarative Device Management

Apple officially describes DDM as having three core pillars that work together to create a more efficient, scalable, and responsive management framework:

Pillar 1: Declarations

Declarations are the policies that define what your devices should look like. Unlike traditional configuration profiles sent as PLIST files, declarations use JSON format and come in four distinct types:

1. Configurations

The actual policies applied to devices (similar to traditional configuration profiles but with DDM intelligence)

Examples: Passcode requirements, Wi-Fi settings, VPN configurations, account settings, restrictions

2. Assets

Supporting data that configurations reference

Examples: User identity information, credentials, certificates

Benefit: One asset can be referenced by multiple configurations, eliminating duplication

Example Use Case: A user identity asset containing email/name can be referenced by Exchange, Wi-Fi (for certificate authentication), and VPN configurations

3. Activations

Define WHEN configurations should apply

  • Combine multiple configurations into logical groups
  • Use predicates (conditional logic) to determine if configurations activate
  • Example: “Apply these configurations only if device type = iPad AND OS version >= 16.0”
  • Support many-to-many relationships: one activation can reference multiple configurations
  • All configurations in an activation must be valid for any to apply (atomic application)

4. Management

Meta-information about the MDM environment

  • Organization details
  • Server capabilities
  • Status subscription configurations
Important Relationship: Activations sit between the MDM server and Configurations. The server sends all declarations to the device, and the device uses Activations with their predicates to determine which Configurations actually apply. This allows devices to make intelligent decisions locally without constant server communication.

Pillar 2: Status Channel

The status channel revolutionizes how devices communicate with the MDM server. Instead of the traditional polling model where servers constantly ask “has anything changed?”, devices proactively report status updates when relevant events occur.

Key Characteristics:

  • Asynchronous reporting: Devices send updates only when state changes (app installed, OS updated, profile applied, compliance violation)
  • Subscription-based: MDM server subscribes only to specific status items it cares about
  • Real-time updates: Administrators see current device state immediately without waiting for scheduled check-ins
  • Reduced server load: Eliminates constant polling of thousands of devices
  • Event-driven: Triggers can be used in activation predicates, allowing devices to respond to their own state changes

Pillar 3: Extensibility

The DDM protocol is designed to grow and evolve without breaking existing implementations. Both devices and MDM servers communicate their capabilities, allowing:

  • New features to be adopted immediately when available
  • Graceful handling of devices with different OS versions
  • Forward compatibility as Apple adds DDM capabilities
  • Workspace ONE UEM’s direct integration with Apple’s GitHub repository for automatic DDM payload support

Workspace ONE UEM DDM Support and Requirements

Current DDM Support Status (January 2026)

iOS/iPadOS Support Timeline:
  • Tech Preview: Version 2306 (September 2023)
  • General Availability: Version 2406 (August 2024)
  • Full Support: Version 2506 Patch 3 and later
  • Supported OS: iOS/iPadOS 16 and later for full DDM (iOS 15+ for initial support)
macOS Support Timeline:
  • Initial Release: Version 2410 (October 2024)
  • Supported OS: macOS Ventura (13) and later (macOS Sonoma 14+ recommended)

⚠️ Critical Prerequisites

1. Workspace ONE UEM Modern SaaS Architecture

  • DDM requires the modern architecture (also called “ModStack”)
  • This microservices-based platform was released with version 2406
  • Your environment must have modern architecture enabled
  • Check with your Workspace ONE administrator if unsure

2. Minimum Version Requirements

  • Workspace ONE UEM: Version 2410 or later (2506 Patch 3+ recommended)
  • iOS/iPadOS: Version 16 or later
  • macOS: Ventura (13) or later

3. Device Enrollment

  • Devices must be enrolled in Workspace ONE UEM
  • All enrollment types supported (DEP/ADE, User Enrollment, Device Enrollment)

4. Administrator Permissions

  • Full admin access to Workspace ONE UEM console
  • Access to Resources > Profiles > Add Profile

Currently Supported DDM Configurations in Workspace ONE UEM

Platform Supported DDM Configurations
iOS/iPadOS Passcode Policy
Software Update Enforcement
CalDAV (Calendar) Account
CardDAV (Contacts) Account
LDAP Account
Calendar Subscription
Exchange Account
Google Account
User Identity Asset
macOS Passcode Policy
Software Update Enforcement
(Additional configurations rolling out progressively)
Note: Workspace ONE UEM uses direct GitHub integration with Apple’s DDM repository, automatically importing new DDM payloads as Apple releases them. This means Day 0 support for new DDM capabilities as they’re announced.

Step-by-Step: Implementing DDM in Workspace ONE UEM

Example 1: Creating a DDM Passcode Policy for iOS/iPadOS

This walkthrough demonstrates creating your first declarative configuration—a passcode policy that devices will autonomously enforce.

1. Navigate to Profile Creation
  1. Log in to your Workspace ONE UEM console
  2. Navigate to Resources > Profiles
  3. Click ADD button
  4. Select Add Profile
2. Select Platform and Management Type
  1. From the platform dropdown, select iOS
  2. Critical Selection: Under “Management Type”, you’ll see two options:
    • Imperative (traditional MDM profiles)
    • Declarative (DDM declarations)
  3. Select DECLARATIVE
  4. From “Declaration Type” dropdown, select CONFIGURATION
  5. From “Context” dropdown, select DEVICE (configurations apply at device level)
  6. Click NEXT
3. Configure the Profile Details

General Tab:

  • Name: Enter descriptive name (e.g., “iOS – DDM Passcode Policy”)
  • Description: Optional but recommended (e.g., “Declarative passcode requirements for all iOS devices”)
4. Add Passcode Configuration
  1. In the payload search field, type “Passcode”
  2. Click ADD next to “Passcode” in the search results
  3. The Passcode policy section will expand
  4. Configure your passcode requirements:
    • Check Require Passcode (essential)
    • Minimum Passcode Length: 8 (recommended minimum)
    • Require Alphanumeric Value: Enable (forces letters and numbers)
    • Minimum Number of Complex Characters: 1
    • Maximum Passcode Age (days): 90
    • Auto-Lock (minutes): 5
    • Passcode History: 5 (prevents reuse of recent passcodes)
    • Maximum Number of Failed Attempts: 10
    • Grace Period for Device Lock: 0 (require passcode immediately)
  5. Click NEXT
5. Assignment
  1. In the Assignment screen, search for your target Smart Group
  2. Select the appropriate Smart Group (e.g., “All iOS Devices” or “Corporate iPhones”)
  3. Click ADD
  4. Deployment Type: Leave as “Auto” (configuration will deploy immediately upon save)
6. Review and Publish
  1. Review your configuration summary
  2. Click SAVE & PUBLISH

✅ What Happens Next

  • Workspace ONE UEM sends the DDM declaration to assigned devices
  • Devices running iOS 16+ receive the declaration
  • Device Intelligence: The device evaluates the declaration and autonomously:
    • Checks current passcode settings against requirements
    • If non-compliant, prompts user to update passcode
    • Continuously monitors passcode configuration
    • Self-healing: If user later disables passcode or changes settings to non-compliant values, device automatically prompts for correction
  • Device reports status through status channel when:
    • Declaration successfully activated
    • User complies with passcode requirements
    • Compliance violation occurs
7. Verify Deployment
  1. Navigate to Devices > List View
  2. Select a device from your assigned Smart Group
  3. Click on device name to open Device Details
  4. Look for Declarations section (may be under “Profiles” or dedicated DDM section depending on Workspace ONE version)
  5. Verify your DDM declaration appears with status “Activated”
Monitoring on the Device: Users can see applied DDM declarations on their devices:

  • iOS/iPadOS: Settings > General > Device Management > [Your Organization]
  • Under “Configurations” section, DDM declarations are listed
  • Traditional profiles appear separately under “Profiles”

Example 2: Software Update Enforcement with DDM

Software update enforcement is DDM’s most critical capability, especially given Apple’s deprecation of traditional MDM update commands in OS 26.

⚠️ Why This Matters

Traditional MDM software update commands will stop working in 2027. Organizations must implement DDM software update enforcement to maintain the ability to manage OS updates on Apple devices. This is not optional—it’s a compliance and security imperative.

1. Create DDM Update Profile

  1. Navigate to Resources > Profiles > ADD > Add Profile
  2. Select platform: iOS or macOS (process is identical for both)
  3. Select DECLARATIVE for Management Type
  4. Select CONFIGURATION for Declaration Type
  5. Select DEVICE for Context
  6. Click NEXT
Configure Profile Details

2. Configure Profile Details

  • Name: “iOS – Software Update Enforcement – 17.2” (be specific about target version)
  • Description: “Forces iOS 17.2 installation by [date]”

3. Add Software Update Enforcement Configuration

  1. Search for “Software Update” in the payload search
  2. Click ADD next to “Software Update Enforcement”
  3. Configure enforcement settings:
    Target OS Version:
    • Enter the target OS version: “17.2” (for iOS) or “14.2” (for macOS)
    • This tells the device which OS version should be installed
    Target Build Version (Optional but Recommended):
    • Enter specific build number if targeting particular security updates
    • Example: “21C62” for iOS 17.2
    • Find build numbers at Apple’s support site or in software update catalogs
    Target Local Date Time:
    • This is the deadline when the update MUST be installed
    • Format: YYYY-MM-DDTHH:MM:SS
    • Example: “2026-02-15T02:00:00” (February 15, 2026 at 2:00 AM local time)
    • Important: Uses device’s local timezone, not server timezone
    Details URL (Recommended):
    • Provide URL with update information for users
    • Example: “https://support.apple.com/en-us/HT213550”
    • Users can click this for more information about the update
  4. Click NEXT

4. Assign to Smart Groups

  1. Select target Smart Groups
  2. Best Practice: Start with pilot group, then expand
    • Week 1: IT department devices
    • Week 2: Early adopter group
    • Week 3+: Full deployment
  3. Click SAVE & PUBLISH

Understanding DDM Update Behavior

DDM software update enforcement is significantly more sophisticated than traditional MDM commands:

7+ Days Before Deadline
  • Device automatically checks for update availability
  • Downloads update in background during optimal times (plugged in, Wi-Fi, sufficient battery)
  • User sees notification: “A software update is available”
  • User can choose:
    • Install Now – Begin update immediately
    • Try Tonight – Schedule for overnight installation (if charging)
    • Defer – Postpone notification (will return later)
3-7 Days Before Deadline
  • Notifications become more frequent
  • User still has flexibility to install at convenient time
  • Background download continues if not yet complete
1-3 Days Before Deadline
  • Daily notifications
  • Message indicates enforcement is approaching
  • Strong encouragement to install before deadline
On Deadline Date/Time
  • If update not installed voluntarily:
    • Device forces installation at specified date/time
    • 1-hour warning notification
    • Final 60-second countdown
    • Automatic restart and installation
  • Device Autonomy: If first installation attempt fails (battery too low, insufficient storage, etc.):
    • Device retries within 1 hour
    • Notification: “Update installation overdue”
    • Continues retry loop until successful
    • This self-healing happens without server intervention

Key Advantages Over Traditional MDM:

  • User Experience: Escalating notifications give users control until deadline
  • Intelligence: Device chooses optimal installation times based on usage patterns
  • Reliability: Automatic retry on failure without administrator intervention
  • Efficiency: No constant server polling—device manages its own state
  • Visibility: Real-time status updates through status channel

Migration Strategy: Traditional MDM to DDM

Critical Timeline and Planning

⏰ Apple’s Deprecation Schedule

  • June 2025: Deprecation announced at WWDC
  • September 2026: OS 26 releases with deprecated MDM update commands
  • 2027: Complete removal in OS 27—traditional update commands stop functioning

Enterprise Migration Timeline (Recommended)

Q1 2026 (January – March): Planning and Preparation
  • Audit all existing MDM update policies and profiles
  • Identify devices and groups requiring update management
  • Document current update schedules and enforcement policies
  • Ensure Workspace ONE UEM version meets minimums (2410+)
  • Verify modern architecture enabled
  • Identify pilot groups (IT department, early adopters)
Q2 2026 (April – June): Pilot Deployment
  • Create equivalent DDM software update enforcement configurations
  • Deploy to pilot groups (50-100 devices)
  • Test enforcement scenarios:
    • Voluntary early installation
    • Approaching deadline notifications
    • Deadline enforcement
    • Retry behavior on failure
  • Gather user feedback on notification experience
  • Adjust deadlines and notification strategies based on feedback
Q3 2026 (July – September): Production Rollout
  • OS 26 releases in September—urgency increases
  • Phase 1: Deploy to early adopter groups (10-15% of fleet)
  • Phase 2: Department-by-department rollout
  • Phase 3: Complete organization deployment
  • Monitor compliance through DDM dashboards
  • Do not remove traditional MDM profiles yet—hybrid operation period
Q4 2026 (October – December): Cleanup and Optimization
  • Verify 100% DDM coverage for update management
  • Begin removing traditional MDM update profiles (device-by-device verification)
  • Optimize enforcement timelines based on experience
  • Document lessons learned
Q1 2027 (January – March): Pre-OS 27 Verification
  • Final verification all devices using DDM for updates
  • Remove ALL remaining traditional MDM update profiles
  • OS 27 beta testing begins—traditional commands disabled
  • Emergency rollback procedures in place if needed
Q2 2027 and Beyond
  • OS 27 releases—traditional update commands no longer function
  • 100% DDM-based update management
  • Expand DDM usage to other configuration areas

Coexistence: Running DDM and Traditional MDM Together

Current State (2026): DDM and traditional MDM profiles coexist on devices simultaneously. This hybrid period is necessary and supported by Apple.

Important Precedence Rules:

Scenario Behavior
Software Updates
Both DDM and traditional MDM update policies present		 DDM declarations take precedence
Traditional MDM commands are ignored
Device follows DDM enforcement schedule
Other Settings
(Passcode, Restrictions, etc.)
Same setting in both DDM and traditional profile		 Most restrictive setting wins
Similar to traditional multiple-profile behavior
Example: DDM requires 8-char passcode, traditional requires 10 chars → Device enforces 10 characters

Best Practice During Migration:

  1. Create DDM configuration
  2. Test on pilot devices
  3. Verify DDM configuration working as expected
  4. Deploy to production
  5. After verification (1-2 weeks), remove equivalent traditional profile
  6. Never remove traditional profile before confirming DDM working

Monitoring and Troubleshooting DDM Deployments

Verifying DDM Declaration Status

Console-Level Monitoring:

Compliance Dashboard
  1. Navigate to Monitor > Dashboards > Compliance
  2. Filter by “Declaration Status” (option available in DDM-enabled environments)
  3. View aggregate compliance across DDM declarations
Device List View
  1. Navigate to Devices > List View
  2. Add column: “DDM Declarations” (customize columns if not visible)
  3. Shows count of active declarations per device
  4. Filter to devices with failed declarations

Device-Level Verification:

  1. Navigate to specific device: Devices > List View > [Select Device]
  2. Device Details Page will show:
    • Profiles Section: Traditional MDM profiles
    • Declarations Section: DDM declarations with status
    • Status Values:
      • Activated: Declaration successfully applied and currently enforced
      • Pending: Declaration received but waiting for conditions
      • Failed: Declaration could not be applied (expand for error details)
  3. Detailed Declaration View:
    • Click on specific declaration name
    • View payload details
    • See timestamp of last status update
    • Review error messages if failed

Common Issues and Resolutions

Issue 1: Declaration Shows “Pending” Status
Symptoms: Declaration deploys but never activates on device
Common Causes:

  • OS version too old (device must be iOS 16+ or macOS 13+)
  • Modern architecture not enabled on Workspace ONE tenant
  • Device enrollment predates DDM support—requires re-enrollment
  • Activation predicate conditions not met

Resolution Steps:

  1. Verify device OS version meets minimums
  2. Confirm Workspace ONE UEM version and modern architecture status
  3. Check device enrollment date—if before August 2024, consider re-enrollment
  4. Review any predicate conditions in the declaration
  5. Check device connectivity—initial declaration receipt requires network
Issue 2: Software Update Not Enforcing at Deadline
Symptoms: Deadline passes but device doesn’t force update installation
Common Causes:

  • Insufficient storage space on device
  • Battery level below threshold (< 50% and not charging)
  • Device powered off at deadline time
  • Conflicting traditional MDM update profile

Resolution Steps:

  1. Check for conflicting profiles:
    • Navigate to device Profiles tab
    • Look for traditional “Software Update” or “Restrictions” profiles
    • Remove traditional profiles (DDM takes precedence, but cleanup prevents confusion)
  2. Verify device readiness:
    • Check device storage availability (need 5-7GB free)
    • Confirm battery level or power state
    • Device must be powered on at deadline
  3. DDM Retry Behavior:
    • Device automatically retries every hour if conditions not met
    • No administrator action required
    • Monitor device for “Update Overdue” notifications
  4. Verify declaration configuration:
    • Check Target Local Date Time is correct
    • Ensure timezone matches device location
    • Confirm Target OS Version is available from Apple

Conclusion: Preparing for the DDM-First Future

Declarative Device Management represents the most significant evolution in Apple device management since MDM’s introduction. For Workspace ONE UEM administrators, the transition from traditional MDM to DDM is not merely a technical upgrade—it’s a mandatory migration with a hard deadline.

Key Takeaways:

  1. Urgency: Organizations must migrate software update management to DDM by 2027. Traditional MDM update commands will stop functioning.
  2. Timeline: Start planning immediately. Pilot deployment in Q2 2026, complete production rollout by end of Q4 2026, final cleanup in Q1 2027.
  3. Requirements: Ensure Workspace ONE UEM version 2410+, modern architecture enabled, and devices running minimum supported OS versions.
  4. Benefits: Beyond compliance necessity, DDM offers superior reliability, reduced server load, better user experience, and enhanced security.
  5. Coexistence: DDM and traditional MDM work together during transition. Test thoroughly before removing traditional profiles.
  6. Expansion: Start with mandatory software updates, then expand to passcode policies, account configurations, and advanced use cases.

The future of Apple device management is declarative. Organizations that embrace this shift early, plan methodically, and execute systematically will be best positioned to maintain compliant, secure, and efficiently managed Apple device fleets.

The time to begin your DDM migration is now.

Must Read

Leave a Comment

Your email address will not be published. Required fields are marked *