SS Mac Admin

Why EdgeUpdater Won't Stop Asking for Permission — and How to Fix It

2026-05-11T00:00:00Z

Latest talk on the town if you're managing macOS devices with Intune is likely the scenatio that your users are getting spammed by a popup saying "EdgeUpdater would like to access data from other apps" — and clicking Allow does absolutely nothing — this post is for you.

What's Actually Happening

This is a macOS TCC (Transparency, Consent, and Control) enforcement issue, made worse by the presence of MDM — and it involves two separate TCC services, not one.

EdgeUpdater — Microsoft's background updater for Edge, which runs as a separate process from the browser itself — makes two distinct TCC requests on each run:

kTCCServiceSystemPolicyAllFiles (Full Disk Access) — needed to read and write its own coordination files, including a shared preferences lock (GlobalPrefs) that synchronises state between its concurrent processes. On MDM-managed devices with a restrictive PPPC profile, this is silently denied — no popup, no prompt, just a blocked syscall.

kTCCServiceSystemPolicyAppData (App Data) — a more targeted service protecting access to other apps' container data. This is what generates the popup: "EdgeUpdater would like to access data from other apps." Because there's no MDM rule covering this service at all, TCC falls through to prompting the user.

So the popup isn't coming from the Full Disk Access denial — that one fails silently. The popup comes from the App Data request, which has no MDM policy either way and therefore asks the user. Clicking Allow still does nothing, because the underlying FDA denial causes EdgeUpdater to crash and respawn immediately, triggering the whole sequence again.

When FDA access is blocked, the cascade of failures looks like this:

It can't acquire GlobalPrefs → multiple instances spawn without coordination
It can't read its own Keystone compatibility data → version state is lost each run
It can't determine which version of itself is "active" → version arbitration fails
Every new instance hits TCC → every new instance triggers the popup

On MDM-managed devices, TCC decisions for managed services are authoritative and user-immutable. The auth_reason value in the TCC database will be 5 — MDM policy — which means user consent is completely bypassed for the FDA request. The App Data prompt appears, but any Allow response is rendered meaningless by the underlying crash loop caused by the FDA denial.

Non-enrolled devices don't have this problem because there's no MDM policy overriding TCC, so the standard user consent flow works as intended for both services.

How We Diagnosed It

Step 1 — Query the TCC database

sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db \
  "SELECT client, service, auth_value, auth_reason FROM access WHERE client LIKE '%EdgeUpdater%';"

Output:

com.microsoft.EdgeUpdater|kTCCServiceSystemPolicyAllFiles|0|5

Two fields told the whole story:

auth_value = 0 → denied
auth_reason = 5 → MDM-enforced, user cannot override

Step 2 — Check for an existing PPPC profile

sudo profiles show -all | grep -A 30 -i "EdgeUpdater"

Returned nothing. No explicit PPPC entry for com.microsoft.EdgeUpdater — meaning it was being caught by a blanket restrictive policy with no allowlist entry for EdgeUpdater specifically.

Step 3 — Find the binary and confirm the process storm

ps aux | grep -i edge

Revealed EdgeUpdater running from a versioned path under ~/Library/Application Support/Microsoft/EdgeUpdater/, with multiple concurrent instances — --wake, --server, --install — all spawning in a tight loop. Each one hitting TCC, each one triggering a popup.

Step 4 — Extract the code requirement

codesign -dr - ~/Library/Application\ Support/Microsoft/EdgeUpdater/149.0.4019.0/EdgeUpdater.app 2>&1

Output:

designated => identifier "com.microsoft.EdgeUpdater" 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

UBF8T346G9 is Microsoft's Apple Developer Team ID. This is the designated requirement string needed for the PPPC payload — without it, the policy can't cryptographically verify the binary identity.

Step 5 — Catch it live with the TCC log stream

To observe TCC decisions in real time, the key is filtering on tccd — the TCC daemon that makes and logs all decisions — not on the requesting process itself. EdgeUpdater triggers the check, but the log entries are written by tccd:

log stream --predicate 'subsystem == "com.apple.TCC" AND composedMessage CONTAINS "EdgeUpdater"' --info

This captured two distinct access requests firing simultaneously when the popup appeared:

Request 1 — Full Disk Access (silent denial):

Handling access request to kTCCServiceSystemPolicyAllFiles
ReqResult(Auth Right: Denied (Service Policy), promptType: 1, DB Action: None)

Denied by MDM policy before any prompt is shown. DB Action: None means it didn't even write to the TCC database — the policy short-circuits evaluation entirely.

Request 2 — App Data (generates the popup):

Handling access request to kTCCServiceSystemPolicyAppData
ReqResult(Auth Right: Unknown (Service Policy), promptType: 1, DB Action: None, UpdateVerifierData)

Unknown means no MDM rule exists for this service, so TCC falls through to the user prompt. The purpose string macOS displays is pulled directly from the system default:

'Keeping app data separate makes it easier to manage your privacy and security.'

Also notable: both requests arrive via com.apple.sandboxd as the requesting process, acting as a broker for the TCC check on EdgeUpdater's behalf.

What the EdgeUpdater log confirmed

The updater.log file at ~/Library/Application Support/Microsoft/EdgeUpdater/updater.log added further context:

Failed to acquire GlobalPrefs — In my logs, it repeated every ~3 minutes through the night, confirming FDA denial was blocking inter-process coordination
CloudPolicyOverridesPlatformPolicy=1 — Intune cloud policy is set to override local platform policy, which is why the MDM denial wins unconditionally
Two EdgeUpdater versions in conflict — v147 (bundled inside Edge 148) and v149 were both trying to register simultaneously, compounding the lock failure
ECS fetch disabled by policy — Edge Configuration Service fetching is disabled by an Intune policy, expected in a managed environment

The Root Cause

This is where it gets interesting. The issue occurred in a lab tenant with no explicit PPPC profile restricting Full Disk Access — no allowlist, no deny rules, nothing targeting EdgeUpdater. Yet the TCC database still showed auth_reason=5 (MDM policy) with auth_value=0 (denied). But the same issue also surfaces in tenants where restrictive PPPC profiles are applied. Did Microsoft pull an oopsie with Edge?

One probable explanation is that macOS applies a default-deny MDM posture for certain TCC services on enrolled devices, even without an explicit administrator-configured restriction — meaning the absence of an explicit allow rule may be treated as an implicit deny with MDM authority, rather than falling through to the standard user consent flow. This would explain the clean-tenant behaviour, but it's an inference rather than something Apple formally documents.

What we can say with confidence is that the fix is the same regardless of which path led here: EdgeUpdater needs to be explicitly allowed, and the absence of a deny rule is not sufficient. Whether that's because your PPPC profile doesn't list it, or because MDM enrollment alone triggers the governed posture, the end state is identical — auth_reason=5, popup storm, clicking Allow does nothing.

EdgeUpdater doesn't live in /Applications and isn't visible in the standard Privacy & Security UI until it's already tried (and failed) to get access. It installs itself into the user's Library under a versioned path, and Microsoft bundles a copy of it inside the Edge app bundle itself as a bootstrapper. There's no obvious signal that a PPPC entry is needed until users start reporting the popup — and Microsoft's own Intune deployment documentation doesn't mention it.

The Fix

1. Add EdgeUpdater with mobileconfig

SystemPolicyAllFiles (Full Disk Access) is the only entry required. Testing on a device with the FDA PPPC entry applied confirmed no popup appeared, and the TCC log stream showed every FDA request hitting Auth:Allowed (MDM Policy) — with EdgeUpdater successfully completing version arbitration and cleaning up the older version folder on its own.

If you deploy PPPC policies with a .mobileconfig or other means, add the following lines under SystemPolicyAllFiles to allow EdgeUpdater and remove the pop ups.:

<key>SystemPolicyAllFiles</key>
<array>
    <dict>
        <key>Allowed</key>
        <true/>
        <key>CodeRequirement</key>
        <string>identifier "com.microsoft.EdgeUpdater" 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</string>
        <key>Comment</key>
        <string>Microsoft EdgeUpdater - Full Disk Access</string>
        <key>Identifier</key>
        <string>com.microsoft.EdgeUpdater</string>
        <key>IdentifierType</key>
        <string>bundleID</string>
        <key>StaticCode</key>
        <false/>
    </dict>
</array>

Use bundleID as the identifier type rather than a path — EdgeUpdater installs under a versioned path that changes with every update, so a path-based identifier would break on each upgrade. Note that this applies whether EdgeUpdater is installed at system scope (/Library/) or user scope (~/Library/) — the bundle ID and code requirement are identical in both cases.

2. Add EdgeUpdater with Intune Template:

If you deploy PPPC via the Device Restrictions template in Intune rather than a custom mobileconfig, configure the template as follow: Name: EdgeUpdater
IdentifierType: BundleID
Identifier: com.microsoft.EdgeUpdater
Code Requirement: identifier "com.microsoft.EdgeUpdater" 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

And then set Full disk access to Allow.

Bonus: A Note on PSSO

The updater log also showed this on every single run:

Device is MDM enrolled. Checking for Microsoft Corp tenant.
No tenant ID in PSSO device cert.
Microsoft Corp tenant not found via any layer.

EdgeUpdater actively checks whether the device is enrolled in a Microsoft Corporate tenant via Platform SSO. If you're planning to roll out PSSO with Intune — or already have it partially configured — it's worth verifying that the device certificate is correctly scoped to your tenant. This won't cause the popup issue, but it does affect EdgeUpdater's ability to use enterprise update channels and Microsoft-side management policies.

Simplified Setup for PSSO with Intune

2026-05-09T00:00:00Z

Something I've wanted since Platform SSO first landed in Intune and with the release of macOS Tahoe 26, we finally have it. Simplified Setup brings PSSO into the Setup Assistant itself, so the whole thing happens during first boot. No waiting for a popup on the desktop to register, no hunting through System Settings to allow access. Here's how it flows:

The Mac sits in Setup Assistant and waits until Company Portal and the required config profiles have finished installing.
macOS then kicks off PSSO registration automatically — no user action needed.
The user signs in with their Entra ID account, and macOS creates the local account based on that identity. Already registered with PSSO from day one.

Let's jump in.

Configuration in Intune

First we need to add one thing to the Platform SSO configuration that we deploy to the machines. If you haven't already implemented Platform SSO yet, create a new Configuration Profile with the Setting Catalog as the Profile Type. Follow the instructions on how to set up the basics from the Microsoft Learn portal how to set it up.

However - this is where we add the extra delicious sauce that will make this otherwise dry feature really shine. In the Settings Picker navigate to Authentication -> Extensible Single Sign On (SSO) and find the option for Enable Registration During Setup. Then you need to Enable this setting. Review and save the profile. Settings Catalog configuration:

Here's the other quirk - we need the latest Beta version of the company portal! I tried a LOT with the latest version that's available from Microsoft's own download url but it did not work (As of writing this today, 9th of May, the latest version from Microsoft is 5.2603.0). You get stuck during the Setup assistant and it will tell you it's the wrong username or password. You need the version with version number 5.2604.0. Deploy it as a Line of Business app and assign it. You can download 5.2604 from HERE.

Enrollment flow

You will go through the enrollment with the Setup Assistant normally, with a few screens added. I'll dump some screenshots of the flow. Some quirks that need to be ironed out but it's working as intended. But I would keep this out of production until it's gotten a public release.

First you start off with your language and region as usual and then prompted for the ADE that your organization will manage the device. After the initial download of configuration and the creation of a local mac account, you will be greeted with this view:

You then log in with your Entra ID and password.

Which then will start the registration of the device.

You then set up TouchID and other optional steps if it's enabled in your enrollment profile. Once that's done, you'll see the following prompt, click Continue and follow the log in prompts/MFA when asked.

Once done, your device is now fully prepared for Platform SSO, users don't need to do anything else on the device regarding SSO and can instantly log on to Outlook, Teams, Edge, etc.

We can also verify it after enrollment that the user account is PSSO enabled from System Settings -> Users & Groups or run the app-sso platform -s command in the terminal to verify everything is correct.

Happy labbin'!

macOS Firewall in Intune: The Compliance Policy Enforcement Trap

2026-04-29T00:00:00Z

Introduction

The macOS Application Firewall looks simple in the Intune admin portal. A few toggles, some bundle ID fields, a compliance checkbox. Many admins assume the mental model is straightforward: Configuration Profiles configure things, Compliance Policies check things. Set them both up, and you are good to go.

But time and time again, I see threads on reddit or in Discord channels where it appears the fire is really tearing down the wall - "Why can't I transfer facetime calls?", "The users can't use sidecar with their iPads" or that some other service can't communicate with the device.

So here I am giving it a shot to to tell you that the mental model is wrong — and in the specific case of macOS firewall settings, the gap between assumption and reality is wide enough to completely break your security design without leaving a single error message anywhere in the portal.

This post goes deep on three things that are consistently misunderstood:

What Block all incoming connections actually does to the macOS Application Firewall at the OS layer — and why it makes your allow-list irrelevant
Why Intune Compliance Policies do not just check firewall state — they enforce it — and exactly what that means for your Configuration Profiles
How to design a firewall policy in Intune that works as intended, verified at the command line

Part 1: The macOS Application Firewall — What It Actually Is

Before touching Intune, you need a solid mental model of the macOS Application Firewall itself, because the confusion in Intune directly mirrors confusion about how the OS works.

Two firewalls in macOS

macOS actually ships with two completely separate firewall subsystems:

socketfilterfw — the Application Firewall. This is what Intune manages. It operates at layer 7 (application layer) and controls whether individual applications can receive incoming connections.
pf (Packet Filter) — the BSD-level network firewall inherited from OpenBSD. This operates at layer 3/4 (network/transport layer) and is not managed by Intune or the standard macOS firewall UI.

