The Problem

A small business running Microsoft 365 with no existing Intune footprint wanted phishing-resistant, hardware-bound MFA their Macs: the same Windows Hello for Business-equivalent experience, but for macOS. Apple’s answer is Platform SSO (PSSO) with a Secure Enclave-backed key, and Microsoft’s Entra ID plugin supports it. The problem: virtually every piece of public documentation for this assumes Intune. This organization didn’t have an Intune license and didn’t want to buy one just to push a single configuration profile.

Apple shipped a free, consolidated MDM this year, Apple Business, that includes a custom configuration profile upload feature. The question I had was whether it could carry the PSSO payload at all. It can, but getting there took several genuinely wrong turns worth documenting, because most of the write-ups on this online assume Intune’s settings-catalog UI is doing translation work for you that you don’t get when hand-authoring the raw profile.

Why Not Just Use Intune

Quick licensing note for anyone doing this math: if you’re already paying for standalone Entra ID P1 for Conditional Access, swapping the affected users to EMS E3 (which bundles Entra ID P1 + Intune Plan 1 together) is usually cheaper than adding Intune Plan 1 as a separate line item on top of what you already pay for P1. But if you’re testing on a handful of devices or a small org with no other Intune use case, standing up an entire Intune tenant just for this one profile is disproportionate at best. Apple Business’s built-in device management is free and does the job in a more user-friendly way for small business owners.

Setting Up Apple Business Manager (ABM)

At a high level:

Go to https://business.apple.com and create an account. This requires proof-of-ownership documentation and takes several days for Apple to approve.
Add your devices (see the addd2abm note below under Failure Mode 2).
Add a macOS Package to deploy the Intune Company Portal app.

PlatformSSO phish-resistant Secure Enclave requires a mac with TouchID, otherwise this defeats the purpose.

Get the package

Resolve Microsoft’s fwlink redirect to find the actual .pkg URL:

curl -sIL "https://go.microsoft.com/fwlink/?linkid=853070" | grep -i location | tail -1

As of this writing this resolves to: https://res.public.onecdn.static.microsoft/mro1cdnstorage/C1297A47-86C4-4C1F-97FA-950631F94777/MacAutoupdate/CompanyPortal-Installer.pkg

Paste that into the macOS Package URL field under Devices → Built-In Management → macOS Packages.

Get the hash

shasum -a 256 CompanyPortal-Installer.pkg

This produces something like d5f25d41e8812fe715ea394196dcda02760bed38dec75950aa26132ab6f3bf93, paste that into SHA-256 Hash.

Fill in the remaining fields

Bundle ID: com.microsoft.CompanyPortalMac
Version Number: make one up (e.g. 1.0) or use the actual package version (I used 5.2606.0).
Description: whatever helps future-you, e.g. “Microsoft App for Platform SSO”
Icon: extract it from the package payload if you’d like: Expand the pkg fully (plain --expand leaves the payload compressed and unreadable):

pkgutil --expand-full CompanyPortal-Installer.pkg ./cp_expanded

The app icon lives at: ./cp_expanded/CompanyPortal-Component.pkg/Payload/Applications/Company Portal.app/Contents/Resources/AppIcon.icns

Or easily just move this to your desktop with:

mv "./cp_expanded/CompanyPortal-Component.pkg/Payload/Applications/Company Portal.app/Contents/Resources/AppIcon.icns" ~/Desktop

Add System Extension

Company Portal ships a Platform SSO extension that macOS will otherwise prompt users to approve manually on install. Pre-approve it here so enrollment doesn’t stall on a local admin prompt:

Team ID: UBF8T346G9 (Microsoft Corporation’s Apple Developer Team ID, stable across their signed apps)
Extension Bundle ID: com.microsoft.CompanyPortalMac.ssoextension

Click Add System Extension, enter those two values, and save.

