WDAC for macOS? App Control on macOS 27 with Intune

For years, stopping an app from launching on a managed Mac meant a third-party tool, or the com.apple.applicationaccess.new profile that Apple now deprecates in macOS 27. Privacy permissions were no better. Users met prompts at awkward moments with no default selected, and Apple itself says that led to wrong choices, broken workflows and support calls.

WWDC26 changes both. One new declarative configuration, com.apple.configuration.app.settings, lets you deny or allow binaries on supervised Macs, and suggest an app’s privacy permissions in a single consent prompt. macOS 27 shipped on 14 September 2026, and the Intune settings catalog already has the settings.

In this post

This is Part 1 of a series on WWDC26 for Intune admins. The series follows Apple’s What’s New for IT at WWDC26, one part per page: app management, device management, identity integration, Apple services and education.

Part 1 covers:

• The eight app management changes at a glance
• Prerequisites for the App Settings declaration
• Deploy 1: deny and allow binaries on macOS 27 from Intune
• Deploy 2: privacy permission defaults and the consolidated consent prompt
• What the Mac shows, where the logs are, and how to troubleshoot

What’s new in app management

Apple lists eight app management changes from WWDC26. Two of them live in one new declaration, com.apple.configuration.app.settings, and those are the two this post deploys from Intune.

Source: Apple, WWDC26 app management updates

In Intune, the new declaration sits in the settings catalog under Declarative Device Management (DDM) > App Settings. The picker shows 26 settings there: Allowed Binaries, Denied Binaries, Always Allow Managed Apps, and Privacy > Permission Defaults. Microsoft’s App settings configuration for Apple devices page covers the launch and binary controls for supervised iOS/iPadOS 27+ and macOS 27+. As of its 26 August 2026 update, it does not describe the Privacy settings.

Prerequisites

You need a supervised Mac on macOS 27, enrolled through Automated Device Enrollment, and a test group in Intune. Use a test Mac, not your daily driver.

Two scopes, so plan two profiles. In Apple’s schema the binary rules (AllowedBinaries, DeniedBinaries, AlwaysAllowManagedApps) are system scope on macOS, and Privacy is user scope. That points to one profile for the binary rules and a second for the privacy defaults. The deployment sections confirm how Intune delivers each.

Why a test Mac. Apple’s Allow and deny apps and binaries page describes two behaviours that can catch you out:

• An allow list quits anything already running that is not on it.
• Any binary policy, even one with an empty list, blocks unsigned, ad hoc-signed and development-signed binaries.

Deny and allow binaries on macOS 27

Start with a deny list. It blocks only what you name, so it is the safer mode to test first. Apple’s schema has no report-only key, so every rule enforces as soon as the Mac applies it.

How a rule matches

A rule holds up to five code-signing attributes. A binary matches only when every attribute in the rule matches, so more attributes make a narrower rule.

A deny rule needs at least one of CDHash, TeamID or SigningID. An allow rule needs CDHash or TeamID, because a Signing ID is not unique across developers.

Source: Apple, Allowing and denying apps and binaries.

Step 1: Read the signing details

The example is Chess. It ships with macOS, and Apple uses it in its own documentation. On the test Mac, run:

lipo -archs /System/Applications/Chess.app/Contents/MacOS/Chess
codesign -dvvv --arch arm64e /System/Applications/Chess.app

The first command lists the architectures in the binary. Pass the value it returns to --arch in the second. Apple’s documentation shows Identifier=com.apple.Chess and TeamIdentifier=not set for Chess. That gives a Signing ID of com.apple.Chess, which is all a deny rule needs.

Step 2: Create the deny profile

• In the Intune admin center, go to Devices > Configuration > Create > New policy.
• Set Platform to macOS and Profile type to Settings catalog. Select Create.
• Enter a name, for example macOS 27 - App Settings - Deny binaries.

• On Configuration settings, select Add settings. Expand Declarative Device Management (DDM) and select App Settings.

