We are migrating our macOS applications from the legacy PPPC Accessibility service to the macOS 27 declarative App Settings configuration, as recommended by Apple.
The applications require Accessibility permission to provide managed data-protection functionality and create the required event taps.
Our configuration contains:
- A declarative com.apple.configuration.app.settings configuration that sets the Accessibility privacy permission to Allow.
- A legacy PPPC payload that grants PostEvent, because this service is not available through App Settings.
The declaration and PPPC payload are delivered and applied successfully. After the user accepts the macOS Allow / Not Now prompt, the application’s Accessibility slider is enabled under: System Settings → Privacy & Security → Device Control and Data Access
The user can turn it off even while the management declaration remains installed and active. When the user disables the setting:
- The application loses Accessibility access.
- Required event-tap functionality stops working.
- The application may display the legacy Open System Settings / Deny Accessibility prompt when the protected feature is subsequently activated.
- Manual user intervention is required to restore the application’s functionality.
Expected behavior:
We expected an Accessibility permission managed by MDM/DDM to remain enforced while its declaration is active, similar to the behavior of an Accessibility permission granted through the legacy PPPC payload.
Apple’s AppSettings documentation states: “The user can change the app permission privacy settings in Settings.app if they choose.”
This appears to describe the behavior we are observing. However, it is unclear how an organization can enforce a required Accessibility permission after the legacy PPPC Accessibility grant is deprecated on macOS 27.