
The one PPPC change in macOS 27 that actually breaks a workflow
A follow-up to the PPPC piece. One deprecated permission in macOS 27 doesn't just move to a new model, it removes a grant path Help Desks quietly depend on. The replacement is user-scoped and vendor support is uneven.
In macOS 27, MDM can no longer silently grant Accessibility. For a Help Desk tool that relies on that service to control a Mac, the old path is gone at 27.0. Apple's documented replacement is a user consent prompt, and it is scoped to AppKit-based Mac apps, so it may not reach the component that needs the permission.
This is a follow-up to the PPPC piece in this series, and to the wider declarative-management shift. That post drew the line between what moved to the declarative model and what still needs a profile, and it flagged Accessibility as the one real removal. A reader, Stephen Grall, pointed out in the comments that this removal isn't just a schema footnote; it breaks a workflow real teams run every day. He's right, so it gets its own post.
One question is worth answering before you upgrade: is the part of your remote-support tool that needs Accessibility a native Mac app, or a background agent? That answer decides whether the new consent path reaches you at all.
What Apple actually removed
Accessibility is one permission remote-control tools may use to move the mouse and type on the other end of a session. Until now, an MDM could grant it silently by pushing a PPPC profile, with no prompt and no user step. That is the path this post is concerned with.
In macOS 27, that silent grant is gone. Of the permissions PPPC could hand out this way, Accessibility is the one Apple is taking back. From Apple's own device-management schema, verbatim: "This profile deprecated its ability to grant access as of macOS 26.2, and removes that ability in macOS 27.0."
The replacement isn't a drop-in
The new declarative privacy configuration (com.apple.configuration.app.settings) does include Accessibility. But two things changed underneath it, and both apply.
First, it's a consent prompt now, not a silent grant. The user gets Allow or Not Now. You set the default; they still decide. In Apple's words from the WWDC session, "the Allow button is the default button, and is clearly highlighted." So it's tuned toward yes, but it is still the user's call.
Second, Apple scopes this Privacy-defaults feature to AppKit-based Mac apps. If the component that needs Accessibility is not AppKit-based, this feature does not cover it. That is a compatibility question to test against the actual component, not infer from the product's user-facing app.
Delivery is a separate dependency
Pushing this declaration needs an MDM path that can deliver a user-scoped custom declaration. Apple's old Accessibility grant disappears at the operating-system boundary; your server's ability to deliver the replacement is a separate dependency. Verify both before upgrading.
Before you upgrade, walk this:
- Find which tools rely on Accessibility.
- Check whether that piece is a native app or a background agent.
- Confirm your MDM's declarative-privacy support and your own migration timeline.
- Test the consent flow with a real standard user, not an admin.
Where the documented vendor paths stand
Vendor support is changing quickly, so this is a source-linked snapshot retrieved 2026-07-29.
- Addigy documents an AppleSeed-tagged App Settings type for devices on supported beta OS versions.
- Jamf Pro Blueprints can create a JSON custom declaration in the User channel. Jamf says custom declarations fall outside its support scope, and Blueprints require one of the listed Jamf Cloud-hosted environments.
- Fleet documents
mdm.allow_all_declarationsfor device-scoped configuration declarations. Its current docs say user-scoped declarations are coming in Fleet 4.90, so that path does not currently deliver this user-scoped Privacy payload.
That is not a market scoreboard. It is the minimum current claim each linked vendor source supports. Confirm your own vendor's release documentation before planning a rollout.
Self-hosting? Build the test bench now
You can author the JSON from Apple's pinned app.settings schema now. Delivery is the gate. Once your MDM path carries user scope, test on a Mac running the relevant macOS 27 seed, signed in as a standard user, and exercise the real component that needs Accessibility. Until then, stage the declaration and document the missing delivery capability rather than treating a device-scoped path as equivalent.
Three pushbacks, answered
This crowd reads schemas, so here are the replies I'd expect, up front.
"Speech Recognition and Bluetooth are deprecated too." They are. Accessibility is different because its schema entry explicitly says the grant ability is removed at 27.0. BluetoothAlways and SpeechRecognition are marked deprecated; the schema does not make the same grant-removal statement for them.
"What about PostEvent?" Apple's current PPPC example configures Allow for PostEvent on com.apple.screensharing.agent. That proves the example exists, not that every remote-control authorization path survives unchanged in 27. Verify which service your tool actually uses.
"Just defer macOS 27." The legacy schema limits MajorPeriodInDays to 1–90, but Apple's current deployment guide says legacy update restrictions, including deferrals, no longer function in 27.0. Migrate the update workflow rather than treating that old range as a current escape hatch.
The shape of it
Two schema fields tell the whole story. Legacy PPPC is device-channel only; the new privacy key is user-scope only. Device-level and silent, to per-user and consensual. Fleet's currently documented declaration path is device-scoped, so it does not deliver this user-scoped Privacy payload today.
If you need to author or check the payload that still does the load-bearing work this cycle, the PPPC Builder is here. And if you haven't read where the rest of the privacy model landed, start with what macOS 27 actually moved off the profile. For an endpoint agent, that profile is only one dependency in a tested uninstall sequence.
Sources
Primary sources retrieved 2026-07-29. The Apple schema links are pinned to macOS 27 Seed2; vendor entries describe only the paths each vendor currently documents:
- Apple device-management schema: TCC / PPPC Accessibility grant-removal line (commit 97a11a8)
- Apple device-management schema: App Settings Privacy, user scope, and AppKit limit (commit 97a11a8)
- Apple device-management schema: Software update settings (legacy 1–90 day major-update deferral)
- Apple Developer: App Settings configuration (the new declarative Privacy defaults)
- Apple Developer: PrivacyPreferencesPolicyControl (legacy payload, PostEvent example)
- Apple Support: Device management updates (legacy update restrictions removed in 27.0)
- WWDC 2026 Session 206: What's new in managing Apple devices (consent UX)
- Addigy: Sending AppleSeed Declarative Settings via Addigy
- Jamf: Creating a Custom Declaration in Blueprints
- Jamf: General requirements for Blueprints in Jamf Pro
- Fleet: Server configuration (mdm.allow_all_declarations scope)