• Under Allowed, select Denied Binaries, then close the picker. Intune adds one rule with five fields: CD Hash, Path Prefix, Signing ID, Signing State and Team ID.

• Select Edit instance. Enter com.apple.Chess in Signing ID and leave Signing State at All. Remove CD Hash, Path Prefix and Team ID with the minus icon beside each field. Intune rejects an empty field with the error “The value must have a length of at least 1.”

• Select Next. Assign the profile to a device group that holds only the test Mac.
• Review the settings and select Create.

A profile can hold several rules, and each rule can use different fields. Select Add for each new rule. The test profile ended up with three: Chess by Signing ID, and two vendors by Team ID. A field that a rule does not use shows as blank or Not configured in the table.

Step 3: Sync and test

• In the Intune admin center, open the device and select Sync.
• On the Mac, open Chess. macOS blocks the launch and shows an alert.
• In Intune, open the profile. Device and user check-in status shows the result, and the Device assignment statusand Per setting status reports give the detail.

Result on the test Mac. The rule works. macOS shows this alert:

“Chess” Unavailable

This app is not allowed by “Intune-IRL”. Contact your administrator for more information.

The alert names the organisation, here Intune-IRL.

In Intune, the profile shows Succeeded: 1 under Device and user check-in status.

A second test covered an app that was already running. Claude was open when a Team ID rule for it was added to the profile. About 11 seconds after the Mac received the change, Claude closed on its own, with no alert. The alert appeared only when Claude was opened again.

Step 4: Move to an allow list

An allow list flips the default. Only listed binaries run, everything else is blocked, and anything already running that is not on the list is quit. Plan the list before you assign it.

What always runs. Apple’s core policy keeps the system and device management working. Binaries under /bin/, /Library/Apple/, /sbin/, /System/, /usr/bin/, /usr/libexec/ and /usr/sbin/ always run. Apps under /Applications/ and /System/Applications/ do not get that pass. Your rules decide those.

What to put on the list. For an Intune-managed Mac, start with two Team IDs:

The Intune agent lives in /Library/Intune/, outside the paths that always run, so it needs a rule. Confirm the Microsoft Team ID on your own Mac:

codesign -dv "/Library/Intune/Microsoft Intune Agent.app" 2>&1 | grep TeamIdentifier

Always Allow Managed Apps. Set it to True and managed apps run without a rule. In Intune that covers VPP apps and the line-of-business app type. It does not cover PKG or DMG apps that the Intune agent installs, so those need their own rule.

How lists combine. Two rules from Apple matter here:

• Deny wins. A binary that matches a deny rule is blocked even if an allow rule matches, so the Chess deny profile can stay assigned.
• Allow lists intersect. With more than one allow configuration on a Mac, a binary must appear in all of them. Keep one allow profile per Mac.

Create the profile

1. Create a second settings catalog profile, for example macOS 27 - App Settings - Allow binaries.
2. In the picker, under App Settings > Allowed, select Allowed Binaries and Always Allow Managed Apps.
3. Select Edit instance. Enter *APPLE* in Team ID and leave Signing State at All. Remove CD Hash, Path Prefixand Signing ID with the minus icon.
4. Select Add and create a second rule with UBF8T346G9 in Team ID.
5. Set Always Allow Managed Apps to True.
6. Assign the profile to the test device group and select Create.

An easy mistake: the leftover Denied Binaries section

This one is easy to walk into. In the settings picker, Denied Binaries sits in the same Allowed group as Allowed Binaries. Select the whole group and Intune adds a Denied Binaries section with one default rule to your allow profile.

If that rule ends up with only Signing State, for example after you remove its empty fields to clear the validation error, Intune saves the profile without any warning. The Mac does not accept it. It rejects the whole profile with “Binary identifier has no usable fields”, every setting shows Noncompliant in Intune, and the valid allow rules are not applied either.

The error does not name the rule. In testing, the first suspect was the *APPLE* Team ID, which turned out to be fine. Before you save an allow profile, remove the Denied Binaries section with the minus icon next to its heading. The Troubleshooting section shows how to find a rejected rule.