Everything in this post is about socketfilterfw. When the Intune firewall profile or the System Settings "Firewall" toggle is involved, that is the subsystem you are interacting with.

Two operational modes in socketfilterfw

This is the most important thing to understand, and the thing that almost every write-up on macOS firewall in Intune gets wrong by omission.

socketfilterfw operates in one of two fundamentally different modes:

Mode 1 — Rule-based (block-all = OFF)

The firewall is active and evaluates incoming connection attempts against a per-application rule table. Each app either has an explicit Allow or Block rule, or defaults to prompting the user. This is where your bundle ID allow/block list lives and where it is evaluated.

Mode 2 — Block-all (block-all = ON)

The firewall ignores the per-application rule table entirely for inbound connection decisions. It short-circuits to "deny" before any rule lookup happens. Your allow-list is still stored — it has not been deleted — but it is never consulted. The state transitions look like this in the socketfilterfw binary:

--setblockall on   → Block-all mode  (rule table ignored for inbound)
--setblockall off  → Rule-based mode (rule table evaluated for inbound)

This is not a matter of priority or precedence. When block-all is active, the firewall is operating in a categorically different way. Think of it like disabling AV real-time scanning: your AV rules still exist, but the engine that evaluates them is off.

What Block All Incoming Connections actually allows through

Even in block-all mode, macOS keeps a handful of essential network services alive. Specifically:

DHCP — so the device can obtain/renew an IP address
Bonjour / mDNS — so local service discovery works
IPSec — so VPN tunnels using IPSec can be established

Everything else — screen sharing, remote management, AirDrop, Apple Remote Desktop, file sharing, and any listening socket your VPN client or remote support tool might need — is blocked. No exceptions. No way to create exceptions while this mode is active.

Verifying firewall state at the command line

This is something every Mac admin should have in their toolkit. The definitive way to check what the Application Firewall is actually doing on a device — regardless of what the portal says — is:

/usr/libexec/ApplicationFirewall/socketfilterfw \
  --getglobalstate \
  --getblockall \
  --getallowsigned \
  --getstealthmode

Sample output on a device in block-all mode:

Firewall is enabled. (State = 1)
Block all ENABLED
Automatically allow signed built-in software ENABLED
Automatically allow downloaded signed software DISABLED
Stealth mode ENABLED

If Block all ENABLED is the output, your allow-list is irrelevant until you change that. You can also dump the full app-level rule table to confirm your bundle ID rules are present (but not being evaluated):

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps

This command is the ground truth. Not the Intune portal. Not a profile deployment status page. Run this on the device.

The macOS Sequoia change you need to know about

Starting with macOS 15 (Sequoia), Apple made a significant change: Application Firewall settings are no longer stored in /Library/Preferences/com.apple.alf.plist. If you have any scripts, tools, or monitoring workflows that read or write to that plist directly, they will stop working. The canonical interface is now socketfilterfw exclusively. Apple also deprecated the EnableLogging and LoggingOption keys in the Firewall MDM payload, as application firewall logging is now enabled by default for the socketfilterfw process.

If your firewall compliance scripts or configuration validators read com.apple.alf.plist, audit and update them now.

Part 2: The Intune Policy Landscape — Where Things Can Go Wrong

Three places in Intune where you can touch the firewall

Administrators can interact with macOS firewall settings from three different surfaces in the Intune admin center:

1. Configuration Profile → Endpoint Protection template Path: Devices > Configuration > Create > macOS > Endpoint Protection Payload deployed: com.apple.security.firewall Capabilities: Full control — enable/disable firewall, block-all toggle, stealth mode, per-app allow/block rules via bundle ID

2. Settings Catalog Path: Devices > Configuration > Create > macOS > Settings Catalog → Firewall Payload deployed: com.apple.security.firewall Capabilities: Same as above, with more granular key-level control including Automatically allow built-in software and Automatically allow downloaded signed software (macOS 12.3+)

3. Compliance Policy → Device Security Path: Devices > Compliance > Create policy > macOS → System Security → Device Security Settings available: Firewall enabled/disabled, Block all incoming connections, Stealth mode

The critical difference between surfaces 1/2 and surface 3 is not visible in the UI — and that invisibility is the root cause of most firewall misconfiguration stories in the Mac admin community.

The payload: com.apple.security.firewall

All three surfaces ultimately interact with the same Apple MDM payload type. According to Apple's platform deployment documentation, the com.apple.security.firewall payload:

Has payload identifier com.apple.security.firewall
Supports macOS device channel
Supports Device Enrollment and Automated Device Enrollment
Allows duplicates: True — more than one Firewall payload can be delivered to a device simultaneously

That last point — duplicates allowed — is architecturally significant and we will come back to it.

What happens when two Firewall payloads are installed

When multiple com.apple.security.firewall payloads are installed on a Mac simultaneously (which is possible and happens in practice when both a Configuration Profile and a Compliance Policy address firewall settings), macOS processes both. The question is: how does it resolve conflicting values?

Apple's general documented behavior for duplicate payloads is that they are matched by PayloadUUID. If two payloads have different UUIDs (which a Configuration Profile and a Compliance Policy remediation payload will), they are treated as independent, additive payloads. For security-related boolean settings like BlockAllIncoming, the most restrictive value across all installed profiles wins. If any installed profile has BlockAllIncoming = true, block-all mode is active — regardless of what another profile says.

This is not a Compliance Policy "overriding" the Configuration Profile in a strict policy hierarchy sense. It is Apple's firewall logic taking the most restrictive applicable setting across all installed profiles. The practical result is the same, but understanding the mechanism matters for troubleshooting.

Part 3: Why Compliance Policies Are Not Read-Only

This is the question that trips up Intune admins and causes confusion beyond belief: why does a Compliance Policy change the firewall setting instead of just checking it?

The conceptual model vs. reality

The expected model in most device management systems:

Configuration Policies  →  actively configure device state
Compliance Policies     →  passively read and evaluate device state

In practice in Intune, this model does not hold for macOS firewall settings. Microsoft's own documentation states it directly: "Compliance policies verify the device settings you configure and can remediate some settings that aren't compliant." And further: "If there are configuration settings that conflict between compliance policies and other policies, then the compliance policy takes precedence."

That is not ambiguous. Compliance Policies in Intune are not passive observers for all settings. For certain settings — macOS firewall included — they are enforcement agents.

The remediation mechanism

When Intune evaluates a macOS device against a Compliance Policy and finds that Block all incoming connections is required but not active, the Intune management agent does not simply mark the device non-compliant and wait for user action. For this class of settings, it pushes a com.apple.security.firewall payload to bring the device into the required state.

This means the sequence on the device is:

Configuration Profile is installed during enrollment → deploys com.apple.security.firewall with BlockAllIncoming = false and an allow-list
Compliance Policy evaluates device → finds BlockAllIncoming = false when it requires true
Intune pushes a compliance remediation payload → com.apple.security.firewall with BlockAllIncoming = true
Both payloads are now installed simultaneously
macOS resolves the conflict → most restrictive value wins → block-all mode active
Your allow-list is now irrelevant at the OS layer

Step 6 happens silently. The Intune portal will show the Configuration Profile as successfully deployed. The firewall profile's per-app rules will appear correctly configured. Nothing shows as an error. Apps just stop being able to receive inbound connections.

Why some settings remediate and others do not

A useful contrast: OS version requirements in a Compliance Policy do not remediate. If you require macOS 14.0 and a device is running 13.7, Intune marks the device non-compliant and that is it. It does not push a software update — it cannot. That setting is genuinely read-only in compliance.

Firewall settings are different. Because Intune can push the required state via MDM payload, it does. This is a product design decision by Microsoft — they chose to make certain security posture settings auto-remediating in compliance rather than purely evaluative. The firewall is in that category.

Why this is not well documented

Frankly, the Intune documentation at the policy-level is sparse on this distinction. The Learn docs page for macOS Compliance settings uses language like "Block — Block all incoming network connections" in the firewall section without explicitly flagging that this will push enforcement, not just evaluate. The key phrase is buried in the general macOS getting started guide, not in the compliance settings reference. Most admins only discover this behavior after troubleshooting broken remote support tools or VPN connections post-policy deployment.

Part 4: Designing a Firewall Policy That Works as Intended

With the above as background, the design choices become clear. There are two coherent models, and exactly one incoherent one that is unfortunately easy to accidentally configure.

Model A: Controlled Allow-List (Recommended for Most Environments)

Goal: Firewall is active, all unsolicited inbound connections are blocked by default, but specific applications can receive inbound connections via an explicit allow-list.

Configuration Profile (Settings Catalog or Endpoint Protection template):

Setting	Value
Enable Firewall	Yes
Block all incoming connections	Not configured
Automatically allow built-in software	Yes
Automatically allow downloaded signed software	No (review per environment)
Enable stealth mode	Yes
Apps allowed (bundle IDs)	your allow-list here

Compliance Policy → Device Security:

Setting	Value
Firewall	Enable
Incoming Connections	Not configured
Stealth mode	Not configured

The key is the Compliance Policy: set Firewall to Enable so you get the compliance check that the firewall is on, but leave Incoming Connections and Stealth mode at Not configured. This avoids the compliance policy pushing any BlockAllIncoming payload that would conflict with your Configuration Profile's allow-list model.

Verify on device:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
# Expected: Firewall has block all state set to disabled.

/usr/libexec/ApplicationFirewall/socketfilterfw --listapps
# Expected: Your allowed bundle IDs listed with ALLOW rules

Example:

Settings Catalog configuration:

Compliance Policy Configuration:

Results on device:

Model B: Maximum Inbound Restriction (High-Security / Air-Gapped Posture)

Goal: All unsolicited inbound connections blocked, no exceptions. Appropriate for high-security endpoints where remote management tools and sharing services are not used.

Configuration Profile:

Setting	Value
Enable Firewall	Yes
Block all incoming connections	Yes
Enable stealth mode	Yes

Compliance Policy → Device Security:

Setting	Value
Firewall	Enable
Incoming Connections	Block
Stealth mode	Enable

In this model, both policies are aligned. There is no allow-list — because you understand that no allow-list will be evaluated while block-all is active. This model is appropriate for endpoints that are not managed via screen sharing or remote MDM tools that require inbound connections, and where the device posture requirement is strict.

Verify on device:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
# Expected: Firewall is blocking all non-essential incoming connections.

The Incoherent Model — What to Avoid

Configuration Profile: Firewall enabled, Block all incoming = No, allow-list defined with remote support tool bundle IDs

Compliance Policy: Firewall = Enable, Incoming Connections = Block

This is the trap. It looks intentional in the portal — you appear to have a nuanced Configuration Profile with a proper allow-list, and a Compliance Policy enforcing a required baseline. In reality, the Compliance Policy's Block setting pushes a BlockAllIncoming = true payload that makes your allow-list irrelevant. Your remote support tool cannot receive inbound connections. Screen sharing is broken. Nothing in the portal indicates a conflict.

The diagnostic command tells you immediately:

/usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
# Actual output: Block all ENABLED   ← not what your config profile says

Part 5: Practical Allow-List Reference

When you are running Model A and need to build an allow-list, keep it minimal. Here are the bundle IDs most commonly needed in enterprise Mac environments:

Remote support and management:

Application	Bundle ID
Microsoft Remote Desktop	`com.microsoft.rdc.macos`
TeamViewer	`com.teamviewer.TeamViewer`
AnyDesk	`com.philandro.anydesk`
Zoom (host/remote control)	`us.zoom.xos`

VPN clients:

Application	Bundle ID
Cisco AnyConnect	`com.cisco.anyconnect.gui`
GlobalProtect	`com.paloaltonetworks.GlobalProtect.client`
Zscaler Client Connector	`com.zscaler.tray`

Developer tooling (scope to dev device groups only):

Application	Bundle ID
Docker Desktop	`com.docker.docker`

Finding bundle IDs for unlisted apps:

osascript -e 'id of app "AppName"'
# Or:
mdls -name kMDItemCFBundleIdentifier /Applications/AppName.app

A few important notes on allow-list accuracy:

Bundle ID errors are silent. If you enter an incorrect bundle ID, the rule is installed but never matches any process. Nothing in the portal flags this. Verify bundle IDs from the device itself using the commands above, not from the internet.
Code-signed apps may not need explicit rules. Automatically allow built-in software and Automatically allow downloaded signed software in the Settings Catalog cover a lot of standard Apple and enterprise apps. Explicitly listing apps via bundle ID is most important for apps that are either unsigned, have non-standard signing, or where you need explicit control.
The allow-list is app-level, not port-level. If you need to control specific ports or protocols, that requires pf (the BSD packet filter), which is outside the scope of the Intune Firewall profile.

Summary: Key Takeaways

On the macOS Application Firewall:

socketfilterfw has two modes: rule-based and block-all. These are not degrees of the same thing — they are categorically different operating states.
Block all incoming connections = true disables per-app rule evaluation entirely. Your allow-list still exists on the device; it is simply not consulted.
Ground truth for firewall state is socketfilterfw --getblockall on the device, not the Intune portal.
macOS 15 (Sequoia) deprecated com.apple.alf.plist. Audit any scripts reading that file.

On Intune Compliance Policies:

Compliance Policies for macOS firewall settings are not read-only. Microsoft explicitly documents that they can remediate settings, and that compliance takes precedence over configuration policies when there is a conflict.
The mechanism is payload delivery: Intune pushes a com.apple.security.firewall MDM payload as remediation, not a separate enforcement channel.
When a Compliance Policy sets Block all incoming connections = Block, it installs a payload alongside any existing firewall Configuration Profile. macOS resolves the conflict by taking the most restrictive value across all installed payloads.
This happens silently. Both the Configuration Profile and Compliance Policy appear successfully deployed in the portal.