Company Portal installs LaunchAgents/LaunchDaemons that run at login (the SSO helper and the Intune management daemon); without pre-approving these, users get a “background items were added” notification and can disable them, breaking enrollment.

Add “App Bundle ID” with com.microsoft.CompanyPortalMac

Create the Platform SSO Payload

com.apple.extensiblesso is Apple’s own MDM payload type: it isn’t Microsoft- or Intune-specific. Any MDM implementing Apple’s device management protocol can deliver it. What differs is how much of the schema each vendor’s UI exposes and validates for you.

Here’s the config that actually works, delivered as a raw .mobileconfig through Apple Business’s custom configuration upload (Devices → Configurations → Custom). Save this (copy and paste it into a new .mobileconfig file):

<?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>PayloadType</key>
            <string>com.apple.extensiblesso</string>
            <key>PayloadIdentifier</key>
            <string>com.example.platformsso.59C07813-CD65-41A0-A417-B1B5F1ED9086</string>
            <key>PayloadUUID</key>
            <string>BB52C32A-C0EE-4D17-85DF-3D0D6E528748</string>
            <key>PayloadDisplayName</key>
            <string>Platform SSO</string>
            <key>PayloadVersion</key>
            <integer>1</integer>
            <key>ExtensionIdentifier</key>
            <string>com.microsoft.CompanyPortalMac.ssoextension</string>
            <key>TeamIdentifier</key>
            <string>UBF8T346G9</string>
            <key>Type</key>
            <string>Redirect</string>
            <key>URLs</key>
            <array>
                <string>https://login.microsoftonline.com</string>
                <string>https://login.microsoft.com</string>
                <string>https://sts.windows.net</string>
            </array>
            <key>AuthenticationMethod</key>
            <string>UserSecureEnclaveKey</string>
            <key>RegistrationToken</key>
            <string>{{DEVICEREGISTRATION}}</string>
            <key>ScreenLockedBehavior</key>
            <string>DoNotHandle</string>
            <key>PlatformSSO</key>
            <dict>
                <key>AuthenticationMethod</key>
                <string>UserSecureEnclaveKey</string>
                <key>UseSharedDeviceKeys</key>
                <true/>
                <key>enable_se_key_biometric_policy</key>
                <true/>
                <key>TokenToUserMapping</key>
                <dict>
                    <key>AccountName</key>
                    <string>com.apple.PlatformSSO.AccountShortName</string>
                    <key>FullName</key>
                    <string>name</string>
                </dict>
            </dict>
        </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Platform SSO</string>
    <key>PayloadIdentifier</key>
    <string>com.example.platformsso</string>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>D4E91EAB-D340-4C4A-911F-71DEE83FE30F</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
</dict>
</plist>

UBF8T346G9 is Microsoft’s own Apple Developer Team Identifier; it’s the same value for every organization deploying this extension, not something specific to your tenant. Everything under com.example should be swapped for your own reverse-DNS namespace, and the two UUIDs should be freshly generated (uuidgen from macOS Terminal) rather than reused.

Prerequisites Before Touching the Profile

Passkey/FIDO2 authentication method enabled in your Entra ID Authentication Methods policy: Platform Credential as a passkey option only appears if this is on.
The Mac actually enrolled in your MDM. Sounds obvious; wasn’t. See below.

Applying this in Apple Business Manager

Save the file contents as a .mobileconfig file.
Go to Devices → Built-In Management → Configurations → New → Custom Configuration, selecting this file and giving it a name (e.g. Platform SSO).

Now is also a good time to review other Apple Configuration Policies you may want to assign to your devices, such as Screen Lock, FileVault, pre-loading your business’ WiFi Network, and ensuring automatic updating is turned on.

Tying it all together

Devices → Blueprints → New → Custom Blueprint. Give it a name (Employee Standard, or something).
Click Add Configurations and select the Platform SSO (and any other configurations you added).
Click Add Apps and add the Company Portal app you configured earlier.
Click Add Devices and select the enrolled devices to apply this to. (Or use All Users)