Test it

1. Before you sync, open one app that is not on the list, for example a third-party browser, and leave it running.
2. Sync the Mac from the Intune admin center.
3. Watch the running app. Apple’s documentation says it is quit, and that launching it again shows the alert.
4. Open an Apple app and a Microsoft app. Both should still launch.

Result on the test Mac. Chrome was open when the profile arrived. About 12 seconds after the Mac received the change, Chrome closed on its own. The log shows the sweep terminating 11 processes in 71 milliseconds:

22:37:34.189 ManagedPreferencesSubscriber [ManagedPreferencesRestrictionsAdapter] Installed profile: 22:37:35.397 managedeventsd [LaunchPolicy] Policy changed — clearing cache and sweeping
22:37:35.417 managedeventsd [ProcessSweep] Terminating 11 violating processes
22:37:35.470 managedeventsd [ProcessSweep] Sweep complete — 11 processes terminated

Roll back. Remove the assignment and sync. Device management processes are part of Apple’s core policy, so the Mac can still receive the change.

Privacy permission defaults on macOS 27

With the Privacy key you suggest an app’s privacy permissions instead of leaving every prompt to the user. The next time the app launches, macOS shows one consent prompt with your defaults, your organisation’s name and your justification. If the user selects Allow, the defaults apply and no further prompts appear. If they select Not Now, macOS prompts in the normal way.

Six permissions take None or Allow: Accessibility, Bluetooth, Camera, Dictation, Local Network and Microphone. Location takes None, WhileUsing or Always, and the last two are equivalent on macOS.

Three limits from Apple’s schema are worth knowing before you test:

• Only AppKit-based apps on macOS support it.
• The prompt lists only permissions the user has not seen before. If they have seen them all, no prompt appears.
• It is a suggestion, not enforcement. The user can decline, and can change the permissions later in System Settings.

Step 1: Build the app identifier

On macOS the app identifier is a composed identifier: the bundle ID, then the designated requirement in braces. Apple’s example is com.example.scanner {anchor apple generic}. The Mac applies the defaults only if the app’s code signature matches it.

Read both parts on a Mac that has the app. The example here is Microsoft Teams:

defaults read "/Applications/Microsoft Teams.app/Contents/Info" CFBundleIdentifier
codesign -dr - "/Applications/Microsoft Teams.app"

The second command prints designated => …. Everything after designated => is the designated requirement. The short form from Apple’s example, {anchor apple generic}, accepts any Apple-issued signature for that bundle ID. The full designated requirement is tighter, because it also pins the developer.

Someshs-MacBook-Pro ~ % defaults read "/Applications/Microsoft Teams.app/Contents/Info" CFBundleIdentifier
codesign -dr - "/Applications/Microsoft Teams.app"
com.microsoft.teams2
Executable=/Applications/Microsoft Teams.app/Contents/MacOS/MSTeams
designated => identifier "com.microsoft.teams2" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UBF8T346G9

Step 2: Create the profile

• Create a settings catalog profile for macOS, for example macOS 27 - App Settings - Privacy defaults.

• In the picker, under Declarative Device Management (DDM) > App Settings > Privacy, select Permission Defaults. Leave the Allowed group unticked.
• Select Edit instance. Intune shows a group named ANY with the permission dropdowns, Organization Justification and Permission Defaults.
• Enter the composed identifier in Permission Defaults. For Teams that is com.microsoft.teams2 {anchor apple generic}.
• Enter your reason in Organization Justification. Apple requires it, and the user sees it in the prompt.
• Set Camera and Microphone to Allow.
• Assign the profile and select Create.

Use Add for each further app. Privacy is user scope on macOS in Apple’s schema, so the declaration has to arrive on the user channel.

In testing, the profile was assigned to a device group, like the binary profiles, and the consent prompt appeared. The declaration still arrived on the user channel: RemoteManagementAgent fetched it, and the log shows it applied “in user scope”.

