This is Part 3 of a three-part series on the architectural shift to Declarative Device Management. Part 1 covered the legacy polling bottleneck. Part 2 covered the client-side mechanics of Declarations, Configurations, Assets, and Activations.

This article focuses exclusively on the DDM Status Channel and delta reporting: how the MDM server subscribes to status items, how the device monitors those items, what a status update looks like, and why this eliminates the legacy polling tax for subscribed state.

The Status Channel Is Not Legacy Inventory

Traditional MDM often depends on repeated inventory or query cycles. The server asks for information, the device responds, and the server compares that response against the desired state. Even when nothing changed, the server still has to ask and evaluate.

The DDM Status Channel changes the reporting pattern.

Instead of repeatedly asking every device for broad state data, the MDM server declares which specific status items it cares about. The device then reports changes for those subscribed items.

For a Windows administrator, the closest conceptual comparison is an event subscription, not a recurring inventory scan. The server is no longer asking, “Send me everything so I can determine what changed.” The server is saying, “Tell me when this specific state changes.”

That distinction is the entire point of delta reporting.

Apple Status Item Names

Apple’s DDM status item names use lowercase dot paths, not older-looking CamelCase names.

Use names like:

device.operating-system.version
device.model.family
management.declarations
diskmanagement.filevault.enabled
passcode.is-present
passcode.is-compliant

Do not model new DDM content around names such as:

Device.PasscodePresent
Device.DiskEncryption.Status

Those are useful conceptual descriptions, but they are not the current DDM status item names used in Apple’s schema.

There is also an important platform nuance: not every status item exists on every Apple platform. For example, passcode.is-present is a real Apple status item, but it is not listed as a macOS status item in the current public schema. For macOS-focused examples, safer status items include device.operating-system.version, device.model.family, management.declarations, and diskmanagement.filevault.enabled.

Platform Parity and Scope

DDM is an Apple platform architecture, but status item coverage is not identical across macOS, iOS, iPadOS, tvOS, visionOS, and watchOS.

That matters operationally. A status item that is valid for iOS may not be available on macOS. A macOS status item may require a minimum macOS version. Some items may be available only in the system channel, while others may be available in the user channel. Vendor implementation timing may also vary as MDM platforms adopt newly published Apple capabilities.

For mixed fleets, validate every status item against:

• the Apple DDM schema,
• the minimum OS version in scope,
• the enrollment type,
• the management channel,
• and the MDM vendor’s implementation notes.

Do not assume that a logical state exists as a DDM status item just because it is visible somewhere else in inventory or in a vendor console.

Declaring Status Subscriptions

Status subscriptions are declared through a DDM Configuration declaration of type:

com.apple.configuration.management.status-subscriptions

The payload contains a StatusItems array. Each entry contains a Name value identifying a status item the device should report.

A macOS-focused example might look like this:

{
  "Type": "com.apple.configuration.management.status-subscriptions",
  "Identifier": "com.admincrossover.status.core-macos",
  "ServerToken": "core-macos-status-v1",
  "Payload": {
    "StatusItems": [
      {
        "Name": "device.operating-system.version"
      },
      {
        "Name": "device.model.family"
      },
      {
        "Name": "diskmanagement.filevault.enabled"
      },
      {
        "Name": "management.declarations"
      }
    ]
  }
}

This declaration does not ask the device to send a full recurring inventory report. It tells the device which specific pieces of state the MDM server wants to subscribe to.

For a Windows administrator, this is closer to registering for specific WMI state changes than running a full hardware inventory cycle every few hours.

What the Endpoint Monitors

After receiving a status subscription declaration, the device tracks the named status items locally.

For example:

device.operating-system.version

This allows the server to learn when the OS version changes.

diskmanagement.filevault.enabled

This allows the server to learn when FileVault enabled state changes on platforms that support that status item.

management.declarations

This allows the server to understand the device’s declaration state.

