"We rolled out MFA. How did the account still get taken over?"
If you've handled an account-takeover incident in recent years, you've probably heard this exact question. The answer is a little uncomfortable: attackers don't crack MFA anymore. They just relay it.
Phishing-as-a-service platforms like Tycoon 2FA have turned the adversary-in-the-middle (AiTM) trick into a mass-market product. The victim clicks a link and lands on a sign-in page that looks flawless, because it isn't a copy at all: it's a reverse proxy serving the real Microsoft 365 page straight through the attacker's server. The password gets forwarded to Microsoft in real time. So does the OTP. The push notification? Approved, of course, because from the user's side this looks like a perfectly normal login. Then the proxy grabs the one thing that actually matters: the authenticated session cookie. The attacker drops it into their own browser and simply becomes the user, MFA and all. Campaigns like this have hit thousands of organizations, and mailbox takeovers that start exactly this way keep popping up across Asia-Pacific.
The takeaway isn't "add more MFA." It's structural: as long as signing in involves a secret the user can type or approve, it can be relayed. SMS codes, authenticator OTPs, and push approvals all fall the same way. What actually stops AiTM is a different kind of credential, one with no secret to hand over in the first place. The industry calls it phishing-resistant authentication, and here's the fun part: every Mac with Apple silicon already ships the hardware for it. It's called the Secure Enclave.
What Is Platform SSO?
Platform Single Sign-on (Platform SSO, usually just PSSO) is a framework Apple introduced in macOS 13 and kept polishing through macOS 14, but honestly, it only grew up in macOS 26, when Simplified Setup finally killed the clunky registration dance users used to suffer through (more on that below). The idea: stop treating "logging in to the Mac" and "logging in to the company identity provider" as two separate chores. Unlock the Mac, and you're authenticated to the IdP (Microsoft Entra ID or Okta today), tokens in hand, SSO everywhere, in apps, in browsers, all day.
Platform SSO comes in three flavors, and they are very much not equal:
| Method | How it works | Phishing-resistant? |
|---|---|---|
| Secure Enclave key | A hardware-bound key pair is created inside the Secure Enclave; sign-in is a cryptographic challenge-response | Yes |
| Smart card | Certificate-based authentication with an external smart card or token (such as YubiKey) | Yes |
| Password sync | The IdP password is synced to the local account password (at login, wake, or every 4 hours) | No |
Password sync is the boring one: convenient, sure, but the credential is still a password, with everything that implies. Smart cards are battle-tested but you have to buy them, issue them, and replace them when someone leaves one in a taxi. The Secure Enclave key is where the story is: smart-card-grade cryptography, using hardware your fleet already owns. Microsoft's implementation is called Platform Credential for macOS, built on the same foundation as Windows Hello for Business.
Why You Can't Phish a Secure Enclave Key
The Secure Enclave is an isolated security subsystem inside Apple silicon (and Intel-based Mac computers with the T2 chip). It has its own processor and its own memory, walled off from macOS. Keys generated inside are non-exportable by design: not by the user, not by malware, not even by macOS itself. The system can ask the enclave to sign something, but it can never read the key.
When a user registers with Platform SSO, the Mac creates a key pair inside the enclave and hands the public key to the IdP. From then on, every sign-in is one round of challenge-response (Entra ID as the example):
- The user unlocks the Mac with Touch ID or the local password, which unlocks access to the Secure Enclave key.
- macOS asks Entra ID for a nonce (a one-time random challenge), valid for all of five minutes.
- macOS builds a sign-in assertion and the Secure Enclave signs it with the hardware-bound private key.
- Entra ID checks the signature against the public key registered for this user on this device, and checks the nonce.
- Entra ID issues a Primary Refresh Token (PRT), encrypted to another device-bound key, and sends it back.
- macOS decrypts the PRT and hands tokens to the SSO extension. Cloud apps, on-prem apps, all smooth sailing from here.
Now run the AiTM playbook against this flow and watch every step whiff:
- Nothing to type. The user never enters a secret, so the fake page has nothing to catch. The "credential" is a signature computed inside silicon.
- Nothing to relay. The signature answers one specific nonce from the real IdP and expires in minutes. A proxied copy is worthless for any other session.
- Nothing to steal afterwards. The PRT is encrypted to a key that also lives in the enclave of this specific Mac. Exfiltrate the token to another machine and all you've got is ciphertext.
- Nothing to grab at rest. The private key physically cannot leave the enclave. Even a fully compromised macOS can't export it.
It's the same security argument as a FIDO2 hardware key, with one difference: this "hardware key" is soldered into every Mac you already handed out.
Bonus: The Same Key Is Also a Passkey
The Secure Enclave credential moonlights. Beyond signing in to the Mac and powering SSO, Platform Credential for macOS works as a phishing-resistant WebAuthn credential for browser reauthentication: those "verify it's you" prompts that Entra ID Conditional Access or sensitive apps throw at you mid-session. That step used to mean retyping a password (phishable) or approving a push (also phishable). Now it's a Touch ID tap, and the enclave answers the WebAuthn challenge.
WebAuthn also brings one more wall AiTM can't climb: origin binding. The browser bakes the website's origin into what gets signed, so a challenge proxied through login.micros0ft-verify.com produces a signature the real service flatly rejects. The fake domain is cryptographically busted.
Two practical notes. First, if your Entra ID FIDO policy uses key restrictions, add the macOS Platform Credential AAGUID (7FD635B3-2EF9-4542-8D9D-164F2C771EFC) to the allow list. Second, high-security shops can turn on UserSecureEnclaveKeyBiometricPolicy (macOS 14.6+), which demands Touch ID, no password fallback, every time the enclave key is touched. Sign-ins then require an enrolled fingerprint physically present, at the price of more prompts and a hard dependency on Touch ID hardware.
macOS Tahoe 26: Phishing-Resistant Out of the Box
For years, the honest asterisk on Platform SSO was the onboarding: log in first, install Company Portal, follow the prompts, register. macOS Tahoe 26 pretty much flattens that:
- Registration during Setup Assistant. With Automated Device Enrollment, Platform SSO registration now happens inside Setup Assistant, before the user ever sees the desktop. Intune drives it with the EnableRegistrationDuringSetup key; with Simplified Setup, the user can even authenticate to the IdP during setup and have their first account created from it. A new Mac is phishing-resistant from first boot.
- Authenticated Guest Mode. On a shared Mac, any employee can sign in at the login window with their IdP identity, work with full SSO, and have the account wiped at logout. Frontline teams, hospitals, and labs finally get clean shared-device identity.
- Tap to Login. Paired with access badges in Apple Wallet, tap an iPhone or Apple Watch and you're in. One catch: per Jamf's current documentation, neither Entra ID nor Okta supports this one yet, so the platform is ahead of the IdPs here.
Version check: these features need macOS 26, a supporting IdP, and an MDM that's kept up (Jamf Pro 11.20 or later on the Jamf side).
Before You Deploy: The Stuff Worth Knowing
Platform SSO is configuration, not code, but the rollout has real decision points:
- Baseline requirements. macOS 14 Sonoma or later recommended (13 works), an MDM to deliver the SSO extension configuration, and for Entra ID: Company Portal 5.2404.0+ (the baseline for PSSO itself; Simplified Setup on macOS 26 needs 5.2604.0+) plus users permitted to register devices.
- Pick the authentication method on purpose. Secure Enclave key is the right default for most fleets. Smart card fits shops with existing CBA/PIV investments. Password sync should be a transition, not a destination.
- Decide the biometric policy before anyone registers. Turning on UserSecureEnclaveKeyBiometricPolicy after the fact forces a full, admin-driven re-registration of everyone. Decide first, then roll out.
- Smart card users can't register in Setup Assistant. That method still needs post-setup registration.
- Already running Jamf Connect? They can coexist, just never on the same job. A common split: Platform SSO handles Secure Enclave key authentication, Jamf Connect keeps non-conflicting duties like Privilege Elevation. Letting both sync passwords is a guaranteed incident.
- Hybrid AD environments are unsupported. Sort out the identity architecture before Platform SSO, not after.
- Switching authentication methods forces re-registration. Moving from password sync to the Secure Enclave key means every user registers again, so map the transition before you start.
- Pair it with Conditional Access to actually finish the job. The real payoff lands when Entra ID Conditional Access requires phishing-resistant authentication strength, slamming the password-plus-OTP side door that AiTM kits love.
The hands-on details (the Jamf Pro configuration profile, Entra ID settings, and rollout sequencing) deserve their own article; this one is about knowing what you're deploying and why it's worth it. For the broader deployment picture, see the 15-step Jamf Pro deployment sequence, and for where Apple is taking identity next (web-based login at the login window, QR sign-in on shared devices), see the WWDC26 device management breakdown.
How KlickKlack Can Help
KlickKlack is the only partner worldwide holding all three Jamf certifications: Elite Partner, MSP, and MSSP, with Apple fleet deployments across semiconductor, electronics manufacturing, finance, government, and education.
- Identity architecture assessment: map your current IdP, MFA posture, and AiTM exposure, and design the Platform SSO rollout that fits
- Deployment and integration: Jamf Pro + Entra ID/Okta configuration, Conditional Access authentication strength policies, and phased user migration
- Managed services (MSP/MSSP): identity, patching, compliance, and security operations for your Apple fleet as a managed service
Further reading: 15-Step Jamf Pro Deployment · WWDC26 Apple Device Management · Apple MDM Complete Guide
Contact KlickKlack for a free consultation on phishing-resistant authentication for your Mac fleet.