← Field Notes
PPPC · Deep dive

The one PPPC change in macOS 27 that actually breaks a workflow

R Rob Flanagan · · 6 min read

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. If you self-host your MDM, you can lose the old path before your server can deliver the new one.

In macOS 27, your MDM can no longer silently grant the permission your Help Desk's remote-support tool needs to control a Mac. That permission is Accessibility, and the silent MDM grant for it is gone at 27.0. The replacement is a user consent prompt, and Apple scopes it to AppKit-based Mac apps only, so it may not reach your tool at all.

This is a follow-up to the PPPC piece in this series. 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 the permission a remote-control tool needs 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 your Help Desk's remote-support tool has been riding.

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 it to AppKit-based Mac apps only, not background agents or helper tools. A lot of remote-support software runs exactly those: a background service that does the actual input injection. If that component isn't an AppKit app, the new declarative path doesn't cover it, and you have no managed grant route at all.

Why on-prem feels it first

Pushing that declarative config needs an MDM server that already supports custom declarations, and the whole feature is still in beta season. If you self-host your MDM, common in regulated sectors like government, defense, healthcare, and finance, you upgrade on a change-control clock. You can lose the old grant path at 27.0 before your server can deliver the new one.

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 upgrade and deferral timeline.
  • Test the consent flow with a real standard user, not an admin.

Where the vendors stand

I read 11 MDM vendors' official docs during the week of this post. It's beta season, so read this as a snapshot dated 2026-07-11, and re-check your vendor's release notes before you plan. Vendors with a native, supported path today: zero.

  • Addigy: a native App Settings declarative type, in beta behind Apple's AppleSeed for IT seeding program.
  • Jamf Pro cloud: deployable today as hand-built JSON via Blueprints custom declarations, with a Channel selector that includes User (which the new privacy key requires). But custom declarations fall "outside the scope of Jamf support," and on-prem is excluded.
  • Fleet: self-hosted, with a raw-DDM server flag (mdm.allow_all_declarations). It scopes to device configuration declarations today; user-scoped support is on its near-term roadmap. This config needs user scope.
  • Everyone else: Kandji, Mosyle, JumpCloud, FileWave, Hexnode, Omnissa Workspace ONE, SimpleMDM, and Intune, all silent on app.settings so far.

Still early. Vendors like Jamf ship native support at launch, so today's hand-built paths aren't the final shape. The lag that sticks is on-prem: with the last big DDM feature, DDM software updates were live in Jamf's cloud roughly a year before self-hosted Jamf Pro caught up. Expect a similar gap here.

Self-hosting? Build the test bench now

You don't have to wait for your MDM server to catch up. Two paths an on-prem shop can run today:

  • Author it from Apple's schema. The app.settings declaration is public in Apple's device-management schema. Write the JSON now, ready to push the moment your server delivers custom declarations.
  • Test it on Fleet. It's open source and self-hostable, and its allow-all-declarations flag pushes raw DDM to a test Mac today. Device scope now, user scope on the roadmap. This config needs user scope, so watch that milestone.

Once your push path carries user scope (Fleet's user-scope support, or your MDM's custom-declaration support), run the test on a Mac on the macOS 27 beta, signed in as a standard user, not an admin, because the admin path can mask the exact prompt behavior a real user will hit. Until then, stage the JSON and stand up the bench so you're ready the day that scope lands.

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. But deprecated still grants this cycle; only Accessibility's grant is removed at 27.0. Deprecated works; removed doesn't. That difference is the whole reason this post is about Accessibility specifically.

"PostEvent still grants." It does, and it isn't deprecated at all. Apple's own PPPC doc example grants PostEvent to com.apple.screensharing.agent. If your tool injects input through PostEvent rather than Accessibility, that grant path survives 27.0. Most tools gate control on Accessibility anyway, so check which one yours actually rides.

"Just defer macOS 27." Deferral caps at 90 days: the MajorPeriodInDays limit (range 1–90) in Apple's softwareupdate.settings schema. That's a clock, not a fix. Put the date in your plan.

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. That's a cleaner model in the long run, but the transition has a gap, and remote-support tooling on self-hosted MDM is sitting in it.

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.

Sources

The Apple claims below are grounded in Apple's own schema and session, linked here. The vendor specifics are a point-in-time docs survey dated 2026-07-11, not linked individually, so re-check each vendor's current release notes before you plan:

← Back to Field Notes