FAQ: Issues Allowing App Permissions via Device Settings (PPPC, System Extensions, etc...) – Addigy

If an app is not receiving the permissions you've configured — even after deploying the relevant PPPC, System Extension, or other permission payloads — work through the troubleshooting steps below to identify and resolve the issue.

Related Resources

1. Make Sure the Device Setting Is Installed Before the Software

Some permissions must be in place before the application is installed. If the Device Setting was deployed after the software, the app may not have picked up the permissions correctly and users may still be prompted to grant permissions. In this case, try reinstalling the application so it can pull permissions from the already-deployed Device Setting.

Note: When deploying Device Settings and Smart Software together via a policy, Addigy's Priority Deployments feature will automatically install Device Settings before software — unless configured otherwise. See: Overview: Priority Deployments.

2. Check for Incorrect or Missing Identifiers

One of the most common causes of permission issues is a missing or incorrect identifier for a specific app binary. A few things to keep in mind:

Applications can include multiple binaries, each with their own identifiers. If a required binary is not included in your payload, the permission may not apply correctly.
When an application updates, its binary identifiers may also change. If new identifiers are not already in your payload, the permission can be lost after an update.

Always check the software manufacturer's remote deployment documentation first, as most vendors publish the required identifiers. If documentation is not available, you can retrieve identifiers manually using: How To Get the Team ID, Bundle ID, and Code Requirement. Note that some binaries may be located in non-obvious directories and can be difficult to locate - it may be worthwhile to contact the software manufacturer's support team if you are unable to locate all the necessary identifiers.

3. Verify the Device Setting Was Applied Correctly

To confirm that Addigy applied the Device Setting as expected, you can view the enforced MDM settings locally on the device. There are two ways to do this:

Via System Information

Open System Information (press CMD + Space and search for "System Information").
Under the Software section in the sidebar, select Profiles.
Select a specific profile by name, or choose Device Configuration Profiles to view all enforced settings.

Tip: Use CMD + F to search for specific identifiers or settings within the output.

Via Terminal Command (Remote-Friendly)

The following command can be run remotely via Addigy and returns the same information as the Device Configuration Profiles view above:

sudo /usr/bin/profiles list -output stdout-xml

If the identifiers and settings from your payload appear correctly in the output, the profile was applied as expected and the issue likely lies elsewhere.

4. Test with a Custom MDM Profile

If you suspect the issue may be with how Addigy is generating the profile, you can test by creating and deploying a custom MDM profile directly. Two widely used tools for building custom profiles are Apple Configurator and iMazing.

For steps on deploying a custom MDM profile via Addigy, see: How To: Configure and Deploy a Custom MDM Profile.

5. Understand the Difference Between OS Prompts and App Prompts

Not all permission prompts indicate a missing profile. Some applications prompt for permissions internally without properly checking whether the OS has already granted them — meaning the app prompt can appear even when the permission is correctly in place.

OS prompt — a macOS system dialog (like the "System Extension Blocked" alert) confirms the permission has not been granted. These prompts are unmistakably from macOS and indicate a real gap in your payload. Do note that the prompt itself will vary in design and wording depending on what permission is required.
App prompt — a prompt generated by the application itself, which may appear even when the permission is correctly configured. In this case, try using the app directly to verify it functions as expected. For example, if an antivirus is asking for permission, try performing a device scan and see if any macOS prompts appear. If app prompts prevent normal use, a reinstall may be needed.

6. Grayed Out Slider in System Settings > Privacy & Security

When a PPPC payload is applied, the toggle for the affected permission in System Settings > Privacy & Security may appear grayed out. This does not necessarily mean the permission is missing — it is a known visual behavior in macOS when a permission is managed by an MDM configuration (Device Setting).

macOS 26.1 and earlier: Managed permissions appear grayed out with no label, which can look like the permission is disabled even when it is not. Test the app's functionality directly to confirm. For example, an antivirus will not be able to scan all directories on a device if Full Disk Access is not provided.
macOS 26.2 and later: Apple updated this behavior — permissions managed by a profile now display a note stating "This setting has been configured by a profile," making it easier to confirm the payload is active.