On policy design:

Choose one model and be consistent between Configuration Profile and Compliance Policy.
For allow-list model: keep Incoming Connections at Not configured in the Compliance Policy.
For block-all model: accept that no exceptions exist and design your management workflows around that constraint.
Community recommendation and practical guidance from practitioners is to leave firewall settings in the Compliance Policy at Not configured and manage firewall state exclusively through Configuration Profiles or the Settings Catalog, unless your organisation explicitly wants compliance-driven enforcement.

DDM, Intune and You

2026-03-31T00:00:00Z

Last updated: March 2026

If you've been managing Apple devices in Intune for any length of time, you've probably noticed new DDM-related settings appearing in the Settings Catalog over the past couple of years. Maybe you've configured managed software updates and wondered what was actually happening under the hood. Or perhaps you just got the memo that MDM-based software update commands are deprecated in Apple OS 26 and you need to figure out what that means for your organisation.

This post covers everything — how DDM works architecturally, what settings are available today, how to configure them in Intune, what works on BYOD versus supervised devices, and where Apple is heading with all of this. It's a long one, so use the headings to jump to what you need.

1. Why DDM matters right now

DDM has been in Apple's device management protocol since WWDC 2021, but for a long time it was easy to treat it as an "eventually" problem — something to pay attention to when your MDM vendor got around to supporting it. That window is now closed.

At WWDC 2025, Apple announced that MDM-based software update commands are deprecated in Apple OS 26. This means the legacy ScheduleOSUpdate and OSUpdateStatus MDM commands — the ones Intune has relied on to push iOS, iPadOS, and macOS updates — are going away on devices running iOS 26, iPadOS 26, and macOS Tahoe and later. If your organisation hasn't migrated software update management to DDM, you will lose the ability to enforce OS updates on those devices.

Microsoft responded quickly. Intune's August 2025 release added real-time DDM-based software update reporting, and the guidance from the Intune product team is unambiguous: migrate now, not later.

But software updates are just the start. Apple has explicitly stated that the focus of all future protocol development will be DDM. Legacy MDM profiles aren't disappearing overnight, but every new management capability Apple ships will land in DDM first — or exclusively. Understanding DDM is no longer optional for anyone managing Apple devices professionally.

2. How DDM works — the architecture

To understand DDM, it helps to first understand exactly what was wrong with the traditional MDM model — because DDM was designed specifically to address those limitations.

The old way: reactive MDM

Traditional MDM is a command-and-response protocol. The server sends a command (install this update, apply this profile, report your OS version), the device executes it and sends back an acknowledgment, and the server then decides what to do next. For the server to know the current state of a device, it has to ask. This creates a few real-world problems:

State is always potentially stale. Between polls, a user could uninstall an app, change a setting, or install a system update. The server doesn't know until the next check-in.
Scale is expensive. Managing a fleet of 10,000 devices means 10,000 devices checking in and being polled on a schedule. The server is doing a lot of work just to maintain a current picture.
Offline devices fall behind. If a device is offline when a command is sent, it misses it. Catch-up logic adds complexity on the server side.
Update enforcement is clunky. The server sends an update command, polls for status, polls again, sends a reminder — it's a multi-turn conversation just to install a software update.

The new way: declarative DDM

DDM flips this model. Instead of the server issuing commands and waiting for responses, the server declares the desired state — "this device should be running iOS 18.4, enforced by November 15th" — and sends that declaration to the device. The device then takes ownership of achieving and maintaining that state, entirely on its own.

The key shift is where the intelligence lives. In legacy MDM, the server drives everything. In DDM, the device drives its own compliance. The server just defines what "compliant" looks like.

This has several practical implications:

Devices self-heal. If a user somehow removes a managed configuration, the device detects the drift and re-applies it without waiting for the server to notice.
Status is proactive. Instead of the server asking "what's your OS version?", the device sends a status report the moment something changes. Intune knows in near-real-time.
Works offline. Declarations are stored on the device. If connectivity is lost, the device continues enforcing policy. When connectivity resumes, it reports status.
Server load drops significantly. No more polling. The server receives status updates only when something actually changes.

The diagram below shows these two flows side by side.

📊 Diagram: Legacy MDM reactive flow (left) vs DDM proactive flow (right), showing the reduction in round-trips and the addition of self-healing and proactive status reporting.

How DDM is enabled

DDM doesn't replace the MDM channel — it extends it. When an MDM server (like Intune) sends a DeclarativeManagement command to a device, the DDM channel is activated alongside the existing MDM channel. Both continue to function. Existing MDM profiles keep working. The device just gains a new, smarter management layer on top.

You enable DDM by sending a special MDM command to the device. In practice, Intune does this automatically for eligible devices — you don't flip a switch. Once enabled, the device begins exchanging declarations and status reports with the MDM server through the DDM channel, while legacy MDM commands continue to work normally on the same device.

3. The three pillars of DDM

Apple describes DDM as built on three foundational concepts: Declarations, Status Channel, and Extensibility. These aren't marketing categories — they map directly to how the protocol actually works.

📊 Diagram: Intune at the top sending declarations down and receiving status reports up, with the Device container showing Pillar 1 (Declarations), Pillar 2 (Status Channel), and Pillar 3 (Extensibility).

Declarations

Declarations are the core of DDM. They are JSON objects (not PLISTs, like old-style MDM profiles) that the server sends to the device to define desired state. There are four types, covered in detail in the next section.

The important thing to understand about declarations is that they are stateful and modular. A declaration isn't a one-shot command — it represents an ongoing desired state. The device stores it locally, evaluates it against the current system state, applies it if conditions are met, and keeps it applied. If a declaration is updated on the server, only the changed parts need to be synced.

Declarations are also composable. An Activation can reference multiple Configurations. A Configuration can reference an Asset (like a certificate). The same Asset can be used by multiple Configurations. This many-to-many model means you can update a certificate in one place and every configuration that uses it automatically picks up the change.

Status channel

The status channel is a new communication path where the device proactively pushes information to the server. The server subscribes to specific status items — OS version, app install status, battery health, account configuration state — and receives updates whenever those items change.

This replaces the polling model entirely for subscribed items. Intune knows a device has updated its OS not because it asked, but because the device told it, at the moment it happened.

Status items are also the foundation for predicates (covered below). A device can apply a declaration conditionally based on its own status — for example, only apply a configuration if the device's OS version meets a minimum requirement — without needing to consult the server.

Extensibility

Extensibility is baked into the DDM protocol design. New declaration types and status items can be added by Apple without breaking existing implementations. When a device receives a declaration type it doesn't understand, it reports it as unrecognised rather than failing silently or erroring out the whole channel.

This means Apple can ship new DDM capabilities in new OS releases — and Intune can start using those capabilities — without needing to redesign the underlying protocol. It's why Apple described DDM as "designed for the present and the future" when they announced it.

4. Declaration types explained

There are four types of declarations. Think of them as a layered system where each type plays a specific role.

📊 Diagram: The four declaration types (Activations → Configurations → Assets, plus Management) with their many-to-many relationships and example use cases for each.

Activations

Activations are the deployment logic layer. They define which configurations get applied to a device, and optionally under what conditions. An Activation references one or more Configurations and can include an optional predicate — a logical condition that must be true for the Activation to apply.

Predicates can reference status items. For example:

"Only apply this configuration if device.os.version is at least 17.0"
"Only apply this configuration if device.model.family is iPhone"
"Apply this stricter policy if the device is not at an approved network location"

This conditional logic runs entirely on the device, without a round-trip to the server. The device evaluates the predicate against its own status, applies or withholds the referenced configurations accordingly, and reports the outcome back via the status channel.

Configurations

Configurations are the settings layer — the equivalent of a payload in a traditional MDM profile, but delivered as a JSON object. This is where the actual management settings live: software update enforcement targets, passcode requirements, account configurations, disk management settings, and so on.

One key difference from MDM profiles: a Configuration is a standalone object that can be referenced by multiple Activations. You don't have to duplicate settings across multiple profiles. Define the configuration once, reference it wherever needed.

Assets

Assets are data objects that Configurations reference. Common examples:

X.509 certificates (for authentication, signing, or trust)
User-specific data sourced from an identity provider (username, email address)
Custom configuration files

The power of Assets is reusability and independent update. If a root certificate needs to be rotated, you update the Asset on the server. Every Configuration that references that Asset picks up the change automatically — without needing to update or re-push the Configurations themselves.

Management declarations

Management declarations serve two purposes. First, they can wrap legacy MDM configuration profiles as DDM objects — this is the migration path for existing profiles. The profile itself doesn't change; it's just delivered via the DDM channel instead of the traditional MDM channel. Second, they allow setting custom management properties — integer, string, or boolean values that can be referenced in Activation predicates as custom logic conditions.

The legacy profile wrapping capability is what makes the transition to DDM gradual rather than a cliff. You can start delivering existing profiles via DDM today without rewriting any settings.

5. What DDM settings exist today

This section covers the native DDM configuration declarations available as of early 2026. There's an important distinction to make upfront that isn't always clear in documentation:

Apple's DDM schema defines the full set of declarations that the protocol supports at the OS level. This is what Apple ships and what any MDM vendor could implement.

Intune's Settings Catalog is the subset of those declarations that Microsoft has actually built UI and backend support for. Not every Apple DDM declaration is available in Intune yet — some exist at the protocol level but aren't surfaced in the catalog. Microsoft adds new DDM settings with each monthly service release, so the gap narrows over time.

The interactive table below maps every current DDM declaration to its Intune availability status. Click any row to expand details and the Settings Catalog path.

Declaration

Intune status

Min OS

Platform

Status as of March 2026. Apple only = supported at the DDM protocol level but not yet a native DDM configuration in Intune. Click any row to expand. Microsoft adds new DDM settings each monthly service release.

✅ Available now in Intune's Settings Catalog

These are the declarations you can configure today under Declarative Device Management (DDM) in the Intune Settings Catalog:

Software Update (macOS 14 · iOS/iPadOS 17+)

softwareupdate.enforcement.specific — The most critical one right now. This is how you enforce a specific OS version by a hard deadline. The device handles everything: downloading, preparing, notifying the user, and installing. Configure it in Intune via Settings Catalog → DDM → Software Update.

Key behaviours:

If multiple enforcement declarations target different versions, the one with the earliest deadline for a newer-than-current version is processed first
If the target version matches or is older than what's installed, the device returns an error in the status report — it will not downgrade
Once a DDM update declaration is active, legacy MDM software update commands return errors on that device — you can't mix the two approaches
User notifications come from the OS itself (not Intune) — Apple owns that UX. The Notifications key lets you adjust the default behaviour, e.g. showing only a 1-hour warning instead of extended reminders

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.update.ios18",
  "Payload": {
    "TargetOSVersion": "18.4",
    "TargetLocalDateTime": "2025-11-15T22:00:00",
    "DetailsURL": "https://intranet.example.com/it/updates"
  }
}

Intune also supports a "Software Update Enforce Latest" mode (introduced in service release 2503) — instead of specifying a target version manually, you define a deferral period in days and an enforcement time, and Intune automatically targets the latest eligible release for each device model.

softwareupdate.settings — Controls update deferral windows, Rapid Security Response behaviour, and whether standard users can manually trigger updates. This is the DDM replacement for the old software update restrictions and is recommended over legacy MDM equivalents since August 2024. Configure it in Intune via Settings Catalog → DDM → Software Update Settings.

Passcode (macOS 14 · iOS/iPadOS 17+)

passcode.settings — The DDM-native passcode declaration. Covers minimum length, complexity requirements, maximum failed attempts, and auto-lock. This replaces the legacy passcode MDM payload and is available cross-platform. Configure via Settings Catalog → DDM → Passcode.

Safari Extension Settings (macOS 15 · iOS/iPadOS 18+)

safari.extensions.settings — Manage Safari extensions across managed devices: allow specific extensions, block others, or lock down the extension ecosystem entirely. Previously required workarounds via App Store VPP assignment or blunt restriction payloads. Configure via Settings Catalog → DDM → Safari Extension Settings.

Disk Management Settings (macOS 15+ only)

diskmanagement.settings — Controls whether devices can connect to external USB storage and network-attached storage. A long-requested capability for Mac admins that previously required third-party tools or kernel extension workarounds. Configure via Settings Catalog → DDM → Disk Management.

Math Settings (macOS 15 · iOS/iPadOS 18+)

math.settings — Configures the Math Notes and Calculator apps. Most relevant in education environments. Configure via Settings Catalog → DDM → Math Settings.

⏳ Rolling out / recently added

Audio Accessory Settings (macOS 26 · iOS/iPadOS 26+)

audioaccessory.settings — New in OS 26, announced in the Intune March 2026 release notes. Manages audio accessory connections and permissions. Rolling out to all customers through late March 2026.

🔵 Apple protocol only — not yet in Intune's Settings Catalog

These declarations are fully supported at the Apple DDM protocol level, but Microsoft has not yet built the backend to deliver them. It's worth being precise about what that means in practice, because the answer differs by declaration type.

A note on custom profiles and workarounds: For declarations that are DDM-native (background tasks, screen sharing), there is no functional Intune workaround today. These are JSON DDM declarations — the device expects them to arrive over the DDM channel with the DDM protocol. A custom configuration profile in Intune is a PLIST payload delivered over the legacy MDM channel. The device won't interpret a PLIST as a DDM declaration, and Intune doesn't have the backend to translate and route it correctly. The profile may deploy without an error, but the declaration won't be applied. This is a protocol gap, not a syntax problem — and it's a common source of confusion.

Background Tasks (macOS 15+ only)

