Every few months, someone asks us a version of the same question: "Apple already builds patch enforcement into every modern MDM — so why do we need anything else?"

It's a fair question, and the honest answer is: for a lot of your fleet, you don't. Apple's Declarative Device Management (DDM) framework is genuinely well-engineered, and for the share of Macs where people respond to a prompt within a day or two, DDM alone gets the job done. The problem is the rest of the fleet — the shared lab Mac, the laptop that's been closed since Tuesday, the contractor's machine that never quite got enrolled the way everyone assumed, the user who has learned exactly how long they can ignore a restart before anything actually happens. That's the part DDM was never going to solve by itself, and it's exactly where Proximos comes in.

This isn't an either/or story. Below, we'll cover what DDM does well, where it runs into real-world friction, four ways we see Proximos and DDM configured to work together, and why "we configured enforcement" and "we can prove every Mac is patched" turn out to be two different claims.

The stakes here are a little higher than they used to be, too. Mac and iPhone fleets keep growing inside organizations that historically ran Windows-first, and recent industry analysis puts a majority of large enterprises squarely in "expanding our Apple footprint" mode. At the same time, Apple has been retiring the older, command-based MDM workflows a lot of admins grew up on — at WWDC 2025, Apple confirmed that legacy, imperative software-update commands are being phased out during 2026 in favor of DDM. More Macs, and fewer paths to managing them the old way, means most IT teams don't get to opt out of building a real DDM strategy. The real question is what you pair it with.

What DDM Actually Does

DDM changes how your MDM and your Macs talk to each other. Under the older, imperative model, your MDM issues a one-off command — install this update, right now — and hopes the Mac happens to be in a state to comply at that exact moment. DDM flips that: instead of one-off commands, your MDM declares a desired end state ("this Mac should be running the latest update by next Tuesday at 6pm"), and the Mac takes responsibility for getting there on its own, checking its status and reporting back.

That local autonomy is the whole point. Apple's own deployment documentation describes devices that keep attempting an update independently, detect when they've missed a declared deadline, and resume automatically once conditions allow — without the MDM needing to re-issue anything. Status reporting improves along with it: rather than a black box, admins get visibility into whether a given Mac is waiting, downloading, preparing, or installing, plus specific error conditions when something blocks the process, such as being offline or low on battery or storage.

Software update enforcement through DDM has been available since macOS Sonoma (14), with more granular controls — enforcement scheduling, notification behavior — arriving in macOS Sequoia (15) and later. Critically, for a Mac to get the fully hands-free version of this, with unattended installs and restarts and nobody sitting at the keyboard, Apple's guidance is explicit that the device needs a bootstrap token, which in practice means it needs to have gone through Apple Business Manager (ABM) enrollment. That one requirement explains most of the gap between how DDM is supposed to work and how it actually behaves on any Mac that falls outside a clean ABM pipeline.

Where DDM Earns Its Reputation

• It comes straight from Apple. Enforcement instructions run through Apple's own framework rather than a third-party agent sitting on top of macOS. For security and compliance teams doing vendor reviews, that provenance is worth something — there's no extra software supply chain to explain.
• It's effectively free. If your MDM already supports DDM, software update enforcement comes with it — no separate licensing tier required.
• It nudges people too. DDM isn't silent, background-only enforcement; Apple builds in a countdown and recurring reminders ahead of the deadline, much like Proximos's own daily notifications.
• Cooperative users have a smooth experience. For the large share of a fleet that responds to prompts promptly, DDM's install flow just works, with no third-party software involved at all.
• Setup is refreshingly simple. A DDM software update policy is typically a handful of fields in your MDM console — no scripting, no extra servers, no additional infrastructure.

The Real World Has Other Plans

Everything above is true, and none of it changes the fact that a meaningful share of enforcement attempts never finish. In practice, the reasons cluster into four groups.

Infrastructure you may not have

Not every MDM platform has caught up. Several RMM-first tools popular with MSPs — including SolarWinds N-able and NinjaOne, among others — still don't implement Apple's DDM framework at all as of this writing, and support varies considerably from platform to platform. If your MDM hasn't built it, nothing else here is available to you regardless of which patch strategy you choose. (Worth a periodic check on your own stack — DDM support has been rolling out unevenly, and a platform that lacked it last year may have added it since.)

The human factor