Step 3: Test

• Reset earlier decisions for the app, so the prompt has something to show:

tccutil reset Camera com.microsoft.teams2
tccutil reset Microphone com.microsoft.teams2

• Quit the app, then sync the Mac from the Intune admin center.
• Open the app. Apple’s documentation says one consent prompt appears, with the organisation’s name, your justification, and Allow as the default button.
• Select Allow, then check System Settings > Privacy & Security > Camera and Microphone.

Result on the test Mac. Teams showed one consent prompt on launch:

“Intune-IRL” Recommends Allowing Access for “Microsoft Teams”

From your organization: Teams needs the camera and microphone for meetings.

The prompt names the organisation, repeats the justification from the profile, and lists each permission with a short description. The capture shows Device Control and Data Access, Camera, Microphone, Local Network and Speech Dictation. The buttons are Not Now and Allow, with Allow as the default.

Bluetooth and Location were also set in the profile, but they are not in the capture. In the log, tccd marked five permissions as needing a prompt. After Allow, it set Accessibility, Camera, Microphone and Speech Recognition to allowed.

tccd also logged skipping access_changed event for unknown service for Location and Local Network. Location was still pending on the next launch of Teams.

Validate on the device

Each deployment shows the user something different. For the admin, the profile’s Device and user check-in status in Intune is the first place to look.

Logs: What a healthy deployment looks like

Three processes carry the story. remotemanagementd fetches the declaration, managedeventsd enforces the rules, and LaunchPolicyAlertAgent shows the alert. The lines below come from the test Mac, trimmed to time, process, category and message.

Capture the log

Run this within 30 minutes of the test:

sudo log show –last 30m –info –debug –predicate ‘subsystem BEGINSWITH “com.apple.devicemanagementclient” OR process CONTAINS[c] “remotemanagement” OR eventMessage CONTAINS[c] “app.settings” OR eventMessage CONTAINS[c] “com.apple.Chess”‘ > ~/Desktop/appsettings-deny.txt

The first term catches managedeventsd and the alert agent. Replace com.apple.Chess with your own Signing ID.

1. The declaration arrives

19:45:38.121 RemoteManagementMCXService [mdmHelper] Processing DeclarativeManagement command for Microsoft.Profiles.MDM, type: 3.
19:45:40.646 remotemanagementd [mdmConduit] ⚙️ Fetching declaration items
19:45:45.034 remotemanagementd [mdmConduit] ⚙️ Fetching partial object RMConfigurationPayload: id='39f4e137-9a07-4a0f-8c36-e55c697a3296_com.apple.configuration.app.settings' token='C27F9596'
19:45:47.124 remotemanagementd [mdmConduit] 🟡 Proposed loaded: id='39f4e137-9a07-4a0f-8c36-e55c697a3296_com.apple.configuration.app.settings' token='C27F9596'
19:45:49.414 remotemanagementd [configurationPublisher] Triggering configuration subscriber plugin: com.apple.remotemanagement.ManagedPreferencesSubscriber
19:45:49.459 ManagedPreferencesSubscriber [configurationSubscriberDelegate] Applicator ManagedPreferencesSubscriber.ManagedPreferencesRestrictionsApplicator in device scope starting processing configurations of types: …
19:45:55.239 ManagedPreferencesSubscriber [configurationSubscriberDelegate] Applicator ManagedPreferencesSubscriber.ManagedPreferencesRestrictionsApplicator in device scope finished processing configurations of types: …
19:45:55.251 remotemanagementd [mdmConduit] Sending status...

How to read it:

• 19:45:38 Intune sends a DeclarativeManagement command. The Mac then asks for the declaration list.
• 19:45:45 The Mac downloads the configuration. Its identifier ends in com.apple.configuration.app.settings, which makes it easy to search for.
• 19:45:49 remotemanagementd passes the change to the ManagedPreferencesSubscriber plug-in.
• 19:45:55 The applicator finishes “in device scope”, 17 seconds after the command arrived. The Mac then sends status back to Intune.

