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:

• Apple: Device management schema (Accessibility grant-removal line, verbatim)
• Apple Developer: App Settings configuration (the new declarative Privacy defaults)
• Apple Developer: PrivacyPreferencesPolicyControl (legacy payload, PostEvent example)
• WWDC 2026 Session 206: What's new in managing Apple devices (consent UX)

By now you know the software update commands are gone in 27. Apple announced the removal last year, and in every 27.0 operating system it landed. The legacy software update commands stopped functioning, along with the queries and the restrictions like deferrals. What's left is declarative enforcement, which works differently than the old commands did. You declare a target version and a date, and the device drives itself there. There's no "patch now" button in that model.

If you've been reading along, none of that is new. The mechanism is a deadline: the com.apple.configuration.softwareupdate.enforcement.specific configuration takes a target OS version and a date, and the device updates itself to meet it. You're setting a deadline, not pressing install.

The part in the same release I keep seeing people miss

In all 27.0 operating systems, select system processes now enforce stricter network security on management traffic. Your MDM service has to meet TLS 1.2 as a floor, with cipher suites and certificates that clear the new App Transport Security bar, or those connections can fail. And it isn't scoped to one function. Device management, enrollment, profile installs, app installs, and software update traffic all ride that stricter requirement now.

Apple's own wording hedges here: the new requirements "might cause connections to fail" if the service doesn't meet them. So this is a floor you need to clear, not a switch that flips your fleet dark on day one. But it's a floor under everything, not one feature.

Why this is the one I'd worry about

The two changes fail in opposite ways, and that's the whole problem.

The software update removal is loud. It shows up the moment you try to run a command that no longer exists, and you know exactly what happened. A TLS handshake your MDM can't complete just looks like the service going quiet, so you go hunting in the wrong place: the device, the network, the profile, anywhere but the certificate on your management service.

What strikes me about the pairing is that Apple didn't ask us to adopt any of this. They removed the alternative and raised the floor under it in the same release. That framing only holds for software update; it's the one place where the old path is genuinely gone rather than deprecated. It is worth saying plainly because it's easy to over-read into the rest of 27, and the PPPC picture is the opposite: there, the old payload is still doing real work.

Before you touch 27

Confirm two things with your MDM vendor. Does it do declarative software update enforcement, and does its service clear the new TLS bar? Then test on one machine before it goes anywhere near the fleet.

One honest caveat: the 27 deployment guide is still pre-release, so the exact wording can shift before it's final. The software update removal is not in that category. It was announced last year and it's in effect across the 27.0 releases now.

Sources

Both changes below are in Apple's deployment guide and device-management schema:

• Apple Support: Device management updates (software update removal, network security)
• Apple: Device management schema (software update enforcement configuration)

At WWDC this year, Apple pitched the new macOS privacy model as a convenience: one consolidated consent prompt, fewer dialogs for your users. That part is true. What the pitch skips is where the schema draws the line, and if you run security tooling that line decides whether you migrate this cycle or end up straddling two models. So I went through the configuration key by key.

This is the second piece in a short series on the macOS 27 model. The first one covered how much of the release moved onto declarative management. This one is about the part everyone is calling the death of PPPC.

There is a real declarative privacy path now

macOS 27 introduces a declarative configuration, com.apple.configuration.app.settings, that carries a Privacy dictionary of permission defaults. You set a per-app default, and on first launch the app shows one consolidated prompt covering the permissions the user hasn't already seen. It lists your org name, the app, your justification, and each permission in the set.

Read the schema and two things stand out. The prompt is a nudge, not a silent grant: Apple tuned it toward yes. In its own words from the session, "the Allow button is the default button, and is clearly highlighted." If the user picks Not Now, they fall back to the normal per-permission prompts. And on macOS this whole feature is scoped: the schema notes it applies to standard, AppKit-based Mac apps only, so background agents, daemons, and helper tools are out. There is no device-wide silent privacy grant here.

What it covers: seven permissions

On macOS the Privacy dictionary covers seven:

• Accessibility
• Bluetooth
• Camera
• Dictation
• Local Network
• Location
• Microphone

Count them, because the cross-platform schema lists eight. The eighth, Location Accuracy, is iPhone and iPad only; it never shipped on the Mac. So neither platform gets the full list, and the macOS set is these seven.

What it does not cover

Full Disk Access and Screen Recording are not in the new privacy configuration this cycle. The two permissions you fight with most are simply absent from the declarative model.

