macOS 27 changes how Macs are managed: binary control is in, PPPC is out

Two things changed for Mac management at WWDC 2026, and both are a bigger deal than the headlines made them sound.

The first: you can now tell a Mac exactly which programs are allowed to run, command-line tools included. If it is not on the list, the operating system stops it. The second: PPPC, the privacy profile every Mac admin has wrestled with for years, is being retired in favour of something far simpler.

Neither got much attention next to the Siri news. But if you run a fleet of Macs, these two are the changes that will actually land on your desk. Here is what they are, in plain terms, and what to do before macOS 27 ships in the autumn.

The Mac finally gets proper application control

For years there has been an awkward gap between iPhones and Macs. On a supervised iPhone you could hand an admin a clean allow list of apps, and nothing else would run. On a Mac you got blunt instruments: Gatekeeper, which only cares whether an app is signed and notarised, and a clumsy "allow apps downloaded from" setting that offered App Store, known developers, or anywhere. Real application allowlisting meant buying a third-party tool and bolting it on.

macOS 27 closes that gap. Apple has added native binary control through the Endpoint Security framework, driven by two new keys in the device management schema: AllowedBinaries and DeniedBinaries. You declare what is permitted, and the OS enforces it.

The detail that matters is how it matches. Per Apple's own deployment guide, binaries are identified by CD Hash, Team ID, or signing ID. So you can be as broad or as tight as you like:

• Team ID allows everything signed by one developer. Trust Adobe, get every Adobe tool.
• Signing ID narrows it to a specific application from that developer.
• CD Hash pins one exact build, down to the cryptographic fingerprint. Nothing else passes, not even a different version of the same app.

And it is not limited to apps you double-click. It covers binaries, which means command-line tools too. That is the part the old controls never touched. A script kiddie's downloaded curl one-liner, a rogue binary dropped in /tmp, an unsanctioned developer tool: if the build is not on your allow list, it does not execute. This is the layer that techniques like ClickFix lean on, where the user is tricked into running a command by hand, so closing it off at the OS matters.

You are not starting from zero, either. There is an AlwaysAllowManagedApps key that automatically permits the apps you already deploy through MDM, so your managed software keeps running without being listed by hand. And this same declaration replaces that old "allowed from" source restriction, folding App Store, identified developers, and the rest into one unified policy instead of a separate toggle.

For a regulated business this is the line that opens doors. Application allowlisting is something auditors ask about directly. ManageEngine maps the new control to NIST SP 800-53 and ISO 27001:2022 software-integrity requirements. Until now, ticking that box on Mac meant extra spend on a dedicated product. From macOS 27 it is a native declaration, defined once, enforced by the operating system.

A word of caution before anyone gets excited and locks everything down on a Friday afternoon. An allow list is only safe if it is complete. Miss a legitimate tool your finance team runs once a quarter, and you will hear about it at the worst possible moment. This is a feature you roll out in deny-nothing reporting mode first, watch what really runs, then tighten. We will come back to that.

PPPC is dead, long live the privacy framework

If you have ever managed Macs, you know the pain of PPPC. Privacy Preferences Policy Control was the profile you built so that Zoom could see the camera, your backup tool could read the disk, and your RMM agent could control the screen, all without the user being nagged to approve each one. It worked, but it was fiddly, easy to get wrong, and every app needed its own carefully formatted entry.

macOS 27 retires it. In its place is a declarative privacy framework built on a new Privacy key, and it works the way PPPC always should have.

There are two halves to it, both confirmed in Apple's app management guide:

For apps, the Privacy key lives in com.apple.configuration.app.settings (iOS 27, iPadOS 27 and macOS 27). One key, one place, and it covers Accessibility, Bluetooth, Camera, Dictation, Local Network, Location, Location Accuracy and Microphone. You pre-set the permissions an app should have, and the user gets a single consolidated consent prompt rather than a drip-feed of separate dialogs.