The user side stays quiet. The user-side agent, RemoteManagementAgent, logs “Last declarations token received matches last one processed; ignoring fetch declaration items”. That fits Apple’s schema, where binary rules are system scope.

2. The launch is blocked

How to read it:

• 19:54:35 The user opens Chess.
• 19:54:36 Chess is terminated 142 milliseconds later. In (27, 1, 9), the first value matches OS_REASON_ENDPOINTSECURITY in Apple’s kernel source, and the last is the signal number for SIGKILL.
• 19:54:46 managedeventsd sends the alert to the user’s session, about 10 seconds after the kill.

21:53:00.007 managedeventsd [LaunchPolicy] DENIED exec: pid 20813, path /System/Applications/Chess.app/Contents/MacOS/Chess
21:53:00.010 managedeventsd [BlockedAlert] Sent alert for com.apple.Chess to agent (UID 501)
21:53:00.012 LaunchPolicyAlertAgent [Agent] Showing alert for: Chess
21:53:00.068 LaunchPolicyAlertAgent [Agent] Transaction opened — alerts visible

How to read it:

• managedeventsd makes the decision. Its LaunchPolicy category logs DENIED exec with the process ID and the full path of the binary.
• It then hands the alert to LaunchPolicyAlertAgent, which shows it in the user’s session. The whole chain takes 61 milliseconds.

The rest of the system only sees a process that dies. These lines are from an earlier attempt on the same Mac:

19:54:35.920 runningboardd [general] Launch request for app<application.com.apple.Chess…(501)>[0] is using uid 501 (divined from auid 501 euid 501)
19:54:36.062 runningboardd [ttl] [app<application.com.apple.Chess…(501)>:14552] termination reported by launchd (27, 1, 9)
19:54:36.067 loginwindow [AppExit] … CAS notification for appDeath for com.apple.Chess … for bundle path: /System/Applications/Chess.app …

Chess is terminated 142 milliseconds after the launch request. In (27, 1, 9), the first value matches OS_REASON_ENDPOINTSECURITY in Apple’s kernel source, and the last is the signal number for SIGKILL.

On that first blocked launch the alert followed about 10 seconds after the kill. On the later launch it was immediate.

21:35:27.344 managedeventsd [LaunchPolicy] Policy changed — clearing cache and sweeping
21:35:27.373 managedeventsd [ProcessSweep] Beginning process sweep (generation 9)
21:35:27.408 managedeventsd [ProcessSweep] Sweep complete — no violators found

3. A rule change quits running apps

For this test Claude was open on the Mac while a Team ID rule for it was added to the deny profile.

22:04:07.564 remotemanagementd [mdmConduit] ⚫️ New: id='39f4e137-9a07-4a0f-8c36-e55c697a3296_com.apple.configuration.app.settings' token='8C42EF29'
22:04:07.564 remotemanagementd [mdmConduit] 🟠 Proposed for deletion: id='39f4e137-9a07-4a0f-8c36-e55c697a3296_com.apple.configuration.app.settings' token='C27F9596'
22:04:09.609 remotemanagementd [mdmConduit] 🟢 Commit loaded: <ConfigurationPayload { identifier = 39f4e137-9a07-4a0f-8c36-e55c697a3296_com.apple.configuration.app.settings, token = 8C42EF29 }>
22:04:12.802 ManagedPreferencesSubscriber [ManagedPreferencesRestrictionsAdapter] Installed profile: <private>
22:04:12.863 managedeventsd [LaunchPolicy] Policy changed — clearing cache and sweeping
22:04:12.864 managedeventsd [ProcessSweep] Beginning process sweep (generation 16)
22:04:12.883 managedeventsd [ProcessSweep] Terminating 11 violating processes
22:04:12.884 managedeventsd [ProcessSweep] SIGKILL sent to pid 5774
22:04:13.515 managedeventsd [ProcessSweep] Sweep complete — 11 processes terminated
22:04:18.631 managedeventsd [LaunchPolicy] DENIED exec: pid 22034, path /Applications/Claude.app/Contents/MacOS/Claude
22:04:18.633 managedeventsd [BlockedAlert] Sent alert for com.anthropic.claudefordesktop to agent (UID 501)