services.background-tasks — Manages launchd agents and daemons in a tamper-resistant, managed location. Previously, Mac admins handled this with scripts, MDM-deployed packages, or tools like Outset. Apple now offers a first-class DDM declaration for it — but Intune can't deliver it yet. No functional workaround in Intune. If background task management via DDM is a requirement, you currently need a DDM-capable MDM (Jamf, Kandji, Mosyle, etc.). Until Intune adds support, the existing approach of deploying launch agents via pkg or script remains the practical path.

screensharing.connection — Manages screen sharing connection groups. In Apple's DDM schema but not deliverable through Intune. No functional workaround in Intune — same protocol gap as above.

Account Configurations (macOS 14 · iOS/iPadOS 17+)

This one is different. Apple has DDM declarations for managed accounts (CalDAV, CardDAV, Exchange ActiveSync, Google, LDAP, Mail, subscribed calendars) — but Intune doesn't need DDM to deliver account configurations, because it already supports them via legacy MDM profile templates (Exchange, Email, etc.) that have worked for years. The MDM channel handles these just fine. What you lose is DDM-quality benefits: proactive status reporting on account state, self-healing if the account config is removed, and the cleaner JSON structure. Practical path: continue using Intune's existing account configuration profile templates — they work. The gap is quality of management, not functionality.

App Management (iOS/iPadOS 17+)

app.managed — The DDM declaration for app lifecycle management. Apple's schema and status channel already support DDM-native app install reporting. In practice, Intune manages apps through its own established channel (VPP, managed apps, required/available assignments) — so this isn't a hard blocker the way background tasks is. But native DDM app management would bring better install status granularity and self-healing deployments. One to watch for future Intune releases.

Legacy profile declarations

com.apple.configuration.legacy — Available in Intune where supported. This wrapper type lets you deliver any existing MDM configuration profile through the DDM channel. The profile content (PLIST) is unchanged; DDM handles delivery and status reporting. This is the migration path for settings that don't have a native DDM equivalent yet — and it unlocks better status reporting for those profiles as a side benefit. Note: passcode profiles cannot be delivered this way; use the native DDM passcode declaration instead.

6. Platform and OS version support matrix

DDM support has expanded significantly since the initial iOS-only launch in 2021. The table below shows the minimum OS versions required for DDM by platform.

Feature	macOS	iOS/iPadOS	tvOS	watchOS	visionOS
DDM protocol (base)	13 Ventura	15	16	9	1.1
Software update enforcement	14 Sonoma	17	17	—	1.1
Software update settings (deferral)	14 Sonoma	17	—	—	—
Passcode settings	14 Sonoma	17	—	—	—
Account configurations	14 Sonoma	17	—	—	—
Disk management settings	15 Sequoia	—	—	—	—
Background tasks	15 Sequoia	—	—	—	—
Safari extension management	18	18	—	—	—
Battery health status item	14.4 (Apple Silicon)	17	—	—	—
Shared iPad support	14 Sonoma	17	—	—	—

Note: "DDM protocol (base)" refers to the ability to receive declarations and use the status channel. Individual declaration types have their own OS minimums — a device can support DDM but not support a specific newer declaration type if the OS is too old.

7. BYOD vs. Supervised — what actually works

This is probably the most nuanced section in the post, and the one that changes most frequently. The short summary: supervision still gates the most powerful capabilities, but DDM has meaningfully expanded what's available for user-enrolled and BYOD devices — particularly for software updates.

What supervision actually means in this context

A "supervised" device in Apple's model is a device enrolled via Automated Device Enrollment (ADE) through Apple Business Manager or Apple School Manager. Supervision is applied during initial setup and grants the MDM server a significantly broader set of management capabilities — including locking the MDM enrollment profile to the device, controlling activation lock, preventing the user from removing MDM, and restricting actions that are otherwise user-controlled.

BYOD in most enterprise contexts means one of two things: a personal device enrolled via the Company Portal app (Device Enrollment, with or without User Enrollment), or a device using App Protection Policies without full MDM enrollment at all.

The historical pattern

Apple has historically tightened supervision requirements over time — moving capabilities from "available to all enrolled devices" to "supervised only" as the capabilities became more sensitive. This trend led many admins to assume DDM would follow the same pattern, with the strongest DDM features requiring supervision.

What's actually available today

The situation as of early 2026:

Declaration / Capability	Supervised (ADE)	User Enrolled BYOD	Account-Driven Enrolment
DDM protocol (base)	✅	✅	✅
Software update enforcement (core keys)	✅	✅	✅
Software update settings (deferral)	✅	⚠️ Limited	⚠️ Limited
Passcode settings	✅	✅	✅
Account configurations	✅	✅	✅
Disk management settings (macOS)	✅	✅	✅
Background tasks (macOS)	✅	✅	✅
Safari extension management	✅	⚠️	⚠️
Legacy profile declarations	✅	✅ (profile restrictions apply)	✅
Status channel (all items)	✅	Subset	Subset

The software update story for BYOD

This is worth calling out specifically because it surprised a lot of people in the community. At WWDC 2024, Apple's presentation described DDM software update enforcement as supervised-only. The documentation at that time supported this reading.

As of mid-2025, the picture changed. The basic DDM software update keys — TargetOSVersion, TargetBuildVersion, TargetLocalDateTime, and OfferPrograms — are available for unsupervised devices enrolled via Device Enrollment or ADE without supervision. In practice, this means you can use DDM to push iOS updates to BYOD devices enrolled in Intune via the Company Portal.

The important caveat: the enforcement experience differs. On supervised devices, the OS enforces the deadline without user override beyond the countdown window. On unsupervised devices, users may still need to agree to terms and conditions before the update installs. This is an Apple-controlled behaviour, not something Intune can override.

If you're running BYOD iOS in your environment and haven't tried DDM update policies yet — this is worth testing. It's a significant capability improvement over the old MDM-based path for BYOD.

What BYOD still can't do

To be realistic about the limitations:

BYOD devices can't have MDM enrollment locked — users can remove management at any time
Activation lock bypass is supervised-only
Certain restriction payloads only apply under supervision (kiosk mode, single-app mode, restricting App Store access)
The full set of status items isn't available on user-enrolled devices — certain hardware and system properties are scoped to device-channel only

8. How to configure DDM in Intune

Intune surfaces DDM in a few different places depending on which declaration type you're configuring. Here's how to find and use each one.

Software updates via DDM

The primary entry point for DDM-based software update management in Intune is the Settings Catalog under device configuration policies.

For iOS/iPadOS:

Intune admin center → Devices → Configuration → Create → New Policy
Platform: iOS/iPadOS, Profile type: Settings catalog
Search for "Declarative Device Management" — you'll find the Software Update category
Configure Target OS Version, Target Local Date Time, and optionally Details URL for an information page users see during the update process

For macOS: The path is the same. The DDM software update settings appear in the Settings Catalog alongside the traditional Software Update payload settings — they are distinct items. Make sure you're configuring the DDM variants if you're on macOS 14+ devices.

📊 Diagram: End-to-end lifecycle from Intune sending a declaration through to deadline enforcement, with proactive status reports at each stage and key behavioural gotchas.

Key settings to know:

Target OS Version — the minimum OS version you want the device to reach. Use the full version string (e.g., 18.4 or 15.3.1).
Target Build Version — optional, but allows targeting a specific build including supplemental security responses. Get current build strings from https://gdmf.apple.com/v2/pmv (the Apple Software Lookup Service).
Target Local Date Time — the enforcement deadline in the device's local time zone. Note: DDM enforcement always uses device local time, not UTC or a server-defined time zone. Plan accordingly if you have users across multiple time zones.
Notifications — controls the user-facing notification behaviour leading up to the deadline.

Important: Once a DDM software update declaration is active on a device, the device will return errors for certain legacy MDM software update commands. Don't mix DDM and legacy MDM update policies targeting the same devices.

Restricting update visibility (deferral)

If you want to delay when an update becomes visible to users — useful for giving IT a testing window — configure a deferral restriction in the Settings Catalog separately from the enforcement declaration. This is the com.apple.configuration.softwareupdate.settings equivalent in Intune, and it works by setting a number of days after Apple releases an update before it appears in the device's Software Update UI.

Other DDM settings in the Settings Catalog

Most native DDM configurations are accessible via the Settings Catalog. When browsing the catalog, look for items tagged "Declarative Device Management" in the category column — this distinguishes them from equivalent legacy MDM payload settings.

For macOS disk management and background tasks (Sequoia and later), these appear under their respective categories in the catalog. Check the "Supported Platforms" note for each setting to confirm the minimum OS version before deploying.

Legacy profiles via DDM delivery

If you have existing configuration profiles and want to deliver them via the DDM channel (for better status reporting and self-healing), some MDM vendors including Intune support wrapping profiles as legacy profile declarations. In the Intune admin center, check profile delivery options under the configuration profile settings — the option to install via DDM is available for most legacy profiles (with the exception of passcode policies, which have a native DDM equivalent).

9. DDM and legacy profiles — coexistence and conflict

A question that comes up constantly: if I have existing MDM configuration profiles deployed, what happens when I also start deploying DDM declarations for the same settings? Do they conflict?

The coexistence model

DDM and legacy MDM profiles coexist on the same device. Apple designed the transition this way deliberately. You don't have to rip out all your existing profiles before adopting DDM. The DDM channel sits alongside the existing MDM channel; both are active and both can deliver settings to the device simultaneously.

Conflict resolution

When both a legacy MDM profile and a DDM declaration configure the same setting, the most restrictive value wins. This applies to both directions — it doesn't matter whether the MDM profile or the DDM declaration is stricter, the device enforces the stricter setting.

Example: if an MDM profile sets a software update deferral of 7 days and a DDM declaration sets 14 days, the device enforces 14 days. If both set passcode minimum length but to different values, the higher value applies.

There is one important exception: software update and app configurations deployed via DDM take precedence over equivalent MDM commands. This isn't about strictness — it's a protocol-level priority. Once a DDM software update declaration is active, the MDM software update commands are effectively ignored.

The migration path

Apple provides a formal migration path for legacy profiles using the com.apple.configuration.legacy declaration type. This wraps an existing MDM profile as a DDM object, allowing the MDM server to take ownership of the profile and deliver it via the DDM channel.

The advantage: you get DDM-quality status reporting (proactive, real-time) for profiles that don't yet have a native DDM equivalent. The profile itself doesn't change — it's the same PLIST payload — but it's now delivered and tracked through DDM infrastructure.

In practical terms for Intune: for the majority of existing configuration profiles, you can opt into DDM delivery without changing the settings themselves.

10. Troubleshooting DDM on-device

Debugging DDM configuration issues requires knowing where to look, because DDM declarations don't appear in the same places as traditional MDM profiles.

Finding declarations on macOS

On macOS Sequoia (15) and later, DDM-deployed settings are visible at:

System Settings → General → Device Management

Locate your organisation's MDM enrollment profile in the list and double-click it. Scroll to the bottom of the profile detail window — you'll see a "Device Declarations" section. This is where all active DDM declarations are listed with their current state.

If you're deploying a software update plan, it appears here. If you're deploying legacy profile declarations via DDM, they appear under a "Profiles" subsection within Device Declarations.

Checking software update state from the command line (macOS)

As of macOS Tahoe 26, there's no official CLI tool for reading DDM declaration state, but Apple writes software update declaration state to a readable plist:

/var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist

You can read this with PlistBuddy or defaults read:

defaults read /var/db/softwareupdate/SoftwareUpdateDDMStatePersistence.plist

This shows the applied target version, enforcement deadline, and current update status as the device sees it — useful for verifying that the correct declaration is in effect on a specific Mac.

Note: This is undocumented by Apple and could change in a future OS release. Use it for diagnostics, not as a production monitoring solution.

Finding declarations on iOS/iPadOS

On iOS/iPadOS 17 and later:

Settings → General → VPN & Device Management

Tap your MDM enrollment profile. Scroll down to see active declarations. This surfaces the same information as the macOS path — active configurations, their current state, and any errors.

Verifying DDM status in Intune

In the Intune admin center, DDM-enabled devices report update status through the standard device update reports. For DDM-managed software updates, you'll see granular per-device status including download progress and installation state without needing to wait for a scheduled check-in.

For other DDM declarations, check the device configuration profile status under Devices → [device] → Device configuration. DDM-delivered configurations report success, error, and pending states similar to traditional profiles.

Common issues

Declaration not applying

Check the predicate if one is configured — the condition may not be met on the device
Verify the device OS meets the minimum version for that declaration type
Check whether a conflicting MDM command is interfering (especially for software updates)

Software update not enforcing on deadline

Confirm the TargetLocalDateTime is in the device's local time zone, not UTC
Check if the device is on the target version or newer — DDM will not downgrade
User Terms and Conditions acceptance may be required on unsupervised devices

Legacy profile declaration not appearing

Not all legacy profiles can be delivered via DDM in Intune — passcode is a known exception
Confirm the device has the DDM channel active (requires at least one check-in after enrollment)

11. What's coming next

Apple's direction with DDM is clear: this is the management protocol for the next decade of Apple devices. Every new management capability Apple announces will be DDM-first or DDM-only.

A few areas worth watching:

App management via DDM The com.apple.configuration.app.managed declaration is in Apple's schema. App lifecycle management — installing, removing, and monitoring managed apps — transitioning to DDM would bring much better real-time install status and self-healing app deployments. Intune has already begun surfacing DDM app status items.

Deeper compliance integration The status channel is a natural fit for compliance evaluation. Rather than Intune polling devices for compliance state, devices could proactively push compliance-relevant status items the moment something changes — triggering Conditional Access decisions in near real-time. This is directionally where the platform is heading.

Expanded status items Battery health reporting is already in DDM (macOS 14.4+, iOS 17+). Expect more hardware health, security posture, and configuration state items to be added as status items over future OS releases.