Upon saving this, it should take several minutes before Company Portal prompts you to login with your Microsoft credentials and save a new passkey to your device.

At this point, you now have phish-resistant, biometrics-based TouchID that can authenticate your user to Microsoft services.

For Mobile, the Microsoft Authenticator app can provide a phish-resistant FaceID-based method that’s equivalently secure.

Learning from Failures

Failure 1: The Device Wasn’t Actually Enrolled

The single biggest time sink wasn’t the profile at all; it was assuming a Mac was MDM-enrolled because it showed some device management state, when in fact it had only been claimed by Apple Configurator without ever being assigned to actual management. sudo profiles renew -type enrollment returned MDMDeviceEnrollment:103, No Device Enrollment configuration was found for this computer, which is a precise, useful error if you know to look for it: it means there’s no Automated Device Enrollment record for that serial number at all, full stop, regardless of anything in your configuration profile.

If you hit this: check the device’s entry in Apple Business directly. “Devices Added by Apple Configurator” as the source is not the same as being assigned to a management authority; there’s a separate Assign Device Management action required.

A second-order version of the same problem: a device can be assigned to management and still fail with a generic “doesn’t support the expected services” error at Managed Apple Account sign-in if the signing-in account has no Blueprint (device configuration group) assigned; role permissions and device-service eligibility are separate checks, and having an Organization Administrator role doesn’t imply the latter.

Failure 2: Adding a Mac That Wasn’t Purchase-Linked

Apple Business’s device roster is normally populated automatically by purchase records from a participating reseller. A Mac bought outside that channel (retail, secondhand, personal hardware pressed into service) has no path into that roster without either a reseller backload (only possible if the original purchase channel supports it) or erasing the machine and running Setup Assistant fresh with Apple Configurator physically present.

There is a no-erase workaround (add2abm, a community tool that temporarily hides local account state to make macOS believe it’s unconfigured, links the device during that window, then restores the account records) but it comes with a real caveat worth taking seriously: it modifies local Setup Assistant/account state directly, and in practice it silently cleared Touch ID enrollment on the device it was run against. Biometric authentication continued failing intermittently for the rest of the session in ways that looked like a Platform SSO keychain problem but were actually just Touch ID needing to be re-enrolled from scratch. If you use this route, check Touch ID status as a standard post-step, not an afterthought: it’s not in Apple’s official on-rails enrollment method, so your mileage may vary, and this’ll save you chasing phantom PSSO bugs that are actually a side effect of the enrollment workaround itself.

Failure 3: The Intune-Specific Macro That Doesn’t Resolve Elsewhere

Early versions of this profile validated and deployed fine with RegistrationToken set to the literal string {{DEVICEREGISTRATION}} and that placeholder is not an error, it’s a real value the Microsoft SSO extension itself recognizes and uses to trigger its own live registration handshake. It is not something Intune substitutes server-side before delivery, despite looking exactly like the kind of macro syntax that would be. Don’t remove it thinking it’s Intune-only cruft, because it isn’t, and removing it doesn’t fix anything if something else is actually broken.

Failure 4: The Wrong Key Name for Touch-ID-Only Enforcement

By default, Secure Enclave key access sometimes falls back to a local account password prompt instead of Touch ID for certain operations, annoying but not a security regression, since it’s your local macOS password, not your Entra password, and not phishable remotely. That said, users often reuse the same password across accounts, so it’s worth understanding the security risk this presents. Microsoft documents a setting to force Touch ID with no password fallback whenever the key is accessed. The friendly Intune settings-catalog name for this is UserSecureEnclaveKeyBiometricPolicy; that is not the literal key name the raw profile expects. The actual key, per Microsoft’s own documentation, is enable_se_key_biometric_policy, nested inside the PlatformSSO dictionary. Using the PascalCase guess is what produced repeated “Invalid configuration profile, some required keys are missing or have an invalid value” errors from Apple Business’s validator, with no more specific detail than that.