The key architectural point is that the endpoint is now responsible for monitoring the subscribed data points. The MDM server does not need to repeatedly query the entire fleet just to discover whether one of those values changed.

Initial Reports and Delta Reports

When a status subscription becomes active, the device sends an initial baseline report for the subscribed item on a Declarative Management check-in after that subscription is processed. This establishes the server’s starting value for the subscribed status item.

After that baseline exists, subsequent reports are delta reports. The device sends updated values when those subscribed values change. If a subscribed status item remains unchanged, the device does not need to report that same value again just to prove that nothing changed.

A practical lifecycle looks like this:

Server declares status subscription
        ↓
Device receives and processes declaration
        ↓
Device sends baseline status for subscribed item
        ↓
Device monitors subscribed item locally
        ↓
Value changes
        ↓
Device sends delta report
        ↓
Value remains unchanged
        ↓
No repeated status report is required for that item

This timing should not be interpreted as a guaranteed human-visible SLA. The important architectural point is that the report is tied to the DDM status-reporting flow after the subscription is active, not to an administrator-created recurring inventory script.

Delta Reporting

Delta reporting means the device reports meaningful changes instead of repeatedly sending unchanged state.

In the legacy model, a server might perform some version of this loop:

Ask device for state
Receive state
Compare state to desired state
Decide if anything changed
Repeat later

In the DDM Status Channel model, the loop becomes:

Subscribe to status item
Device monitors status item
Device detects change
Device sends status report
Server records new value

That eliminates the polling tax for subscribed status items.

This does not mean every possible MDM workflow becomes event-driven overnight. Devices still enroll, synchronize declarations, retrieve payloads, and perform other protocol operations. The point is narrower and more important: once the server subscribes to a status item, it no longer needs to repeatedly query that same value just to learn whether it changed.

The Protocol Shape of a Status Report

The status report JSON is the important data structure.

The transport path uses the standard MDM check-in protocol. In practice, the device initiates a Declarative Management check-in to the management service using an HTTP PUT request. The entire check-in is wrapped in an XML Property List (maintaining protocol continuity with legacy MDM), and the status report JSON is Base64-encoded and placed in the Plist’s <data> tag. This is like SOAP envelopes containing JSON-RPC (legacy transport, modern payload).

A simplified check-in wrapper looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>MessageType</key>
  <string>DeclarativeManagement</string>
  <key>Topic</key>
  <string>com.apple.mgmt.External.example</string>
  <key>UDID</key>
  <string>00000000-0000000000000000</string>
  <key>Endpoint</key>
  <string>status</string>
  <key>Data</key>
  <data>
  eyJTdGF0dXNJdGVtcyI6eyJkZXZpY2UiOnsib3BlcmF0aW5nLXN5c3RlbSI6eyJ2ZXJzaW9u
  IjoiMTUuNSJ9fX0sIkVycm9ycyI6W10sIkZ1bGxSZXBvcnQiOmZhbHNlfQ==
  </data>
</dict>
</plist>

When decoded, the Base64 Data field contains this JSON status report:

{
  "StatusItems": {
    "device": {
      "operating-system": {
        "version": "15.5"
      }
    }
  },
  "Errors": [],
  "FullReport": false
}

The MDM server receives the check-in request, identifies Endpoint as status, Base64-decodes Data, parses the JSON, and updates its record for the subscribed status item.

Understanding FullReport

The FullReport field tells the server whether the status payload should be interpreted as a complete status snapshot or an incremental report.

A normal delta report uses:

{
  "FullReport": false
}

That means the payload contains changed status information rather than a full snapshot of all subscribed state.

A full report uses:

{
  "FullReport": true
}

A full report is used when the device needs to establish or reestablish complete status context for the server. This can happen during initial state establishment, after subscription changes, or when the client and server need to resynchronize status state.

For day-to-day reporting, the important operational assumption is that FullReport: false is the common delta-reporting case. The device is not repeatedly sending a complete inventory-style snapshot just because a subscribed item exists.