For websites, the same idea now reaches Safari. The Privacy key in com.apple.configuration.safari.settings lets you set Camera and Microphone permissions per domain, or by wildcard domain. If your team lives in a browser-based video tool or a web app that needs the mic, you can grant it cleanly across the fleet instead of leaving each person to fumble through Safari's site settings.

The old way is officially on the way out. Apple's guide states the corresponding keys in com.apple.TCC.configuration-profile-policy are deprecated in iOS 27, iPadOS 27 and macOS 27. Deprecated is not removed, so your existing PPPC profiles will keep working through this cycle. But Apple has shown its hand. The new keys are where everything goes from here.

The user-facing win is real, too. Prompt fatigue is a genuine security problem. When people are trained by years of pop-ups to click "Allow" on autopilot, they will allow the wrong thing eventually. One clear, admin-shaped consent screen beats ten guesses.

This all rides on Declarative Device Management

Both of these features share a foundation, and it is worth naming. Declarative Device Management, or DDM, has been Apple's modern management protocol for a few years, but it lived alongside the old profile-push model as a sort of preview. At WWDC 2026 Apple moved it to the standard. Binary control, the new privacy framework, credential handling, health reporting: every major announcement this year is built on it.

The practical difference with DDM is that the device does the work. Instead of the server pushing a profile and hoping it sticks, the Mac holds a set of declarations and keeps itself in that state, reporting back when something changes. It is faster, more reliable, and it scales without hammering the MDM server.

A few other macOS 27 changes land on the same foundation and are worth a mention:

• Software finally uninstalls cleanly. A new UninstallBehavior key with a Remove option means deleting an app's declaration actually removes the app, closing a long-standing gap where pulling a config left the software sitting on the device.
• Credentials are declared once. You define a certificate or credential a single time, and your DNS proxy, VPN, SSO and content filter configs all reference it. Rotate it once, and everything that depends on it follows, instead of editing every profile by hand.
• Hardware health reporting arrives for iPhone and iPad through a new device.system.health status item, surfacing the genuineness and status of components like the baseband, camera, Face ID, Touch ID, NFC and Ultra-Wideband. Useful for spotting tampered or failing devices before they are redeployed.

If you want the source straight from Apple, the WWDC session What's new in managing Apple devices walks through the lot.

What to do before the autumn

macOS 27 follows Apple's usual rhythm: a public beta over the summer, general availability in the autumn. That gives you a clear runway, and the worst plan is to do nothing and meet these changes for the first time when staff devices start updating.

Here is the order we are working through, and the order we would suggest for any managed fleet:

1. Get the beta into a pilot ring now. A handful of non-critical Macs on the macOS 27 beta, enrolled in your MDM, so you can see the new declarations in your console and test before anything real depends on them.
2. Turn on binary visibility before enforcement. Watch what actually runs across the pilot group first. Build your allow list from real data, not from a guess about what people use. Only then switch from reporting to blocking.
3. Migrate your noisiest PPPC apps first. Pick the three or four apps that generate the most permission prompts and rebuild them on the new Privacy key. You will feel the benefit immediately and learn the workflow on low-risk targets.
4. Check your MDM is keeping pace. These are native Apple declarations, so any current MDM will get them, but vendors expose new keys at different speeds. Confirm your platform supports the macOS 27 schema before you rely on it. If you are weighing platforms anyway, our Jamf vs Intune vs Iru comparison is a good starting point.
5. Fold it into your security baseline. Binary control and the privacy framework both map onto the controls in our Mac security baseline guidance, and both help on the compliance side. Document them as part of your standard build.

The short version: macOS 27 hands Mac admins two tools they have wanted for years, native application control and a privacy model that is not a fight to configure. They are genuinely good changes. They are also the kind that bite if you flip them on without testing. Pilot over the summer, build from real data, and you walk into the autumn ready instead of reacting.

This is the sort of platform shift we plan and roll out for clients as a matter of course. If you run Macs and want the new controls in place cleanly before macOS 27 lands, that is what we do.