Privacy Preferences Policy Control

Q: How do I obtain the Code sign requirement for an app?

Run codesign --display -r - /path/to/app/binary on a fresh installation of macOS 10.14 or later, and specify the output displayed as the Code sign requirement.

This page explains how to configure Privacy Preferences Policy Control (PPPC) profiles in MDM to remotely manage application permissions on macOS Mojave (10.14) and later. Admins can allow or restrict cross-application data requests—such as Camera, Microphone, Accessibility, and AppleEvents—on behalf of users, removing the need for manual consent. It also details profile specifications including bundle identifiers, code sign requirements, static code validation, and how to configure permissions for multiple apps within a single PPPC policy.

With the release of macOS Mojave (10.14), Apple introduced controls that let the users allow or restrict cross-application data requests. Subsequently, macOS Catalina (10.15) extended this list of requests to include permissions such as Camera, Photos, Accessibility, AppleEvents, and much more.

For example, certain apps or services might require users' permission(s) to access specific data or even other apps; similar to the permissions requested on mobile devices. The users must provide their consent, without which the apps and services might fail to function. Certain apps or services like Accessibility might even require admin privileges to grant access, which cannot be manually granted by a standard user.

Configuring Privacy Preferences Policy Control (PPPC) in MDM lets you remotely manage these security preferences/permissions. You can allow or restrict permissions requested by Mac applications, on the users' behalf.

Prerequisite(s)

The managed Mac machines must be running macOS 10.14 or later.

Profile Description

Profile Specification	Description
Identifier Type	Select the identifier type using the radio button. The available options are: Bundle ID — Select this option to identify the app using its unique bundle identifier. Installation Path — Select this option to identify the app using its installation path. This is useful for non-bundled apps.
Identifier Value	Based on the selected Identifier Type, specify the corresponding value: If Bundle ID is selected, enter the unique bundle identifier of the app (e.g., com.example.app). If Installation Path is selected, enter the full installation path of the app (e.g., /Applications/Example.app).
Code sign requirement	To find the code sign requirement of an app, run the following command in Terminal: `codesign -d -r- /Applications/AppName.app` Example: `codesign -d -r- /Applications/Safari.app` Example Output: `designated => identifier "com.apple.Safari" and anchor apple` Copy the portion after => and paste it in the Code sign requirement field. In this example, you would copy: `identifier "com.apple.Safari" and anchor apple`
Static code validation	Enable this only if the app or process invalidates the dynamic Code sign requirement. By default, this will be disabled.
Permissions	Allowed Permissions Specify permissions that you want to provide consent to, on behalf of the users. Other Permissions Permissions which are not marked as allowed can be set to user controlled or restricted.
Apple Events Receiver Application Information	If the app or service requires permission to access other apps or services via AppleEvents, specify each receiver application with the following details: Identifier Type — Choose the identifier type using the radio buttons: Bundle ID — Identify the receiver app using its unique bundle identifier. Path — Identify the receiver app using its installation path. Identifier Value — Based on the selected Identifier Type, enter the bundle identifier or installation path of the receiver app. Code sign requirement — Specify the code sign requirement of the receiver app. Static code validation — Enable this only if the receiver app invalidates the dynamic code sign requirement. By default, this will be disabled. You can add multiple receiver applications by clicking + Add more.

You can configure PPPC for multiple apps within a single policy.
Permissions such as Camera, Microphone, and Screen Recording cannot be granted access by any MDM. These can only be restricted or left to user controlled, which is the default option.
After applying a PPPC permission to a device, in some cases even if the change is not reflected in the device system settings, the permission will be applied internally to the device.
Starting from macOS Tahoe (26.2), app privacy permissions configured via device management are now visible in System Settings > Privacy & Security.

Frequently Asked Questions

Which macOS version is required to configure PPPC profiles?

The managed Mac machines must be running macOS 10.14 (Mojave) or later.

Can MDM automatically grant permissions like Camera, Microphone, or Screen Recording?

No. Permissions such as Camera, Microphone, and Screen Recording cannot be granted access by any MDM. These can only be restricted or left to user controlled, which is the default option.

How do I obtain the Code sign requirement for an app?

Run codesign --display -r - /path/to/app/binary on a fresh installation of macOS 10.14 or later, and specify the output displayed as the Code sign requirement.

Can a single PPPC policy cover permissions for more than one app?

Yes, you can configure PPPC for multiple apps within a single policy.

Jump To