Failure 5: An Incomplete GUI Export from iMazing

iMazing Profile Editor is commonly recommended for building this payload without hand-authoring XML. Worth knowing: depending on which export action you use, it can produce just the inner payload settings dictionary rather than a complete, deployable profile: no PayloadContent array, no outer wrapper keys. That partial file will fail with the identical generic “invalid” error, and it’s easy to mistake that failure for a content problem rather than a completeness problem. If you go this route, confirm the exported file has both an outer <dict> with top-level Payload* keys and the inner payload dict wrapped in a PayloadContent array before uploading, not just the settings section.

Two Things That Turned Out Not to Be Configurable at All

Forcing the “Company Portal” AutoFill/passkey-provider toggle on via profile. This is the manual step where a user has to go into Settings → General → AutoFill & Passwords and flip Company Portal on as a credential source. There’s no MDM-exposed managed preference key for enabling a specific third-party credential provider extension. Apple deliberately keeps this a user-consent action, for the same reason a rogue MDM shouldn’t be able to silently register itself as a system-wide password/passkey source. Restriction payload keys (allowPasswordAutoFill, safariAllowAutoFill) control whether AutoFill functions at all, not which provider is enabled within it. Budget for this as a one-time manual step in your rollout communication, not something you can automate away.

Merging the PSSO payload with a Restrictions payload in one file. Technically supported by Apple’s schema (multiple payload types can live in a single PayloadContent array), but in practice, combining them in one upload triggered validation failures that neither payload produced independently. Deploy them as two separate custom configurations targeting the same device group instead of one merged file. ABM’s settings I documented above account for this another way.

Verifying It Actually Worked

app-sso platform -s

Look for registrationCompleted: true, a loginType of POLoginTypeUserSecureEnclaveKey, and a valid, unexpired SSO token in the output. That confirms device-bound registration succeeded, independent of what any web UI shows; the self-service “Security info” consumer page in Entra ID doesn’t reliably surface a device-bound macOS credential the same way the admin-side Authentication Methods report does, so don’t treat its absence there as a failure signal.

To confirm the credential is genuinely phishing-resistant rather than a synced passkey riding along in the same account, pull the org’s registration report and check MethodsRegistered for macOsSecureEnclaveKey specifically, not just any passkey-shaped entry:

Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "UserPrincipalName eq '[email protected]'" |
    Select-Object -ExpandProperty MethodsRegistered

Summary

Apple Business can carry the Platform SSO payload for a small deployment without Intune, but the tooling around it is genuinely unproven compared to Jamf, Kandji, or Mosyle, which have all published working configs for this. Most of the failures along the way weren’t about whether the concept works (it does); they were about the gap between what Intune’s UI quietly handles for you (correct key casing, complete wrapper structure, validated nesting) and what you have to get exactly right by hand when going through a lighter-weight MDM. If you’re testing this on a handful of devices for a small org, budget real time for exactly this class of error, not the PSSO concept itself.

The Problem#

Why Not Just Use Intune#

Setting Up Apple Business Manager (ABM)#

Get the package#

Get the hash#

Fill in the remaining fields#

Add System Extension#

Login and Background Item Management#

Create the Platform SSO Payload#

Prerequisites Before Touching the Profile#

Applying this in Apple Business Manager#

Tying it all together#

Learning from Failures#

Failure 1: The Device Wasn’t Actually Enrolled#

Failure 2: Adding a Mac That Wasn’t Purchase-Linked#

Failure 3: The Intune-Specific Macro That Doesn’t Resolve Elsewhere#

Failure 4: The Wrong Key Name for Touch-ID-Only Enforcement#

Failure 5: An Incomplete GUI Export from iMazing#

Two Things That Turned Out Not to Be Configurable at All#

Verifying It Actually Worked#

Summary#