Declaration State Reporting

Declaration state is reported through status items, not through a separate legacy inventory mechanism.

The most important example is:

management.declarations

If the server subscribes to management.declarations, the device can report state about declarations, including activations, configurations, assets, and management declarations.

A simplified declaration-state report might look like this:

{
  "StatusItems": {
    "management": {
      "declarations": {
        "activations": [
          {
            "identifier": "com.admincrossover.activation.standard-mac",
            "server-token": "standard-mac-v1",
            "valid": "valid",
            "active": true
          }
        ],
        "configurations": [
          {
            "identifier": "com.admincrossover.configuration.loginwindow-baseline",
            "server-token": "loginwindow-baseline-v1",
            "valid": "valid",
            "active": true
          }
        ],
        "assets": [],
        "management": []
      }
    }
  },
  "Errors": [],
  "FullReport": false
}

This does not mean every status report always includes declaration state. Declaration state is included when the relevant declaration status item is subscribed and when the device needs to report that state. If declaration state changes, such as an Activation becoming active or a Configuration becoming invalid, the device can report that updated declaration state through the subscribed status item.

The valid value describes whether the declaration is valid from the client’s perspective. The active value describes whether the declaration is currently active in the local declaration model. These values help the server understand not only that the device received a declaration, but whether the device is actually treating it as usable and active.

Why This Reduces Server Load

The status subscription model changes the server’s role.

In legacy MDM, the server often has to perform broad reconciliation:

Receive inventory
Load desired state
Compare current state to desired state
Calculate drift
Decide remediation
Update compliance

With DDM status subscriptions, the device can send a narrow update:

diskmanagement.filevault.enabled changed to true

That is a radically smaller unit of work.

The server does not need to reprocess a large inventory document to discover that one value changed. It receives the changed value directly through the subscribed status item.

At fleet scale, this matters because most endpoints are usually boring most of the time. A compliant Mac should not need to repeatedly prove the same unchanged state every few hours. Delta reporting lets the server spend less effort confirming that nothing changed and more effort reacting when something actually changes.

What “Eliminating the Polling Tax” Really Means

It is important to be precise. DDM does not eliminate all network communication between the device and the MDM server. It does not eliminate declaration synchronization, enrollment traffic, payload retrieval, or all traditional MDM operations.

What it eliminates is the legacy need to repeatedly poll subscribed state just to determine whether that state changed.

For subscribed status items, the architecture changes from this:

Server asks repeatedly:
  “What is your OS version?”
  “What is your FileVault state?”
  “What declarations do you have?”

to this:

Device reports when subscribed state changes:
  “My OS version is now 15.5.”
  “My FileVault enabled state is now true.”
  “My declaration state changed.”

That is the polling tax reduction.

Why This Completes the Architecture

DDM has three important architectural pieces:

1. The server declares desired state.
2. The device evaluates and enforces that state locally.
3. The device reports subscribed state changes back to the server.

Part 2 covered the second point: autonomous local evaluation and enforcement.

The Status Channel completes the loop by letting the server receive relevant state changes without falling back to constant broad polling.

This is the architectural benefit: the endpoint becomes both a desired-state engine and a targeted state reporter. The server remains authoritative, but it no longer has to calculate every delta from repeated full check-ins.

Conclusion

The DDM Status Channel is the reporting counterpart to declarative enforcement.

Status Subscriptions tell the device which state items matter. The device monitors those items locally. When a subscribed value changes, the device sends a status report through the Declarative Management check-in flow using Endpoint: "status" and Base64-encoded JSON in Data.

For senior Windows administrators, this is the difference between scheduled inventory polling and event-driven state reporting. The server no longer has to repeatedly ask every device whether the same subscribed value changed. The device tells the server when the change occurs.

That is why DDM is not merely a new payload format. It is a different management architecture.