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

Question

Created Jul ’26

Replies 3

Boosts 4

Views 1.1k

Participants 3

We develop an endpoint security agent that customer IT deploys and manages via MDM on supervised, ADE-enrolled Macs. The agent requires Accessibility permissions to perform core security functions.

Historically, IT provisioned this via the PPPC payload which granted Accessibility as a managed control without end-user interaction. In macOS 27 this path for Accessibility has been removed. The documented replacement — the Privacy key in com.apple.configuration.app.settings — is consent-based: on a supervised device it presents the user a consolidated prompt with "Allow" preselected, which the user may decline.

We are seeking guidance on the supported approach for macOS 27 GA:

On a supervised macOS 27 device, is there a supported mechanism for an MDM-managed, code-signature-verified application to be provisioned with Accessibility as a managed security control, without depending on individual end-user consent? (i.e. an equivalent to what PPPC provided for enterprise-managed endpoints.) If the consent-based com.apple.configuration.app.settings Privacy declaration is the only path, what is Apple's recommended approach for enterprise-mandated security agents that must have Accessibility to function — including handling the case where a user declines or dismisses the prompt?

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

Environment for context: macOS 27 supervised via Automated Device Enrollment, managed by Jamf Pro.

Answered by DTS Engineer in 901251022

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"

Answer 1

sa_i OP

1d

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

Answer 2

DTS Engineer OP

Apple

9h

Recommended

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"

Answer 3

sa_i OP

2h

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.