← Field Notes
Privacy · Deep dive

Local Network is the one macOS privacy prompt MDM cannot answer

R Rob Flanagan · · 7 min read

Nearly every privacy prompt in a macOS rollout has a payload behind it. This one does not, and the only person holding the switch is the user who already said no.

A user clicks Deny on one Local Network prompt. One toggle inside that account undoes it, and neither your MDM nor a TCC reset is that toggle. Apple's technote states the constraint in a single sentence: device managers are not able to configure local network privacy using MDM.

That is unusual. Nearly every privacy prompt in a macOS rollout has a payload behind it, and Privacy Preferences Policy Control can pre-grant something as broad as Full Disk Access without the user seeing anything. Local Network is not a PPPC service at all, so there is no key to write and no profile to scope.

I have managed Mac fleets for years. Local Network is one of the few permissions I have never had a payload to write, and the first time it matters is usually the day an app that scans for printers stops finding them on a few hundred Macs at once.

Apple states the MDM limit directly

TN3179 is the authoritative document, and it does not hedge:

Device managers aren't able to configure local network privacy using MDM.Apple, TN3179: Understanding local network privacy

Read that as a statement about the per-app privilege. It is not a claim that no administrator lever exists anywhere, and one broad lever does exist further down this page. It means there is no per-app grant, no per-app deny, and nothing to scope to a Smart Group.

Local Network is not a PPPC service, and Location is in the same position

The distinction that trips people up is that Local Network sits outside TCC entirely, so the tools built for TCC do not reach it.

Apple's Developer Technical Support says so plainly, naming Local Network and Location as the two critical outliers among the privileges shown in System Settings > Privacy & Security. That is also one reason a TCC reset does not clear a Local Network decision: the decision was never TCC's to hold.

The shipping PPPC schema makes the same point by omission. It carries 24 service keys, and sorting them is the fastest way to see where the gap is:

  • MDM can grant: 20 of them, including SystemPolicyAllFiles, which System Settings calls Full Disk Access
  • MDM can only deny: exactly four — Camera, Microphone, ScreenCapture and ListenEvent
  • Outside that schema, with no per-app MDM grant: Local Network and Location

Note the middle row is four, not three. ListenEvent carries the same deny-only sentence as the three services usually listed, and it is easy to miss.

macOS exempts more than you expect, and the exemption list contains a trap

macOS automatically allows local network access for three categories:

  • any daemon started by launchd
  • any program running as root
  • command-line tools run from Terminal or over SSH, including any child processes they spawn

The trap is in the first line. The exception for launchd daemons does not apply to launchd agents. A script you run over SSH is exempt, and the same code shipped as a user LaunchAgent is not.

This is why a rollout can pass every test and still fail in production. Root and SSH are the exempt path, so testing through them proves the code works and proves nothing about the privilege. Test it the way the user launches it.

One category needs no privilege at all: high-level services that use Bonjour internally, AirPlay among them, do not require local network access, because those services isolate the app from any details about the local network. There is nothing to prompt for.

No reset returns the privilege to undetermined

On macOS there is no way to reset a program's Local Network privilege to the undetermined state. Apple files that under a radar number, FB14944392, which is a fair signal of how it is regarded.

macOS also keeps that state separately for each user account. That has two consequences worth planning around: a fresh account gets the prompt again while the original account stays denied, and a per-device fix does not travel with the user.

Apple documents two testing alternatives: restore a virtual machine from a snapshot taken before you installed the program, or create a new user account and test there. Neither resets the decision in place. Separately, Apple's Developer Technical Support states there is no supported way to remove orphaned Local Network entries from the System Settings list.

A user can turn access back on. Apple documents that path in System Settings, where each listed app has a switch for local network access. It is per device, per user account, and done by hand.

No MDM reporting path is documented either

Apple's device-management schema has no MDM query and no declarative status item that returns an app's Local Network state, so there is no documented way to report on it through MDM. A sweep of the release branch's status directory finds 40 shipping declarative status items — its 48 entries minus seven test.* fixtures and the shared statusreason.yaml — and none of them is privacy, TCC, or Local Network related.

State that as a documentation boundary rather than an impossibility. An app can detect its own denial, and on-disk preference files exist. What Apple does not do is give you a supported way to ask the fleet.

Building an extension attribute is harder than it looks, and the reason is the exemption list above. An inventory script running as root is exempt, so a probe would report healthy on every Mac including the ones where the app is denied. The exemption that lets the script run is the same exemption that makes it blind as a test. The useful thing to read is the stored consent decision, and Apple calls the on-disk form an implementation detail whose presence and format you should not rely on.

The one broad lever Apple does document

Apple documents two preferences that exempt address ranges from local network privacy: AllowedEthernetLocalNetworkAddresses for wired interfaces and AllowedWiFiLocalNetworkAddresses for Wi-Fi, both in the com.apple.network.local-network domain, each taking an array of CIDR strings. They debuted in macOS 15.5.

Four properties decide whether this is useful to you:

  • It is a preference, not an MDM payload. Apple documents a sudo defaults invocation and does not document a payload for it.
  • It affects the entire system, which is why Apple says to set it with sudo.
  • It requires a restart to take effect.
  • It is not an undo. The system stops treating those addresses as local at all, so local network privacy stops blocking any app from them. The app's privilege stays denied.

Apple positions it at site administrators and continuous-integration systems, which is the honest scope. It is a blunt instrument for a known subnet, not a per-app repair.

macOS 27 adds a per-app default, with real limits

The macOS 27 seed schema adds a per-app Local Network default to the declarative App Settings configuration. It is worth watching, and it is worth reading carefully before it becomes a plan.

In the seed, the setting is supervised-only, user-scoped, and AppKit-only, the user can decline it, and the schema defines None and Allow with no Deny. Apple's own documentation also says the consolidated prompt omits permissions the user has already seen, and it does not document changing an existing Denied decision, so do not assume the default repairs a Mac that is already denied.

This is pre-release, and Apple's page carries the standard warning that pre-release features may change or be removed. Read it as direction rather than plan.

The direction itself is the interesting part. On the same seed branch, the TCC payload schema marks the PPPC keys for Camera, Microphone, Accessibility, SpeechRecognition, and BluetoothAlways deprecated at 27.0, and several point at the declarative Privacy key. Apple is moving per-app privacy onto user-consented declarative defaults rather than adding Local Network to the old silent-grant model.

Sort your permissions before the next rollout

Before your next macOS Tahoe rollout, or your first macOS 27 test build, put every privacy permission your fleet depends on into one of three piles: the ones MDM can grant, the four it can only deny, and the ones that sit outside the schema. Local Network belongs in the third pile with Location, and anything in that pile needs a plan that does not start with a profile.

For the permission that does have a payload but is losing its silent grant, see the one PPPC grant macOS 27 takes back and PPPC on macOS 27 still needs a profile. The broader move to declarative configuration is covered in what macOS 27 moved to declarative.

Has anyone built an extension attribute that reads the stored Local Network state reliably? Root is exempt, so probing proves nothing.

Sources

Apple primary sources, retrieved 2026-07-21 and re-verified live on 2026-08-05:

← Back to Field Notes