That is the whole ballgame for anyone shipping an endpoint agent. If your tool needs Full Disk Access or screen recording, those grants stay on the legacy PPPC payload for now. You are not cutting over to declarative; you are running both at once. PPPC can still grant Full Disk Access. It was never able to silently grant screen recording anyway; a profile can only deny that one, or hand the choice to a standard user.

One grant path is removed. Four more are just deprecated.

The "PPPC is dead" reading falls apart right here. In the macOS 27 TCC schema, five service keys are marked deprecated, and only one of them loses a capability you were actually using.

• Accessibility: the one real removal. Granting it through a PPPC profile is deprecated as of 26.2 and removed in 27.0. Apple points you at the new Privacy key instead.
• BluetoothAlways and SpeechRecognition: deprecated, with the schema pointing them toward the new Privacy key.
• Camera and Microphone: marked deprecated, but their entries only restate what was always true: a profile can deny them, never grant them. You weren't granting these from a profile in the first place.

Full Disk Access and Screen Recording aren't deprecated at all. So the payload isn't being buried; it's being hollowed out selectively, and the one grant that actually goes away is Accessibility.

Plan for a straddle, not a cutover

If you manage Macs with security tooling, here is the shape of the next cycle:

• Set your camera and microphone defaults in the new model for standard native apps. The user still gets the prompt; you're pre-seeding the answer.
• Keep Full Disk Access and screen recording on the legacy PPPC payload. There is no declarative path for them yet.
• Test the consent flow with real users before you roll it out. The prompt is built to get a yes, so make sure the yes applies the defaults you actually meant.

The obituaries are early. PPPC is narrower in 27 than it was, but it is still doing the load-bearing work for exactly the permissions your agents depend on. Next in the series: the change in the same release that I think is bigger than any of this, and that fails in a way you won't see coming. If you need to build or check a payload now, the PPPC Builder is here.

Sources

The specifics here come from Apple's own schema and session, not the summary:

• Apple Developer: App Settings configuration (Privacy defaults)
• Apple: Device management schema (TCC and app.settings YAML)
• WWDC 2026 Session 206: What's new in managing Apple devices

I spent years hitting refresh on a management console, waiting to find out whether a profile I pushed actually took. If you managed Apple devices the old way, you did too.

That job mostly ended with declarative device management, and by now everyone knows the pitch. The device holds its own declarations and reconciles its own state, then reports changes back over a status channel, so there's a lot less to poll. It shipped back in iOS 15. At WWDC this year Cyrus Daboo put it about as bluntly as Apple puts anything:

"It's here. It's shipping. It's in production across fleets around the world. If you're managing devices today without using it, you're working harder than you need to."Cyrus Daboo, WWDC 2026 Session 206

Fine. None of that is news. What I don't think got enough attention is how much of the 27 release moved onto that model.

The status channel reports things it never used to

On iPhone and iPad, device system health now covers the baseband, the camera, and the Face ID sensors. Supervised devices report whether the user turned on Lockdown Mode. Credentials became declarative assets, so you refresh a certificate once and every configuration that references it picks up the change on its own. Anyone who has chased a cert rotation through a dozen profiles knows what that's worth. Network and VPN configurations went declarative this wave too, along with a new extensible SSO configuration.

• Device system health (iPhone and iPad): baseband, camera, and Face ID sensor status, reported over the status channel.
• Lockdown Mode state (supervised iPhone and iPad): devices now report whether the user enabled it.
• Credentials as declarative assets: refresh a certificate once; every configuration that references it reconciles on its own.
• Network and VPN configurations: moved onto the declarative model this release.
• Extensible SSO: a new declarative single sign-on configuration.

Why this is the real headline of 27

For me, that's the story. The model absorbed the parts of device management a lot of us were still doing the old way. Your MDM server didn't go anywhere, and enrollment still runs through it. Declarative management was never a new protocol, just an extension bolted onto MDM. There is just less reason to keep asking the server questions the device is already answering.

If you're standing up new configurations this cycle, that's the lens to use: for each thing you push, ask whether the device can now hold and report that state itself. More of the answers are "yes" in 27 than in any release before it.

This is the first in a short series on what changed in the 27 model. The next piece looks at something the WWDC talk sold as a convenience that the schema says is narrower than it sounds: the privacy consent changes, and why the "PPPC is dead" takes are early. When you need to rebuild or sanity-check a payload in the meantime, the PPPC Builder and the rest of the builders are here.

Sources

Every claim above traces to Apple's own primary material:

• Apple Developer: Leveraging the declarative management data model to scale devices
• WWDC 2026 Session 206: What's new in managing Apple devices