There are several cheap MDM solutions for Apple devices that I would rather pay for than be dependent on this. (We've used SimpleMDM and love them.)
Like really Apple, that's your device "locking"? I could test activate my work Mac with my personal Apple ID while doing this, no alarm bells, nothing, effectively "It's your laptop now".
Fortunately around the same time, JamF ended the practice of the mandatory Jamf JumpStart (£5K fee), which finally made Jamf a feasible option for the company I was in at the time.
In the end we just made do with intune. It's a lot less capable for Mac but these days you can get by with it.
You just have to secure it properly. Have limits to how many one admin can wipe etc. But trust me every company with managed IT assets has this capability. Often even in BOYD scenarios! Stryker just failed to secure access to it properly and to set sensible limits.
However, the feature isn't very effective in the field. It's very unlikely for an attacker to be smart enough to bypass the password on a stolen Mac which is needed to connect it to WiFi, yet at the same time be dumb enough to connect it to the unfiltered internet so it can receive the wipe command. The overlap between these sets of people is almost zero. We do fire a wipe at every stolen computer but I doubt it ever actually happens. If it ever happens it'll be a total end user fail (like writing the password on a post-it with the laptop)
Either you will lose it to a common thief who won't be able to breach the login (99% of cases), or to a really targeted adversary who has cellebrite or something similar and won't connect it to the internet ever again. This is still the most risky scenario because if someone like that steals it, there's bound to be something really valuable on it.
In practice this is something more suited to mobile devices.
In a small shop that might work but not in an enterprise with ISO norms and security certifications to meet.
It's an absolute failure of the MDM server administrator for allowing such things, not on Apple.
The point is to make sure there’s not a mess on the other end when you enforce SSO for MAIDs.
Apple’s documentation for ABM and ABE is atrocious, but they do manage to document a bunch of footguns, just poorly and in seemingly bizarre places.
For example, ABE doesn’t support MDM migration (either as source or destination), despite the fact that the feature launched with macOS/iOS/iPadOS 26 and is supported by other MDM solutions.
And you cannot push custom config profiles with ABE which declare a non-Apple preference domain. Utter nonsense.
If you’re using the full ABM-with-ADE and MDM stack, it’s expected that you push apps to employees.
You can also use Munki to make apps available to users. You can just push only Munki via MDM if you want, and let it manage app installs and self service installs for you. There are caveats.
I had the same thing happen but with Microsoft. A friend and I had started a small consulting business and were using Google Workspace, but I needed a Microsoft account to interact with a client. I made one with my business email. None of us knew any better, but I couldn’t connect with our client’s Microsoft setup because it was a personal account. So I went to set up a business account. It was a whole fiasco and the only way I could really fix it was create an alias and use that for Microsoft.
So give all the employees an email alias they can use to create a new Apple ID for this purpose?
This should not be a surprise. Greenfield services have not existed long enough to resolve edge cases that inevitably arise while integrating existing operating models already in use.
Not really sure why you made that point only to wave it away later saying it's always been broken regardless
Employee does not trust the company having access to everything else in their personal iCloud account - photos, mails, messages, calendar, reminders, etc.
Employee registers a new Apple ID with company email, as it would be only used for downloading one single app.