Supported mechanism to provision Accessibility for an MDM-managed security agent on supervised macOS 27, after PPPC removal

Hey everyone,

Just wanted to chime in and say our team is hitting the exact same wall with macOS 27.

We build an enterprise observability agent deployed via MDM, and the only reason we touch Accessibility APIs is to read the active foreground window title for session analytics. Everything else in our agent works fine without special permissions.

The move from silent PPPC payloads to consent-based DDM (com.apple.configuration.app.settings) creates two massive headaches for us:

IT loses enforcement: On supervised corporate Macs, admins need to guarantee required telemetry is running. Giving end-users a prompt where they can just click "Not Now" or decline completely undermines fleet-wide compliance.

Background daemons have no GUI: Our agent runs as a headless launchd system service, not a user-facing AppKit app. A consent flow designed around interactive application launches leaves background services completely stranded—there's no UI to trigger or catch the prompt.

Is there any supported, non-interactive route planned for supervised/ADE devices to grant Accessibility to signed enterprise binaries?

And if DDM really is the only path Apple is giving us, how are headless background daemons expected to handle this when there's no UI layer to prompt the user in the first place?

We have also logged this feedback via Feedback Assistant: FB24264150

We have also filed this as an enhancement request via Feedback Assistant (FB23531820).

Thanks!

We have also logged this feedback via Feedback Assistant: FB24264150

Ditto.

IMO this is the right path forward for this.

There’s no doubt that this change was deliberate. It also seems that it’s broken a number of well-trodden device management paths. The best way to let the relevant engineering team know about those issues is via Feedback Assistant.

Have you folks tried this with the just-released macOS 27.0b5? In some other context I’ve learnt that it has significant changes in this space, and I’m not sure whether those also impact this issue.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

Thanks for the quick response as always—really appreciate your insights here.

We haven't tested against macOS 27.0b5 yet, so I've asked our QA team to roll it into our nightly test environments. It'll probably take a day or two to get solid results (fingers crossed!), but I'll make sure to follow up here as soon as we have data.

Hi Quinn and everyone following this,

Following up as promised. Our QA team just finished retesting against macOS 27.0 beta 5 (build 26A5406e).

The end result hasn't changed (silent Accessibility grants via PPPC profiles still don't work), but the OS behavior subtly shifted in a way that's actually trickier for IT admins.

In earlier betas, the Accessibility entry was stripped out of the profile entirely. In beta 5, the profile payload installs cleanly and looks completely valid in the UI, only that it’s just silently ignored by the OS when applying TCC rules.

What we're seeing:

• Checking live applied overrides via:

sudo plutil -p /Library/Application Support/com.apple.TCC/MDMOverrides.plist

shows that other permissions from the same PPPC profile (like Full Disk Access / kTCCServiceSystemPolicyAllFiles) apply as expected.

• However, kTCCServiceAccessibility is silently omitted from MDMOverrides.plist.

• Our helper process logs confirm it immediately. The helper process is not trusted by the Accessibility framework.

This creates a silent failure mode for admins. An MDM audit will show the PPPC profile as complete and active on the endpoint, even though the OS is silently discarding the Accessibility payload behind the scenes.

I really hope someone from the relevant engineering team is reading this, as the situation is now actually worse.

Ah, OK, sorry that I wasn’t clearer about this. I was referring to the replacement side of things, that is, the Accessibility property within the AppSettings value. Have you tried that out on 27.0b5?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Oh, thanks for the heads-up!

We have not yet tried that. I passed your hint to our QA team, they are going to give it a try. I'll report back as soon as I can.

Thanks!

So we tested the above with the latest beta and ran into the following:

• Current behavior on Beta 5: Legacy MDM PPPC profiles are accepted but ignored, and manual granting in System Settings no longer works.

• Declarative Schema problems: We looked into switching to DDM (com.apple.configuration.app.settings), but the schema explicitly states it is AppKit-only and requires a launch-time consent prompt.

Since our product is a UI-less background agent (no AppKit UI, no user launch moment for a prompt to display), how is Declarative Device Management intended to grant Accessibility permissions to background services/daemons?

Is there a different declaration type planned for non-AppKit agents, or is maybe the behavior on beta 5 a defect?

Long story short, we could not make it work.