Intune's DDM roadmap Microsoft has committed to DDM as the forward path for Apple management in Intune. Expect the Settings Catalog to gain more native DDM declaration types as Apple adds them, and continued retirement of legacy MDM command equivalents on the Intune side.

The practical advice for Intune admins today:

Migrate software updates to DDM now — the MDM path is deprecated on OS 26 devices
Start delivering existing profiles via DDM delivery where Intune supports it — you get better status reporting for free
Test predicates if you have heterogeneous fleets — the conditional logic capability is underused and genuinely powerful
Monitor Apple's device management schema releases after each WWDC — that's where new DDM capabilities show up first before MDM vendor implementations follow

Wrapping up

DDM isn't a replacement for everything you know about Apple device management — it's an evolution built on top of it. Your existing profiles still work. Your existing Intune policies still apply. The transition is designed to be gradual.

But the direction is unambiguous. Apple is putting their engineering investment into DDM, and the deprecation of MDM software updates on OS 26 is the first concrete forcing function for the enterprise. If you're managing Apple devices in Intune and haven't started thinking about DDM, now is the time.

Got questions or something to add? Hit me up on linkedin and I'll try to get back to you as soon as possible.

Meet Apple Business

2026-03-24T00:00:00Z

Apple Consolidates Its Business Portals Into One: Meet Apple Business

If you've been juggling Apple Business Manager, Apple Business Connect, and Apple Business Essentials, Apple just made your life simpler. On March 24, Apple announced Apple Business — a single unified platform that replaces all three portals. It launches on April 14, 2026, and it's free.

Three Portals, One Platform

For years, managing Apple devices in an enterprise or SMB environment meant navigating a fragmented set of portals:

Apple Business Manager (ABM) — the backbone for zero-touch deployment, Managed Apple Accounts, and app/book purchasing. Available globally.
Apple Business Connect — the newer brand and location management tool for controlling how your business appears across Maps, Mail, Wallet, and Siri.
Apple Business Essentials — Apple's MDM subscription service, launched in beta in late 2021 off the back of Apple's 2020 acquisition of Fleetsmith — a well-regarded Mac MDM startup known for its zero-touch deployment approach. It was Apple's first foray into owning the full MDM stack, bundling device management, iCloud storage, and AppleCare+ for Business. It never expanded beyond the US, and with Apple Business it's now being folded into the broader platform — free, and available globally.

Apple Business rolls all of this into one unified experience. When the platform goes live on April 14, all three portals will be retired. Existing ABM data and Business Connect location data will automatically migrate — no action required on your end.

What's New (Beyond the Consolidation)

The announcement isn't just a rebranding exercise. There are genuinely new capabilities worth paying attention to.

Built-In MDM with Blueprints

Apple Business includes native MDM — previously only available as a paid subscription through Essentials in the US. Now it's built in and free globally. The standout new feature here is Blueprints: preconfigured bundles of settings and apps that can be assigned to device groups, enabling consistent zero-touch deployment out of the box. Think of it as Apple's own take on configuration profiles and enrollment groups, built directly into the platform.

Managed Apple Accounts also get an upgrade — automated provisioning is now supported through identity providers including Microsoft Entra ID and Google Workspace, which is a meaningful improvement for organisations already invested in the Microsoft stack.

Mail, Calendar, and Directory

Apple Business now offers integrated email, calendar, and directory services with custom domain support. Businesses can bring an existing domain or purchase a new one through the platform. There's calendar delegation and a company directory with contact cards — essentially a lightweight Google Workspace or Microsoft 365 alternative for smaller businesses. Worth noting: these features require iOS 26, iPadOS 26, or macOS 26.

Expanded Globally

Perhaps the biggest headline for organisations outside the US: the full Apple Business platform — including MDM — is now available in 200+ countries and regions. Apple Business Essentials was never available outside the US, so this is a significant expansion. Feature availability does vary by region (the UK gets most features including Managed Apple Accounts, Get Apps, Get Books, and Tap to Pay on iPhone), but the core device management capabilities are broadly available.

Ads on Apple Maps (Coming Summer 2026)

For businesses that also manage customer-facing operations, Apple Business will introduce paid advertising in Apple Maps starting this summer in the US and Canada. Ads will appear at the top of search results and in a new "Suggested Places" experience. Apple maintains its privacy stance here — ad interactions are not tied to a user's Apple Account, and personal data stays on device.

What Happens to Your Existing Setup?

If you're currently using Apple Business Manager, your transition should be seamless — data migrates automatically. If you were paying for Apple Business Essentials, your subscription charges stop on April 14. The built-in MDM is now free.

The companion Apple Business app (for employees to install work apps, find colleagues, and request support) will require iOS 26 or macOS 26 when it ships.

Optional paid add-ons remain for US customers: additional iCloud storage starts at $0.99/user/month, and AppleCare+ for Business starts at $6.99/device/month.

The Bottom Line for Mac Admins

Apple Business is a meaningful step forward — particularly the global MDM expansion and Entra ID integration. For smaller organisations without a dedicated MDM solution, Apple now offers a compelling native option that didn't exist a year ago. For larger orgs already running Intune or Jamf, the interesting question is how Apple Business's built-in MDM positions itself as either a complement or a simpler alternative over time.

Keep an eye on April 14 for the full launch details and any migration documentation Apple publishes.

Sources: Apple Newsroom, Apple Support — Available features by region

Building a Zero-Config ESP Framework for macOS and Microsoft Intune

2026-03-10T00:00:00Z

If you've managed macOS devices with Microsoft Intune for any length of time, you've probably run into this scenario: a user completes ADE enrollment, hits the desktop, and immediately starts poking around before their required apps have finished installing. Defender isn't running yet. Company Portal is halfway through. Teams hasn't even started. And now you've got a support ticket.

Windows has a built-in Enrollment Status Page that blocks the desktop until device setup is complete. macOS doesn't. And this was also something that came up when I was having a session at Experts Live in Denmark last month. So I started to build something that's easy to set up.

The Problem With Existing Approaches

Most ESP-style solutions for macOS rely on the same pattern: a script deployed per-app via Intune that fires a SwiftDialog update when that specific app finishes installing, or drop information in a specific folder which need to be specified. It works, but it has some drawbacks.

You need a separate script for every tracked app. Install order is non-deterministic in Intune, so you need to handle race conditions. Native MDM apps — Microsoft 365, Defender, Edge — don't go through the Intune Management Extension at all, so they never trigger IME-based scripts. And maintaining the whole thing as your app catalogue grows becomes a headache.

I wanted something different: deploy one PKG, configure a list of apps, done. No per-app scripts. No race conditions. No maintenance overhead per app.

How It Works

The framework is built around two components that communicate through a shared JSON state file.

The LaunchDaemon runs as root from the moment the device enrolls. It polls for each tracked app every 10 seconds using mdfind — Spotlight's bundle ID index — which works for every install type including native MDM apps that never touch IntuneMDMDaemon.log. When all required apps are detected, it updates the state file and signals the UI to enable the Continue button.

The LaunchAgent runs in the user's session. It waits for the daemon to signal ready, launches SwiftDialog with a live-updating app list, and polls the state file every 3 seconds to pipe updates through SwiftDialog's command file interface. When the user clicks Continue, it archives the logs and tears everything down cleanly.

The key insight that makes this work — and that took some real digging to validate — is that native MDM-deployed apps like Microsoft 365, Defender, and Edge never appear in IntuneMDMDaemon.log. They go through mdmclient instead. Any solution that only watches the IME log will silently miss them. mdfind doesn't care how an app was installed. It just checks whether it's there.

Is daemons and agents overkill? Perhaps, but I like to think about the future where we can deploy agents and daemons during ESP, set install order of applications and Intune have an equivalent of PreStaging? What a dream... Therefore I think this is a way to go.

The Detection Strategy

Each tracked app gets three detection attempts in order:

Spotlight (mdfind kMDItemCFBundleIdentifier == 'com.microsoft.Word') — the primary method, works for all install types
Path check (-e /Applications/Microsoft Word.app) — fallback if the Spotlight index hasn't caught up yet during early enrollment
PKG receipt (pkgutil --pkg-info) — second fallback, same method Intune uses internally

This three-layer approach means apps get detected correctly whether they came in through the native MDM stack, the Intune Management Extension, or were already present on the device.

Let's configure!

Start by dropping by the GitHub and download the zip file. When unwrapped it should look like this:

ESP-SwiftDialog/
├── build.sh
├── esp-daemon.sh
├── esp-agent.sh
├── esp-util.sh
├── com.intune.esp.daemon.plist
├── com.intune.esp.agent.plist
├── postinstall
├── SwiftDialog.pkg      ← you provide this
├── logo.png             ← optional
└── banner.png           ← optional

We only need to touch two files - the esp-daemon.sh and esp-agent.sh.

Setting apps to track, Required vs Optional Apps

Let's set up what applications we want to track in our ESP, open up esp-daemon.sh and look at lines starting from 62. It should look like this:

Not every app should block the user from getting to their desktop. The framework supports a required flag per app:

declare -a TRACKED_APPS=(
    "Microsoft 365 Apps|com.microsoft.Word|/Applications/Microsoft Word.app|true"
    "Microsoft Teams|com.microsoft.teams2|/Applications/Microsoft Teams.app|true"
    "Slack|com.tinyspeck.slackmacgap|/Applications/Slack.app|false"
)

Required apps (true) hold the Continue button until installed. Optional apps (false) show up in the list with their real-time status but don't block the user. The daemon only enables the button when all required apps are confirmed present.

When you've set up the applications you want to track, there's nothing else to configure here - we can head over to the cosmetics how it will visually look.

Branding and Customisation

Everything visual is configured in a single block at the top of esp-agent.sh, starting at line 33:

readonly ORG_NAME="Contoso"
readonly LOGO_PATH="/Library/ESP/logo.png"
readonly LOGO_FALLBACK="SF=building.2,colour=#3b82f6"
readonly DIALOG_BANNER_IMAGE="/Library/ESP/banner.png"
readonly DIALOG_TITLE="Setting up your Mac"
readonly DIALOG_POSITION="centre"
readonly DIALOG_FULLSCREEN="false"
readonly BLUR_SCREEN="true"
readonly DIALOG_IGNORE_DND="true"
readonly DIALOG_LIST_FONTSIZE="small"
readonly DIALOG_WIDTH=740
readonly DIALOG_HEIGHT=500

Drop your logo (512×512px PNG) and banner (1800×300px, 6:1 ratio) in the repo root before building and they get bundled automatically. No need to add an actual path in the settings for them, just drop them in the folder and be happy. Don't forget to name them banner.png or logo.png.

Set DIALOG_FULLSCREEN="true" for a hard kiosk experience where the user can't interact with anything else, or BLUR_SCREEN="true" for a softer version that blurs the desktop behind the dialog.

One setting worth calling out: DIALOG_IGNORE_DND="true" should always be on in production. If a user has Focus mode active at first login, SwiftDialog won't appear without it.

When you have set the configuration you like and added your logo and/or banner and the structure look like the image below, it's time to build!

When testing locally on your device when configuring the cosmetics I advice not to use the Blur or Fullscreen experience as it might be quite hard to exit out of.

Lets build - What Gets Deployed

Everything ships in a single PKG built with macOS's built-in pkgbuild — no third party tools required.

Start up your terminal and trail to the folder where all the files are located. Type ./Build.sh to initiate the PKG-building. It will give you a complete log of what was build.

You should now have a folder named "build" in your project.

The payload contains:

esp-daemon.sh — the root-level monitor
esp-agent.sh — the user-level UI controller
SwiftDialog.pkg — bundled and installed by the postinstall script
logo.png / banner.png — optional org branding, auto-detected by the build script

The postinstall script installs SwiftDialog first, sets directory permissions correctly so the user-context agent can write logs, creates the log archive directory, and bootstraps the LaunchDaemon. The LaunchAgent loads automatically at first login — which on a real ADE enrollment is exactly when you want it.

Now let's head to Intune to deploy!

Intune Deployment

Stat out by going to Apps -> macOS -> Create -> macOS App (PKG) and click Select. This allow us to deploy applications that's not signed.

Click on "Select app package file and upload the ESP-Framework-1.0.pkg we created in our last step with out build script. Click OK and Next to proceed.

Select the name you would like to have, this is only for cosmetics in Intune for your eyes.

Detection rule: App bundle ID au.csiro.dialog, Ignore app version: Yes

Since macOS PKG detection in Intune only supports bundle IDs (no file path option like Windows), you need an actual .app bundle to detect against. SwiftDialog is the only app your PKG installs, so its bundle ID is the natural choice. Setting Ignore app version to Yes means you're not locked to a specific SwiftDialog release every time you update the PKG.

Assignment: Required, to a Device group you want to deploy to.

Save and create the application. You're now done! Yay!

What it looks like when running on a device:

The daemon waits up to 120 seconds for IntuneMdmDaemon to appear before proceeding anyway — on a real ADE enrollment the agent typically starts within 30–60 seconds of the user session. The 30-minute overall timeout means even slow deployments get handled gracefully, with the Continue button enabling automatically if the wait exceeds the limit.

Cleanup

When the user clicks Continue to Desktop the agent doesn't just close SwiftDialog and exit. It:

Archives the daemon log, agent log, and final state snapshot to /Library/Logs/ESP/ with a timestamp
Touches a .cleanup_requested marker file
The daemon (running as root) picks up the marker on its next poll, removes both plists, wipes /Library/ESP/, and unloads itself
The agent unloads itself last
Logs are stored in /Library/Logs/ESP

After a successful ESP run the only thing left on the device is the archived logs — useful for troubleshooting without cluttering the filesystem.

