Apple needs to fix admin authentication in ABM

What are the implications? What this means in practice is that when admins engage with the authentication process, they need to do so using non-federated Apple Account sign-in with Apple’s two‑factor authentication (typically via a trusted device or trusted phone number using SMS/voice). That’s weird; it means the key accounts that manage protection for sometimes thousands of devices are still only protected by a six-digit SMS code sent to a specified phone number. We know that SMS authentication is risky, with three well-known attack paths: SIM swapping, where an assailant contacts your cellular company posing as you and convinces them to transfer your phone number to a SIM in their control. Once that takes place, all your SMS codes go to them. Phishing, such as a fake login page that acts normally but intercepts your SMS code once you enter it, capturing and immediately using it to attack your actual account. Interception, in which sophisticated, usually nation-state-adjacent attackers exploit the known vulnerabilities of SMS to intercept messages in transit. While it is true most small and mid-size businesses probably don’t need to worry about that third attack possibility, and the second can be mitigated against by being careful never to use a link provided in an email to access key accounts, the first exploit sits within the reach of determined attackers. A hole in the bucket The consequences of a successful attack can be serious. Equipped with a compromised ABM account, an attacker could reassign enrolled devices to an MDM server they control, wipe devices, or push malicious apps/profiles or configurations at your devices. Those outcomes are, shall we say, sub-optimal. I’m certain Apple has thought about this. It has, after all, introduced a range of security protections for all its devices, including managed devices. But in this case, it’s left things a little exposed. That weakness is made more critical because Apple’s system permits just a small number of administrators for each ABM setup, regardless of company size. As a result, an attacker might be able to penetrate a company with perhaps tens of thousands of users simply by identifying five names to target with any/all of the above attacks. Apple does not need to leave this hole in its security bucket. What can you do to improve protection? There are some easy wins when you try to protect your business while using Apple’s existing system: The best practice seems to be for admins to use a dedicated phone number that is only used to handle the ABM and never anything else. The number should have SIM swap protection in place. You might be able to set this up with a call to your carrier to have this applied to the account. The number of active admin accounts should be limited to a minimum to narrow the target surface. What can Apple do better? Apple needs to change things up. Doing so needn’t be horrifically complex, either, as most of these mitigations are already in place elsewhere in its ecosystem. Here are some suggestions: Extend authenticator support to ABM admin accounts. Introduce Passkeys for admin accounts. Put FIDO2 support in place so admins can use hardware security keys to authenticate, if they choose. Introduce mitigations such as conditional access, so logins from unexpected locations aren’t respected. Introduce support for Sign in with Apple, using biometric data to a specific device as a second factor. All of these protections are already available in the Apple ecosystem; all Apple needs is to divert a little of its RD cash into implementing the same protections in Apple Business Manager. From what I’ve seen, the Apple admin community would rejoice if it did. I imagine the Apple Business team is already lobbying for it to find the resources to do just that. Please follow me on social media! Join me on BlueSky, LinkedIn, and Mastodon.