How to read it:

• 22:04:07 An edited profile keeps its declaration identifier and gets a new token. The Mac fetches 8C42EF29 and marks the old C27F9596 for deletion.
• 22:04:12 Once the change is installed, managedeventsd sweeps the running processes. It finds 11 violators and sends each a SIGKILL. The sweep takes 0.65 seconds.
• 22:04:18 A new launch of Claude is denied, and the alert follows.

Claude closed about 11 seconds after Intune’s command reached the Mac. The sweep raised no alert. The first alert in the log belongs to the relaunch at 22:04:18.

The Policy changed line alone does not prove a rule update. The same line also appears when the token has not changed, followed by Sweep complete — no violators found. To confirm that new rules arrived, look for the ⚫️ New line with a new token.

Lines you can ignore

• RemoteManagementMCXProfile … The declarations profile cannot be installed via MDM. It is logged as an error on every sync in this healthy run, including syncs where nothing changed.
• kernel: (Sandbox) … wdavdaemon … deny(1) file-read-data /private/var/db/rmd/secure/Status/…. That is Microsoft Defender being refused access to the declaration’s status file. The deployment still succeeded.

Troubleshooting

These are the problems hit while testing this post, with the cause and the fix for each.

One more comes from Apple’s documentation and was not tested here. Any binary rule also blocks unsigned, ad hoc-signed and development-signed binaries, so in-house tools can stop working. codesign -dv <path> shows Signature=adhoc for an ad hoc-signed binary.

Find the rule the Mac rejected

A rejected profile leaves two error lines in the log:

22:21:03.689 ManagedPreferencesSubscriber [ProfileTransformer] Binary identifier has no usable fields
22:21:03.691 ManagedPreferencesSubscriber [configurationMultipleApplicator] Failed to apply new configuration: …Restrictions/6EE8E3AF-…:M2MxNzFj…c3M=.MTAzNTg5RjQ= error:…invalidConfiguration("Binary identifier has no usable fields")

The two long strings in the second line are base64. They decode to the declaration identifier and its token, which tells you which profile failed:

echo "M2MxNzFjNmQtOThlZC00MDhlLWI1ZTAtNzFmNGU2OWFmMDNkX2NvbS5hcHBsZS5jb25maWd1cmF0aW9uLmFwcC5zZXR0aW5ncw==" | base64 -d

That prints 3c171c6d-98ed-408e-b5e0-71f4e69af03d_com.apple.configuration.app.settings.

To find the rule, open the per-setting status for the device in Intune. Each rule appears with its index. The broken rule is the one with a Signing State row and no Team ID, Signing ID or CD Hash row. In the test it was Allowed/DeniedBinaries/[0]/SigningState, a leftover deny rule inside the allow profile.

List what is being blocked

sudo log show --last 8h --predicate 'subsystem == "com.apple.devicemanagementclient.managedeventsd" AND category == "LaunchPolicy" AND eventMessage CONTAINS "DENIED"'

Each line gives the process ID and the full path of a blocked binary. It is the quickest way to see what an allow list still needs.

Wrap-up

macOS 27 puts binary control and privacy defaults in one declaration, and the Intune settings catalog already has the settings. Three points from the testing:

• Start with a deny rule. It blocks the launch, and the alert names your organisation.
• Plan an allow list before you assign it. It quits running apps that are not on the list, with no alert. A rule with only Signing State gets the whole profile rejected.
• Privacy defaults are a suggestion. The user still answers one consent prompt. Succeeded in Intune means the Mac accepted the declaration, not that the user selected Allow.

Part 2 will cover device management, the next page in Apple’s What’s New for IT at WWDC26.