The Utility Script

Testing and maintenance are covered by esp-util.sh:

sudo bash esp-util.sh clean     # full teardown, ready for fresh install
sudo bash esp-util.sh unlock    # force-enable Continue button
sudo bash esp-util.sh status    # pretty-print current state
sudo bash esp-util.sh logs      # tail both logs live
sudo bash esp-util.sh restart   # bounce daemon and reload agent

The unlock command is particularly useful during testing — it bypasses the app detection and enables the button immediately so you can test the full flow without waiting for apps to install.

Get It

The full framework is available on GitHub. Download the zip-file, unwrap, drop in your SwiftDialog.pkg and optional branding assets, update TRACKED_APPS for your environment, and run ./build.sh. That's it.

ESP-SwiftDialog/
├── build.sh
├── esp-daemon.sh
├── esp-agent.sh
├── esp-util.sh
├── com.intune.esp.daemon.plist
├── com.intune.esp.agent.plist
├── postinstall
├── SwiftDialog.pkg      ← you provide this
├── logo.png             ← optional
└── banner.png           ← optional

If you deploy this in your environment I'd love to hear how it goes!

macOS Defender Check

2026-02-06T00:00:00Z

If you manage Microsoft Defender for Endpoint (MDE) on macOS devices, you know how critical it is to verify that security features are actually working as intended. Today, I'm sharing a new toolkit I've developed to help IT admins and security professionals validate MDE configurations on macOS.

What is macOS Defender Check?

macOS Defender Check is a comprehensive bash/shell script testing suite for Microsoft Defender for Endpoint on macOS.

Why I Built This

While managing MDE deployments across macOS fleets, I found myself repeatedly running manual tests to verify:

Is Tamper Protection actually preventing unauthorized changes?
Are web protection features blocking malicious URLs?
Is SmartScreen working correctly across different browsers?
Are my custom URL Indicators being enforced?

Instead of running these checks manually, I wanted an automated, comprehensive testing toolkit that works natively on macOS without requiring PowerShell or additional dependencies.

What It Tests

The toolkit includes two main scripts:

1. Tamper Protection Testing (`defendercheck-tp.sh`)

MDE installation and health verification
Real-Time Protection status
Tamper Protection configuration
Actual tampering prevention tests
System Extension approval status
MDM profile deployment

2. Web Protection Testing (`defendercheck-wp.sh`)

Microsoft Defender SmartScreen
Network Protection
Custom URL Indicators (CSV import)
Web Content Filtering (WCF)
Multi-browser testing (Chrome, Edge, Safari)

Quick Start

Download the files from my GitHub.

# Download and make executable
chmod +x defendercheck-tp.sh defendercheck-wp.sh

# Test Tamper Protection
sudo ./defendercheck-tp.sh

# Test Web Protection (all browsers)
sudo ./defendercheck-wp.sh

# Test specific browser only
sudo ./defendercheck-wp.sh -b edge

# Test with custom URL Indicators
sudo ./defendercheck-wp.sh -f your_urls.csv

# Test Web Content Filtering
sudo ./defendercheck-wp.sh -c AdultContent

Real-World Use Cases

Pre-Deployment Validation

Before rolling out MDE to your entire fleet, use these scripts to validate that all security features work correctly on your test devices.

Post-Deployment Verification

After deploying MDE, run the tests to confirm that Tamper Protection, Network Protection, and other features are properly enabled.

Compliance Auditing

Generate test reports to demonstrate that security controls are functioning as required by your security policies or compliance frameworks.

Troubleshooting