Even where DDM is fully supported, it still generally needs a person to authenticate the update with their password, and DDM doesn't remove that requirement. If someone simply declines to enter it, the update typically doesn't proceed. DDM's patience isn't infinite in practice, either — our own field experience suggests that when a user avoids enforcement for roughly a week or more, DDM can effectively stop attempting the install altogether, leaving that Mac out of compliance with no further automatic retries, often with nothing flagging it anywhere.

DDM Limitations

A handful of device-state conditions, each independently capable of stalling an otherwise well-configured enforcement:

• DDM Updates will not install if The MacBook lid is closed.
• DDM Updates will not install if the Mac was shut down rather than left on and awake — unlike Windows, macOS won't force an update through at shutdown.
• DDM Updates will not install if the Mac's battery charge is below roughly 50%.
• DDM Updates will not install applications are open with unsaved documents.
• DDM Updates will not install another user is still signed in, as on a shared lab or concierge Mac.

Individually, each looks like an edge case. Add them up across a real fleet — remote workers, shared machines, people who close their laptop the second a meeting ends — and "edge case" starts looking like most Tuesdays.

Compliance you can't fully own

One more gap worth naming: DDM's notifications belong to Apple, not to you. You can't brand them, adjust their language, or tailor them to whatever specific compliance-notice wording your legal or compliance team needs on record.

Proximos + DDM: Two Layers, One Strategy

None of the above is an argument against DDM. It's an argument against asking DDM to do a job it was never fully designed to finish alone. The strongest patch compliance setups we see pair DDM's native, Apple-backed enforcement with Proximos's user-facing communication and telemetry layer, running side by side rather than competing for the same job.

That pattern shows up elsewhere in the Apple admin community too, not just in our own deployments. At JNUC 2025, NetApp's IT team described their own patch compliance journey: roughly 30% adoption using legacy, command-based MDM tools alone, climbing to about 80% once user-facing notifications were layered on top, and landing around 90% once notifications and DDM were running together — inside a two-to-four-week window. The tooling in that story isn't identical to a Proximos deployment, but the shape of the result is the same: notification plus enforcement consistently beats either one alone.

We typically see four configurations in practice:

The Part Most Teams Miss: Configured Isn't the Same as Confirmed

Here's the distinction that tends to get lost in patch management conversations: setting up an enforcement policy — in DDM, in Proximos, in anything — tells you what you intended to happen. It doesn't tell you what actually happened. Every failure mode above (a closed lid, a dead battery, a user who's learned to outlast a countdown, the quiet way DDM can stop retrying after about a week) produces the same symptom from the outside: a Mac that looks compliant on your dashboard because a policy is assigned to it, and isn't compliant at all.

That gap used to be mostly an internal housekeeping problem. It isn't anymore. Cyber insurance renewals and compliance audits have moved noticeably in the same direction: underwriters increasingly ask for documented patch SLAs and dated proof of remediation rather than a policy statement, and stalled reboots that leave updates unapplied are called out repeatedly in recent audit guidance as exactly the kind of gap that shows up during review — which is precisely the failure mode a closed lid or a dead battery produces. The same shift shows up with regulators and auditors more broadly: "we have a policy" is rarely the answer they're looking for. They want to know what's actually installed, on which machines, as of when.

That's the case for building visibility in from the start instead of bolting it on after an incident. A Custom Pending Update Command and a Custom Past Due Command aren't just automation conveniences — they're the mechanism that turns "we configured enforcement" into "we can show you, per device, what's installed, what's pending, and how long it's been pending." That's the difference between clearing a renewal questionnaire on the first pass and scrambling to reconstruct your compliance history after the fact.

If there's one thing to take from this, it's this: don't just ask whether your fleet is enforced. Ask whether you could prove, right now, exactly which Macs are patched — and how you'd find out if one quietly fell out of compliance a week ago.

Bringing It Together

DDM is a legitimate, well-built part of Apple's platform, and there's no reason to route around it for the large share of your fleet where it just works. The case for Proximos was never "replace DDM" — it's "cover what DDM was never going to solve alone":

• Proximos is your base layer. Powerful, trusted, brandable, customizable compliant.
• Real-world conditions will always leave a gap. Closed lids, dead batteries, shared Macs, and people who've learned to wait out a countdown aren't going away.
• DDM as a backup — DDM can install late at night when the user isn't avoiding enforcement.
• Configured isn't confirmed. The goal isn't a policy that's assigned; it's an answer you can produce on demand, per device, about what's actually installed.

If you're weighing how to combine Proximos and DDM for your own environment, that's exactly the kind of conversation our team is set up to have.