When users report that legitimate sites are being blocked (or malicious sites aren't being blocked), use the URL Indicators test to validate your allow/block lists.

Example: Testing URL Indicators

One of the most useful features is testing custom URL Indicators. Create a CSV file with your blocked/allowed URLs:

IndicatorValue
https://demo.smartscreen.msft.net/phishingdemo.html
https://github.com
https://malicious-site.example.com
https://microsoft.com

Then run:

sudo ./defendercheck-wp.sh -f urls.csv

The script will test each URL and generate a detailed CSV report showing which URLs were blocked/allowed, with timestamps and connection details.

Browser Support & Private Mode

A unique feature is automatic private/incognito mode for testing:

Chrome: Automatic incognito mode (--incognito)
Edge: Automatic InPrivate mode (--inprivate)
Safari: Opens in regular mode (private mode must be enabled manually)

This ensures test URLs don't pollute browser history and provides a clean testing environment.

What Makes It Different?

Compared to manual testing:

Automated and repeatable
Tests multiple browsers simultaneously
Generates detailed logs and CSV reports
Saves hours of manual validation work

Conclusion

Whether you're deploying MDE to a handful of Macs or managing thousands of macOS devices, having a reliable testing toolkit is essential. macOS Defender Check gives you the confidence that your security configurations are working as intended.

Give it a try and let me know what you think!

Automated iOS/macOS Compliance Policy

2026-01-14T00:00:00Z

Updated April 2026 — now with iOS/iPadOS support and two deployment options

The manual grind

If you're managing macOS devices in Intune, you've probably been in this situation: Apple releases macOS 26.3, and you need to update the osMinimumVersion field in your compliance policy to require 26.1 (or whatever version makes sense for your org). You open Intune, navigate to the compliance policy, update the minimum OS version, save, and you're done.

A week later, macOS 26.4 drops. Repeat. And if you're also managing iOS/iPadOS, you're doing this dance twice.

This gets old fast. And let's be honest — we forget to do it sometimes.

What this does

This solution automatically keeps the osMinimumVersion field in your Intune compliance policies current, for both macOS and iOS/iPadOS. It pulls the latest version data from the SOFA feed (the MacAdmins community standard — updated every 6 hours directly from Apple), calculates your target minimum based on your versioning strategy, and patches the policy via the Graph API if anything has changed.

It runs on Azure Automation, costs basically nothing (well within the free tier), and once it's set up you never touch it again.

Version strategies

Before getting into setup, it's worth understanding how the versioning logic works — this is the part that makes it actually useful rather than just "latest minus one."

Track major versions — stay N major versions behind the latest release.

MACOS_VERSIONS_BELOW = 2
# Latest: macOS 26 → requires macOS 24

Pin to major version — lock to a specific major and track minor releases within it. This is the one I'd recommend for most environments.

MACOS_PIN_TO_MAJOR_VERSION = 26
MACOS_VERSIONS_BELOW       = 2
# Latest 26.x is 26.7 → requires 26.5
# Ignores macOS 27.x entirely

Track minor versions — stay N minor versions behind within the same major.

MACOS_USE_MINOR_VERSIONS = True
MACOS_VERSIONS_BELOW     = 2
# Latest 26.7 → requires 26.5

The same strategies apply to iOS/iPadOS using the IOS_ prefix.

Pinning to a major version is particularly useful when you want to test the next major OS on a pilot group while keeping production on the current one. You set up two compliance policies, point this automation at each, and let it handle the rest.

Two deployment options

Since v4, you can choose how to deploy this:

Separate Runbooks

Two independent runbooks — one for macOS, one for iOS/iPadOS. Each has its own schedule, variables, and diagnostics. A failure in one platform doesn't affect the other. Good if your team manages platforms independently or needs them on different update schedules.

You end up with 4 runbooks total (2 main + 2 diagnostics), but they're fully isolated.

Unified Runbook

A single runbook handles both platforms in one execution. Each platform is independently enabled/disabled via ENABLE_MACOS and ENABLE_IOS variables, so you can start with just macOS and flip iOS on later without any runbook changes.

7 variables. 2 runbooks. One scheduled job. That's the whole thing (Managed Identity, both platforms enabled).

For most environments the Unified Runbook is the right choice — simpler to manage, fewer moving parts.

Authentication: Managed Identity

The whole solution runs on Managed Identity — no client secrets, no expiry dates, no calendar reminders. The Automation Account authenticates directly to Graph as itself.

You only need one Graph permission: DeviceManagementConfiguration.ReadWrite.All. It covers both macOS and iOS policies.

The setup is:

Enable System-Assigned Identity on your Automation Account (Identity → System assigned → On)
Copy the Object (principal) ID
Run this in Azure Cloud Shell:

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All"
 
$managedIdentityId = "PASTE-YOUR-OBJECT-ID-HERE"
$graphAppId        = "00000003-0000-0000-c000-000000000000"
 
$graphSP    = Get-MgServicePrincipal -Filter "appId eq '$graphAppId'"
$permission = $graphSP.AppRoles | Where-Object { $_.Value -eq "DeviceManagementConfiguration.ReadWrite.All" }
 
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $managedIdentityId `
    -PrincipalId        $managedIdentityId `
    -ResourceId         $graphSP.Id `
    -AppRoleId          $permission.Id

Done. That single permission covers both platforms.

If you prefer a Service Principal (useful for running the scripts locally or in CI/CD), that's supported too — see the standalone usage guide in the repo.

Diagnostics

Each deployment option includes a diagnostics runbook that runs a 5-step pre-flight check before you schedule anything: variables, authentication, Graph API permissions, policy access, and SOFA feed connectivity. Run these first. They'll catch misconfigured variables, wrong policy IDs, and auth issues before they become a silent failure at 2 AM.

What the output looks like

{
  "Success": true,
  "AuthMethod": "Managed Identity",
  "Duration": 6.8,
  "Results": {
    "macOS": {
      "Platform": "macOS",
      "PreviousVersion": "26.3.0",
      "NewVersion": "26.4.0",
      "Updated": true
    },
    "iOS": {
      "Platform": "iOS/iPadOS",
      "PreviousVersion": "18.3.0",
      "NewVersion": "18.3.2",
      "Updated": true
    }
  }
}

If nothing needs updating, it says so and exits cleanly. All job history is in Azure Automation.

Get it

Everything is on GitHub — scripts, setup guides, standalone usage docs, and a migration guide if you're coming from a Service Principal setup:

SSMacAdmin/Apple_ComplianceVersion_Updater

Set it up once, forget about it.

Have fun and good luck!

iOS26 New apps removal

2025-09-20T00:00:00Z

iOS26

I just want to show a quick and easy way to remove/restrict some native Applications for iOS. This will also apply to iPads since they also got the Phone application as default in iPadOS26. The new apps are Games and Preview

The settings

So we will need to create a new Policy with the Device Restriction template. Navigate to Devices -> iOS/iPadOS -> Configuration -> Create -> New Policy and then choose profile type Templates and select Device Restriction.

First we can set a name, give it a great one 😎 Next, we want to look for the section Restricted Apps. This will allow us to hide the app and it will also not allow other applications to open or interact with them. The app can't be installed from the App Store either if that's something you want to enforce.

So we need to find the Bundle ID's for the applications and they can be found on Apple's website here: https://support.apple.com/en-gb/guide/deployment/depece748c41/web

Then we can start to add the Bundle's in our configuration policy, it should look something like this:

When you're happy with the configuration. Save it and assign it to your organization!

Advanced uBlock Config

2025-07-20T00:00:00Z

Configure

With uBlock deployed to the orgainzation from the last post. We can also dive deeper in configuring uBlock with the help of some PowerShell and we will utilize remediation scripts in Intune to have a way check in with devices from time to time if changes has been made or if we want to update some configurations.

Got the chance to do this because a customer wanted to whitelist a couple of websites for Google analytics. It's not really that convenient to ask 3000+ employees to whitelist 10+ websites manually. The best solution for us was to create the remediation. These detect and remediate scripts also allow you to change filterlists. If you know your way around Powershell, it shouldn't be hard to add even more configurations that's available on uBlock's Wiki-page.

Detect

Let us configure the Detection part first.

First we need to set the location to the rigstry key that contain all information about the extension. Then we run a detection how we want the settings to be as our baseline. If it doesn't match, the remediation will kick in and set the parameters we would like.

We will mainly touch the part of the script that includes "trustedSiteDirectives". This is where the whitelisting of websites that's not going to be touched by uBlock will be put. This part need to be identical in both the Detect and Remediate part, since we want to find out if something has been changed from our baseline. This setting do not interfere with the manual whitelists users might have done on their own with the extension.

# Detect
[int32]$SkipRemediate = 0
[int32]$Remediate = 1

$Policy = "HKLM:\Software\Policies\Microsoft\Edge\3rdparty\Extensions\odfafepnkmbhccpbejgmiehpchacaeak\policy"

# Expected userSettings
$userSettings = @'
[
    ["contextMenuEnabled", "true"],
    ["showIconBadge", "true"]
]
'@

# Expected toOverwrite
$toOverwrite = @'
{
    "filterLists": [
        "user-filters", "ublock-filters", "ublock-badware", "ublock-privacy",
        "ublock-abuse", "ublock-unbreak", "easylist", "easyprivacy",
        "urlhaus-1", "adguard-annoyance", "ublock-annoyances", "plowe-0"
    ],
    "trustedSiteDirectives": [
        "about-scheme", "chrome-extension-scheme", "chrome-scheme",
        "edge-scheme", "moz-extension-scheme", "opera-scheme",
        "vivaldi-scheme", "wyciwyg-scheme", "website1.dk", "website2.no",
        "website3.se", "chrome-extension-scheme", "another.one.com",
        "moz-extension-scheme", "macos.rules.com"
    ]
}
'@

try {
    if (-Not (Test-Path -Path $Policy -ErrorAction SilentlyContinue)) {
        Write-Host "Remediate. uBlock whitelist missing."
        exit $Remediate
    }

    # Get registry values
    $policyValues = Get-ItemProperty -Path $Policy

    # Save for troubleshooting
    $policyValues | Out-File -FilePath $RemediateWhitelistOnDomains -Force

    # Check if userSettings matches
    $currentUserSettings = $policyValues.userSettings
    $currentToOverwrite = $policyValues.toOverwrite

    if ($currentUserSettings -ne $userSettings -or $currentToOverwrite -ne $toOverwrite) {
        Write-Host "Remediate. uBlock whitelist update required."
        exit $Remediate
    }

    Write-Host "Skip Remediate. uBlock whitelist match."
    exit $SkipRemediate

} catch {
    Write-Host $_.Exception.Message
    exit $Remediate
}

Remediate

The remediate part kicks in if we find anomalies from what we want our baseline to be in uBlock. The settings, as mentioned in the detection part, should be identical otherwise it will just loop itself to infinity and beyond.

# Remediate
[int32]$Success = 0
[int32]$Failure = 1

$Policy = "HKLM:\Software\Policies\Microsoft\Edge\3rdparty\Extensions\odfafepnkmbhccpbejgmiehpchacaeak\policy"

# userSettings
$userSettings = @{
    "Force" = $true
    "Path"  = $Policy
    "Type"  = "String"
    "Name"  = "userSettings"
    "Value" = @'
[
    ["contextMenuEnabled", "true"],
    ["showIconBadge", "true"]
]
'@
}

# toOverwrite
$toOverwrite = @{
    "Force" = $true
    "Path"  = $Policy
    "Type"  = "String"
    "Name"  = "toOverwrite"
    "Value" = @'
{
    "filterLists": [
        "user-filters", "ublock-filters", "ublock-badware", "ublock-privacy",
        "ublock-abuse", "ublock-unbreak", "easylist", "easyprivacy",
        "urlhaus-1", "adguard-annoyance", "ublock-annoyances", "plowe-0"
    ],
    "trustedSiteDirectives": [
        "about-scheme", "chrome-extension-scheme", "chrome-scheme",
        "edge-scheme", "moz-extension-scheme", "opera-scheme",
        "vivaldi-scheme", "wyciwyg-scheme", "website1.dk", "website2.no",
        "website3.se", "chrome-extension-scheme", "another.one.com",
        "moz-extension-scheme", "macos.rules.com"
    ]
}
'@
}

try {
    If (-Not (Test-Path -Path $Policy)) { New-Item -Force -Path $Policy }

    Get-Item -Path $Policy
    
    Set-ItemProperty @userSettings
    Set-ItemProperty @toOverwrite

    exit $Success

} catch {
    Write-Host $_.Exception.Message
    exit $Failure
}

Save the scripts as two seperate .ps1-files and upload the scripts as a remediation in your tenant. This can be deployed without interfering the users.

Signed, sealed and delivered uBlock configuration. Enjoy!

Adblock it!

2025-07-02T00:00:00Z

Adblock!

I want to hit on the big drum and clean up the browser for users as well as making the device safer. This will mainly focus on Windows on this, but can still be applied to macOS (will make a post about that later), since some of my recent customers have been mainly Windows oriented.

So, when people think of ad blockers, they usually picture someone trying to clean up their personal browsing experience. But in enterprise environments, ad blockers aren’t just about aesthetics — they’re a smart, strategic tool that improves security, productivity, and even compliance.

Some, but not all, reasons to deploy adblockers in an enterprise environmen;

Strengthening Enterprise Security

Cybersecurity threats are evolving, and not all of them come through phishing emails or dodgy downloads. Malvertising — malicious ads that spread malware — can compromise systems without a single click. By blocking ads and third-party scripts, ad blockers eliminate a common vector for these kinds of attacks, significantly reducing risk across the organization.

Boosting Employee Productivity

Let’s face it: ads are distracting. Whether it's a flashy banner or an auto-playing video, these interruptions pull attention away from work. By removing visual clutter and noise from web pages, ad blockers help employees stay focused. Plus, pages load faster.

Saving Bandwidth and Reducing IT Load

Ad content consumes more than just attention — it eats up bandwidth and system resources. In a large-scale environment with hundreds or thousands of devices, this adds up fast. With ad blockers in place, companies can see noticeable reductions in network traffic and hardware strain, translating into smoother performance and potentially lower IT costs.

Supporting Privacy and Regulatory Compliance

Tracking scripts embedded in ads can quietly collect data about users, often without their knowledge. For businesses subject to privacy regulations like GDPR or HIPAA, this presents a serious compliance issue. Ad blockers help curb unauthorized data sharing, contributing to better data hygiene and more control over what information leaves the network.

Delivering a Better Web Experience

Cleaner interfaces mean happier users. Employees benefit from faster, more readable websites without the distraction or frustration of intrusive advertising. For teams using web-based tools, this improvement in user experience can have a real impact on daily workflow.

Ok, so enough yapping, let's get to work.

Deploy Adblock with Intune

So I will be deploying uBlock Origin since I think it's the best one out the personally and that I've got experience with.

First I block all extensions and whitelist whenever it's necessary. This way you also get control over extensions that could possibly do harmful things or leak data. Go to Devices -> Windows -> Configuration -> Create -> New Policy and create a Settings Catalog profile. Search for "Extensions" and then choose "Microsoft Edge\Extensions", then select the options as pictured below to Block All extensions with a wildcard. If you already have a Edge configuration policy, you can add these settings to that configuration if you'd like.

Now we need to deploy uBlock Origin and make an exception for the extension in Edge. Create a new configuration profile and search for the same setting then add the following as pictured below.

Then we need to find the extension id for uBlock. You can find the Id's for extensions by browsing the Add-On "store", then look at the URL. In the end of the URL there will be a block with random letters, this is the ID you need to paste.

Exmple:

When deploying this setting, we will Whitelist the extension (since we block all extension with a wildcard) and automatically install the extension without the user needing to do anything.

In the next post, I will show you how to configure a list with exteptions and other modifiers with Powershell for the uBlock extension!

WWDC2025 MDM News!

2025-06-18T00:00:00Z

📱 All the New MDM Features from Apple’s WWDC25

Apple's WWDC25 unveiled a massive slate of upgrades to Mobile Device Management (MDM), showcasing a vision centered around declarative management, automation, and streamlined identity. Here's a partial breakdown of everything new for IT administrators with Apple environments.

🔧 1. Apple Business & School Manager Gets Smarter

Managed Apple Accounts: A new downloadable report lists personal Apple IDs linked to your domain, helping you steer users toward official managed accounts.
Block Personal Apple IDs: IT can now block personal IDs during Setup Assistant—even without MDM configuration.
ABM/ASM APIs: New APIs allow you to:
- Retrieve device inventories
- Reassign devices to different MDM servers
- Check enrollment statuses
Vision Pro Enrollment Support: Use Apple Configurator to enroll Vision Pro. Pairing via iPhone is now available.
Server Migration Tool: Migrate devices between MDM servers without wiping them. Set migration deadlines with fallback auto-migration if users don’t act.

🛠 2. Declarative Device Management (DDM)

Expanded Support: DDM now supports:
- Software updates for iOS, iPadOS, macOS, tvOS, visionOS
- Vision Pro
New Update Controls: Define update cadence, defer periods, and enforce deadlines—all handled on-device. Traditional commands are deprecated.

🌐 3. Safari & Network Management

Safari Configuration via DDM:
- Push bookmarks
- Set default homepages
Managed Network Relays: Now support FQDN-based traffic routing for more control over network traffic in enterprise setups.

🔁 4. Return to Service (Shared Devices)

Preserve Managed Apps: Erase iPads, iPhones, or Vision Pro for reuse without wiping managed apps.
Vision Pro Support: Control Center includes “Reset for Next User” to streamline shared use cases.

📦 5. Smarter App Management

Per‑App Deployment Controls:
- Pin versions
- Block cellular downloads
- Monitor install/update status
macOS App Distribution:
- Deploy apps/packages declaratively on macOS Tahoe
- Create self-service catalogs with the new ManagedAppDistribution framework

🛂 6. Identity & Access Enhancements

Setup Assistant SSO:
- During ADE on macOS Tahoe, you can configure Platform SSO and link to Managed Apple ID before login.
Tap‑to‑Login / Authenticated Guest Mode:
- Use iPhone, Apple Watch, or NFC badge to unlock shared Macs.
- All data is wiped after logout—ideal for labs and shift-based workers.

🔄 7. Migrating Devices to a New MDM Without Re-enrolling

For the first time, Apple lets you move devices between MDM servers without wiping or re-enrolling them. This is ideal during MDM vendor transitions or domain restructures and something I will personally test heavily when it is available. Will be very interesting to see how it work in practice.

🔑 Key Features:

No Factory Reset Required: Devices retain all data and apps.
Deadline Control: Set a grace period before automatic migration.
Cross‑platform Support: Works across iPhone, iPad, Mac, Apple TV, and Vision Pro.
ABM/ASM Interface: Reassignment done via Apple Business/School Manager.

🧭 Step-by-Step:

In ABM/ASM, navigate to Devices > Assign to Server
Select the new MDM server
Set the migration window
Devices will prompt users (or auto-migrate after the deadline)

🖼 Example Screenshots:

Above: Device selection screen in Apple Business Manager

Above: New server assignment view via Apple Configurator (visionOS example)

💡 Why It Matters

Benefit	How It Helps
Scalability	Declarative model means less MDM traffic and higher reliability
Efficiency	Faster deployment, shared device prep, and app control
Security	Tighter control over identity, accounts, and update timelines
User Experience	More seamless onboarding, shared use, and app management

🧠 TL;DR: Apple MDM in 2025

✅ Vision Pro fully supported
✅ Seamless device-to-server migration
✅ Declarative control over Safari, apps, and updates
✅ Identity-first onboarding and access
✅ Shared device workflows—reimagined

Intune and PSSO

2023-09-25T00:00:00Z

Intune and Platform Single Sign-On

Microsoft is taking a significant step forward by introducing Platform Single Sign-On (SSO) functionality to macOS devices in Intune.

In essence, Platform SSO marks a progression from the Extensible SSO payload. The noteworthy aspect is its availability at the login window, enabling users to seamlessly log in with their Identity Provider (IdP) credentials (such as Entra ID, Okta, etc.), subsequently gaining automatic access to business applications and websites. This synchronization between the local account and the IdP ensures a consistent login experience, requiring users to remember only one password.

Platform SSO offers two supported authentication methods:

Password Authentication: Users can authenticate using either a local or IdP password.
Secure Enclave: This method establishes SSO without impacting the local account password.

Prep

Microsoft Intune

Mac devices using ADE (Automated Device Enrollment) or Device Enrolment.
Create a Microsoft SSO configuration profile

Device

macOS Ventura 13.0 or later
Company Portal app (Currently only support version 5.2307.99, Preview release)

Configuration

First, we need to create a SSO Payload and we will be using the Settings Catalog for this.

Then we click on '+ Add Settings' and search for 'Extensible Single Sign On', and select the options as shown in the screenshot, and configure accordingly.

Save the configuration and deploy it to a device that got the correct version of the Company Portal.

When deployed, the profile should look like the screenshot:

The experience

From the perspective of both the device and the user, the experience is remarkably seamless. After setting up the Company Portal and logging in, a toast notification will prompt the user to utilize their IdP password for logging into the Mac.

Clicking on "Register" will redirect you to the device registration process with Microsoft Entra.

Upon completion, the final prompt will request your current local device password. Once entered and confirmed, the Platform SSO payload is fully implemented. From this point forward, the user can use their IdP credentials to log in to the device directly from the login screen.

To verify the successful registration of the device and the reception of tokens, simply type app-sso platform -s in the terminal to view all configurations.

Thoughts

This is a great step for the IdP sync for Intune and macOS devices. No more hassle with the SSO Extension and kerberos sync with On-Prem and use of VPN to enable the sync in the first place.

I'm really looking forward to seeing how PSSO evolves within Intune, and I've got my fingers crossed for seamless integration with the onboarding experience during an ADE enrollment.

And just peeking into the Settings Catalog for Platform SSO, it's pretty clear that there are some seriously cool features in the works.

Compliance Policies

2022-10-19T00:00:00Z

Think it through

I see so very often that there is only one compliance policy assigned in Intune (per OS). This grinds my gears, and I get in discussions a lot why this is not such a great practice when I get out to customers or other vendors that have set up the environment. Especially if the setup is as a BYOD environment without DEP.
In general, there is nothing wrong with one policy, but it’s quite an obstacle to work around and it get dirty very fast. The user experience is not quite there and the support team will be confused initially before looking up the device in Intune. And as of late with the great super patch for iOS which is to upgrade to iOS 15.7 or, if you use an older device (iPhone 5s, 6, 6 Plus and iPad Air, Mini 2/3 and iPod touch 6th Gen), iOS 12.5.6. You should not let anything below that through. Both for the sake of your organisation and to help the user with security.
As you can see it's a great mess.


Please dont :(

With iPhone 14 released and iOS 16 is out in the wild, we need to be able to segregate devices in a better way than to lock everything in one policy and assign it to a specific group. This will also benefit the user when they receive a notification why their device isn't compliant, since we don’t want to push generic “Contact your local IT for help” mail.
As a rule of thumb with everything related to Intune, SPLIT – THINGS - UP! We need to be flexible since there is a lot going on with versions of iOS and hardware models.

Before we begin, iOS 16 will require a hardware of the following models:

iPhone 14
iPhone 14 Plus
iPhone 14 Pro
iPhone 14 Pro Max
iPhone 13
iPhone 13 mini
iPhone 13 Pro
iPhone 13 Pro Max
iPhone 12
iPhone 12 mini
iPhone 12 Pro
iPhone 12 Pro Max
iPhone 11
iPhone 11 Pro
iPhone 11 Pro Max
iPhone XS
iPhone XS Max
iPhone XR
iPhone X
iPhone 8
iPhone 8 Plus
iPhone SE (2nd generation or later)

iPadOS 16 have the following:

iPad Pro (all models)
iPad Air (3rd generation and later)
iPad (5th generation and later)
iPad mini (5th generation and later)

Filter like a coffeemaker

We need to talk filters. This will be our little cuddle bear in this transformation. A such small and simple thing as a filter will improve the QoL quite a lot, and we can get a better understanding of the environment as well. And it work faster than dynamic groups, since we don't need to rely on AAD syncs. Filters are quite easy to set up and can be powerful (not just for Compliance policies, also for profiles and applications).
We need to create some filters. One that filters out all devices that’s above iPhone 8 and one filter for iPhone 7 and below. You can either write the syntax, or use the drop downs to create it.

Navigate to Devices - Filter and hit create. We need to create three different filters.

Legacy devices:

(device.model -contains "iPhone 5s") or (device.model -contains "iPhone 6")

Current devices:

(device.model -contains "iPhone SE") or (device.model -contains "iPhone 8") or (device.model -contains "iPhone X") or (device.model -contains "iPhone 11") or (device.model -contains "iPhone 12") or (device.model -contains "iPhone 13") or (device.model -contains "iPhone 14")

As we can see with this filter for example, if we choose to preview devices, we can see that it filters through all versions of the specific models we have applied in the syntax.

The forgotten iPhone 7:

(device.model -contains “iPhone 7”)

You should have the following filters created:

With the filters ready to go, let’s create policies.

Create the policies

We want to split the policies, so we need three (unfortunately, because Apple droppen iPhone 7 from iOS 16...) policies for version handling, and this is where you can freebase, either you can run the rest in one policy (depending on your needs), or you can split it up further. This is where you decide how informative you want to be towards the users.

A note for macOS specifically. Changing a policy touching passwords (complexity, etc) will trigger a password reset on targeted users macOS devices.

So head to Devices - iOS/iPad OS - Compliance Policies and click on Create Policy. Here we need to create three different policies to only handle version verification. Name them as you see fit, as long as you know which policy is which. In my example, I'm configuring the legacy compliance. And we only set minimum OS version in these policies.

Version Setttings

Select the actions you want to have for the policy

In the ‘Assignments’ tab, click on “Add all users”, and then we can select “Edit Filter”. This is where we let the filter do all the work for us.

Save the policy and let Intune do the work for us.

When all our policies are created, we should have the following stack:

Maintenance

The maintenance is low. When the next iOS or iPadOS is released, or a new version of the devices, simply bump up the values of the minimum OS version in the policy, and add/remove/move the models in the filters.

Conclusion

With the split of the policys, and addition to filters, we have more control over the versionhandling of the devices, and we can easily move the models around if necessary when new releases of either OS or models. We also make it easy for the user to understand what is the cause why they can't access company data because of the compliance policy. And if the user need to contact IT for assistance, they don't need to troubleshoot or look up the device, they have the answer in the email that's sent.

So all in all, we make everyone happy :)

WWDC, what's in it for MDM?

2022-07-23T00:00:00Z

Apple's WWDC 2022 gave us quite some tings to have in mind going through the year. Both with macOS 13 (Ventura) and iOS and iPadOS 16.
Let's have a look and see what delicious features they are providing, some might have the potential to be disruptive, some might not.

Let's start with hardware limitations for macOS Ventura

Sometimes when a new OS drops, some hardware adoptions might be needed due to security features it provides. Ventura will drop support for a quite hefty portion of hardware compared to other versions.

You will need a device no older than 2017. For MacBook Air and Mini, push it to 2018. Mac Pro users, you need the cheesegrater. Time to throw my own trascan in the... trashcan.

The list is the following:

MacBook 2017 and later

MacBook Pro 2017 and later

iMac 2017 and later

iMac Pro 2017

MacBook Air 2018 and later

Mac Mini 2018 and later

Mac Pro 2019 and later

Platform Single Sign-On

With this update, Apple will release Platform Single Sign-On. This allows the user to utilize, in example, their Azure AD or company account to unlock their devices. This will automatically keep the device's local account password in synd with the cloud password. Which will result in a more seamless sign-on experience.

The best part is, we can create config profiles for this! I really hope Microsoft will dish this one out quite fast for their Company Portal! They have given a timeline of this fall.


Apple Platform Single Sign-on

Gatekeeper

Gatekeeper will do a bit of a switcharoo in macOS Ventura, instead of checking the code at first run as it does today. It will include checking notarized apps if they have been altered/modified after the initial launch by unathorized processes. Apple has stated that some processes are allowed, but those processes has to be allowed by the developer.

This boils down to apps with autoupdaters, etc. Check your apps!

Altough, with these amazing news, the Gatekeeper check is overridable by users. I'll give it a try to see if these settings will be modifiable by admins.

Passkeys

A collaboration with Google, Microsoft, and other big players on the field, they have been working on a technology for web and remote services which they call 'Passkeys'. This is an aim to solve problems with passwords in general.

It's essentially a public-private key encryption. One key is stored (securely) on the device, and the other key in the cloud/server. Each passkey is generated for a single account. We don't need to remember the passwords, and the device will automatically let the user to choose the available passkey when trying to log on to a service. You can then use FaceID or TouchID to verify the ownership and login.

Passkeys will be stored in, for Apple users, the iCloud Keychain. So as long as you have access to a device with your iCloud account logged on, and synced with Keychain, you should be good to go.

With the rehaul of the 'System Preferences' application, it's now 'System Settings', and it's quite similar to the iOS/iPadOS format (or, it's a copy).

From a security standpoint, some features that's nice is the ability to now manage Login Items, LaunchAgens and LaunchDaemons from a single place in System Settings. Previously we had to use the Terminal, jump into hidden folders in Finder or use 3rd Party Softwares. This can give us a great benefit to actually pull data and see if some applications silently add persistence items without authorization from the user.

While these are good tools for administrators. For a user to go in here and turn of a bunch of launchers might not be that optimal since enterprises might use applications with dependencies that's required for critical systems. So let us hold out thumbs that we can lock this down a bit!

So all in all...

A lot of the new features are very welcomed and let us hope they give us even more tools to work with in an enterprise environment (looking at you Software Updates...)

KFM your OneDrive

2022-05-15T00:00:00Z

Microsoft has finally released the option to KFM your files to OneDrive on macOS (Late Feb/early March). This has been a function that has been available for a while on Windows.

We are currently able to sync folders Desktop, Documents and Pictures. Pictures is optional and has to be added in the profile.

Note that you can only have one sync of these folders activated, i.e; you can not have iCloud Drive sync and OneDrive sync enabled at the same time.

So, let's get started.
We need to following to start creating the config:

Correct version of OneDrive installed, the minimum version of OneDrive on macOS need to be 22.022.
Azure TenantID.

The important configurations we need to have in our mobileconfig is the following keys:
Automatically move known folders

<key>KFMSilentOptIn</key>
<string>(TenantID)</string>

If you want to prompt the users, use the following key.

<key>KFMOptInWithWizard</key>
<string>(TenantID)</string>

This leaves us with a OneDrive config initially with these settings:

OneDrive configuration part of mobileconfig

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>DisablePersonalSync</key>
			<false/>
			<key>FilesOnDemandEnabled</key>
			<true/>
			<key>OpenAtLogin</key>
			<true/>
			<key>KFMSilentOptIn</key>
			<string>(TenantID)</string>
			<key>KFMBlockOptOut</key>
			<true/>
			<key>PayloadDisplayName</key>
			<string>Microsoft OneDrive</string>
			<key>PayloadIdentifier</key>
		    <string>com.microsoft.OneDrive</string>
			<key>PayloadType</key>
			<string>com.microsoft.OneDrive</string>
			<key>PayloadUUID</key>
			<string>{UUID-GOES-HERE}</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>

Although this might look sufficient, we need to allow OneDrive for Full Disk access along with Desktop and Documents folder. We can add these TCC configurations in the same config file. If you want to, you can create a separate configuration in your MDM to grant OneDrive those permissions.

So we need to add the following:

Allow OneDrive disk access

<dict>
	<key>PayloadDisplayName</key>
		<string>Privacy Preferences Policy Control #1</string>
		<key>PayloadIdentifier</key>
		<string>com.apple.TCC.configuration-profile-policy</string>
		<key>PayloadType</key>
		<string>com.apple.TCC.configuration-profile-policy</string>
		<key>PayloadUUID</key>
		<string>{UUID-GOES-HERE}</string>
		<key>PayloadVersion</key>
		<integer>1</integer>
		<key>Services</key>
		<dict>
			<key>SystemPolicyAllFiles</key>
			<array>
				<dict>
					<key>Allowed</key>
					<true/>
					<key>CodeRequirement</key>
					<string>identifier "com.microsoft.OneDrive" 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</string>
					<key>Identifier</key>
					<string>com.microsoft.OneDrive</string>
					<key>IdentifierType</key>
					<string>bundleID</string>
					<key>StaticCode</key>
					<false/>
				</dict>
			</array>
			<key>SystemPolicyDesktopFolder</key>
			<array>
				<dict>
					<key>Allowed</key>
					<true/>
					<key>CodeRequirement</key>
					<string>identifier "com.microsoft.OneDrive" 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</string>
					<key>Identifier</key>
					<string>com.microsoft.OneDrive</string>
					<key>IdentifierType</key>
					<string>bundleID</string>
					<key>StaticCode</key>
					<false/>
				</dict>
			</array>
			<key>SystemPolicyDocumentsFolder</key>
			<array>
				<dict>
					<key>Allowed</key>
					<true/>
					<key>CodeRequirement</key>
					<string>identifier "com.microsoft.OneDrive" 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</string>
					<key>Identifier</key>
					<string>com.microsoft.OneDrive</string>
					<key>IdentifierType</key>
					<string>bundleID</string>
					<key>StaticCode</key>
					<false/>
				</dict>
			</array>
			<key>SystemPolicyDownloadsFolder</key>
			<array>
				<dict>
					<key>Allowed</key>
					<true/>
					<key>CodeRequirement</key>
					<string>identifier "com.microsoft.OneDrive" 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</string>
					<key>Identifier</key>
					<string>com.microsoft.OneDrive</string>
					<key>IdentifierType</key>
					<string>bundleID</string>
					<key>StaticCode</key>
					<false/>
				</dict>
			</array>
		</dict>

So all in all, our full mobileconfig will look like the following XML:

Full code for KMF OneDrive!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>DisablePersonalSync</key>
			<false/>
			<key>FilesOnDemandEnabled</key>
			<true/>
			<key>OpenAtLogin</key>
			<true/>
			<key>KFMSilentOptIn</key>
			<string>(TenantID)</string>
			<key>KFMBlockOptOut</key>
			<true/>
			<key>PayloadDisplayName</key>
			<string>Microsoft OneDrive</string>
			<key>PayloadIdentifier</key>
			<string>com.microsoft.OneDrive</string>
			<key>PayloadType</key>
			<string>com.microsoft.OneDrive</string>
			<key>PayloadUUID</key>
			<string>{YOUR-PAYLOADUUID-GOES-HERE}</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
		</dict>
		<dict>
			<key>PayloadDisplayName</key>
			<string>Privacy Preferences Policy Control #1</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.TCC.configuration-profile-policy</string>
			<key>PayloadType</key>
			<string>com.apple.TCC.configuration-profile-policy</string>
			<key>PayloadUUID</key>
			<string>{YOUR-PAYLOADUUID-GOES-HERE}</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>Services</key>
			<dict>
				<key>SystemPolicyAllFiles</key>
				<array>
					<dict>
						<key>Allowed</key>
						<true/>
						<key>CodeRequirement</key>
						<string>identifier "com.microsoft.OneDrive" 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</string>
						<key>Identifier</key>
						<string>com.microsoft.OneDrive</string>
						<key>IdentifierType</key>
						<string>bundleID</string>
						<key>StaticCode</key>
						<false/>
					</dict>
				</array>
				<key>SystemPolicyDesktopFolder</key>
				<array>
					<dict>
						<key>Allowed</key>
						<true/>
						<key>CodeRequirement</key>
						<string>identifier "com.microsoft.OneDrive" 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</string>
						<key>Identifier</key>
						<string>com.microsoft.OneDrive</string>
						<key>IdentifierType</key>
						<string>bundleID</string>
						<key>StaticCode</key>
						<false/>
					</dict>
				</array>
				<key>SystemPolicyDocumentsFolder</key>
				<array>
					<dict>
						<key>Allowed</key>
						<true/>
						<key>CodeRequirement</key>
						<string>identifier "com.microsoft.OneDrive" 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</string>
						<key>Identifier</key>
						<string>com.microsoft.OneDrive</string>
						<key>IdentifierType</key>
						<string>bundleID</string>
						<key>StaticCode</key>
						<false/>
					</dict>
				</array>
				<key>SystemPolicyDownloadsFolder</key>
				<array>
					<dict>
						<key>Allowed</key>
						<true/>
						<key>CodeRequirement</key>
						<string>identifier "com.microsoft.OneDrive" 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</string>
						<key>Identifier</key>
						<string>com.microsoft.OneDrive</string>
						<key>IdentifierType</key>
						<string>bundleID</string>
						<key>StaticCode</key>
						<false/>
					</dict>
				</array>
			</dict>
		</dict>
	</array>
	<key>PayloadDescription</key>
	<string>OneDrive</string>
	<key>PayloadDisplayName</key>
	<string>OneDrive</string>
	<key>PayloadIdentifier</key>
	<string>com.microsoft.OneDrive</string>
	<key>PayloadOrganization</key>
	<string>{YOUR-ORGANIZATION-GOES-HERE}</string>
	<key>PayloadScope</key>
	<string>System</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>{YOUR-PAYLOAD-GOES-HERE}</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
	<key>TargetDeviceType</key>
	<integer>5</integer>
</dict>
</plist>