The Mac local password and the company password have been two different things for twenty years.
This is the framework that finally reconciles them. Change a password anywhere, on the machine or through your directory, and the other side follows. Local accounts can be built the moment somebody signs in with a company identity rather than being pre-created by an administrator. And crucially all of it happens at the login window itself, not in some catch-up process after the user is already sitting at a desktop. For any Indian organisation running Microsoft Entra ID, this closes the single oldest ticket category in the Mac support queue. We deploy it remotely from Gachibowli, Hyderabad.
- macOS 13+The stated minimum version
- 5 methodsPassword, web, smart card, Secure Enclave, access key
- Password syncLocal and identity provider, either direction
- On demandLocal accounts created at first sign-in
One is an Apple framework. The other is a product that addresses the same problem.
We deploy both, and the difference is worth understanding properly, because people routinely treat them as competing purchases when they are not that at all.
- What Apple ships is a capability inside macOS. It needs a management service that supports Extensible Single Sign-on configuration and a compatible extension from whoever provides your identity. There is no licence to buy here, because this is plumbing rather than a product.
- Jamf Connect, by contrast, is a product solving the same underlying problem, designed to sit within a Jamf-managed estate surrounded by Jamf tooling. For Indian organisations already invested in Jamf Pro, that integration plus the wider capability set around it is the genuine argument in its favour.
- The practical question is therefore not which of the two, but what your device management service and your identity provider each support, and whether you want the Apple framework configured directly or a product experience built around it.
- For the Microsoft-centric majority of Indian businesses, Entra ID plus Intune plus the Microsoft SSO extension is the common path, and the prerequisites are specific: Company Portal 5.2404.0 or later, an SSO extension MDM payload configured by an administrator, and macOS versions checked against what each feature needs.
Eight things about Platform SSO that decide whether it fits your estate.
Password synchronisation, in both directions
Once enabled, a password change propagates automatically between the local account and your identity provider regardless of where the change originated. That one behaviour eliminates the most tediously familiar ticket in any Indian service desk: somebody rotated their company password on Friday, the Mac never learned about it, and now they cannot get into their own laptop at nine on Monday with a client call at half past.
Local accounts created on demand
A local account can be built at the moment somebody first signs in using their directory credentials, and you choose which identity attribute supplies the account name. Think about where that helps: shared Macs, hot-desking floors, training rooms, any machine touched by more than one person. The entire exercise of pre-creating accounts for people who may never use that particular device simply disappears.
A Secure Enclave-backed key, the interesting one
Here the user still signs in with a local account password, but the authentication itself rides on a key held in the Secure Enclave. The distinction matters enormously: authentication becomes tied to that specific piece of hardware rather than to a secret somebody could be talked out of over a convincing phone call. That is a fundamentally stronger property than password synchronisation alone, and it deserves consideration for anyone whose account an attacker would actually target.
Web-based authentication, using the journey you already run
Web flows work here, complete with multifactor prompts and QR code scanning. The significance is subtle but real. If your identity provider already enforces a particular sign-in journey with conditional policies and second factors, the Mac login runs through that same journey. Without it you end up with a parallel, simplified path into your environment that quietly sidesteps the controls your team spent a year building.
Smart card and access key options
Smart cards are supported provided they are registered with your identity provider, and there is also an access key method working as pass-based authentication through Apple Wallet. With five approaches available, nearly every organisation discovers one that mirrors what they already do elsewhere. Take that route. Matching your existing practice is a far quicker path to a decision than inventing a new authentication model purely for the Mac population.
It works with your device management service, whichever it is
Nothing here locks you to a particular vendor. Apple asks only for a management service capable of Extensible Single Sign-on configuration and a matching extension from your identity provider. Organisations on Intune, on Jamf, or on something else entirely can all use this, so long as both halves of that requirement are genuinely satisfied. Confirming exactly that is the first thing we do on any engagement.
Shared device keys, which gate several features
Apple requires shared device keys for a specific list of capabilities: Automated Device Enrollment, Touch ID, web authentication, guest mode, on-demand accounts and network authorisation. Do not file that away as a footnote. Look at the list again and notice that several of those items are the exact reasons organisations adopt this framework in the first place, which makes shared device keys a design decision rather than an implementation detail.
Version requirements that need checking against your fleet
The floor is macOS 13, though the more interesting capabilities want later releases. If you are on Microsoft Entra ID there are two further conditions: Microsoft recommends macOS 14 Sonoma as a minimum and requires Company Portal at 5.2404.0 or above deployed before any user is targeted. Which of these features your actual machines can support is something we measure against your real inventory rather than assume from a version policy document.
Four things that decide whether a Platform SSO rollout is smooth.
We confirm both halves of the prerequisite first
Two conditions have to hold simultaneously, and people frequently assume one will do. Your management service must support Extensible Single Sign-on configuration, and your identity provider must supply a compatible extension. Add the macOS versions genuinely present in your fleet, plus the Company Portal version if you are on Entra, and a twenty minute conversation tells us whether you are buying a configuration project or a prerequisites project. Those cost very different amounts.
We choose the method from what you already run
The options run from passwords, federated environments included, through web flows with multifactor and QR scanning, smart cards, a Secure Enclave-backed key, and an access key living in Apple Wallet. Resist the temptation to pick the most sophisticated. The correct choice is nearly always the one that mirrors how the rest of your organisation already authenticates, because consistency is what makes people stop noticing the login.
We plan around the shared device key requirements
Six capabilities depend on shared device keys: Automated Device Enrollment, Touch ID, web authentication, guest mode, on-demand accounts and network authorisation. Since that list includes most of the reasons anyone wants this framework, we settle the requirement at the start. Skip it and you produce an elegant design that quietly assumes a capability whose prerequisite was never switched on.
We handle the existing Macs deliberately
Enrolling a brand new machine is trivial. Handling a laptop somebody has lived on for three years, whose local password parted company with their directory password long ago, is a migration with its own risks. Working out that starting position across the whole fleet and then sequencing the change team by team, delivered remotely from Hyderabad, is precisely what separates a rollout nobody notices from a week of people unable to log in.
Six Indian situations where Mac identity is worth solving properly.
A design, media or engineering team on Macs
Practically every technology or creative company in India has one of these teams, and they are reliably the hardest group to persuade of any IT process. Give them a login that accepts the password they already use for everything else and you remove a small daily annoyance. More usefully, you also make every future conversation about managing their machines noticeably easier.
A regulated firm needing consistent identity controls
You have multifactor everywhere, conditional policies, periodic access reviews, and then a population of Macs signing in against a local password nobody governs at all. That is a genuine control gap, and DPDP-driven security reviews are increasingly good at spotting it. Web-based authentication with multifactor closes it by routing the Mac login through exactly the same journey and the same conditions as every other sign-in in your organisation.
An organisation with shared or hot-desked Macs
Accounts appearing the moment somebody signs in with a company credential is precisely what a shared estate needs, and it deletes the entire pre-provisioning exercise. One caution to carry into the design: on-demand accounts sit on Apple list of features requiring shared device keys, so that prerequisite belongs in your plan from the first day rather than being discovered during a pilot.
Education and training environments
Computer labs, teaching rooms and shared workstations cycling through a dozen people between morning and evening, which describes most Indian universities and training institutes. Accounts forming at first sign-in, named from whichever identity attribute you nominate, makes that estate genuinely manageable. The alternative is an administrator preparing accounts for every student who might conceivably sit at every machine.
A helpdesk drowning in Mac password calls
Pull your ticket history and count them. Somebody rotates their directory password, the laptop never hears about it, and now they are locked out of the machine sitting in front of them. Two-way synchronisation does not reduce that category, it eliminates it, and the count you already have in your service desk is usually the fastest internal business case anyone could ask for.
An organisation moving towards phishing-resistant authentication
Anchoring authentication in a Secure Enclave key ties it to that physical machine rather than to a secret a person can be tricked into revealing, which is a categorically different security property from synchronising a password. Organisations already deploying passkeys and hardware-bound credentials across their Windows and web estate should treat the Mac login as the obvious next place to apply the same reasoning.
How Mac identity actually works in Indian organisations.
| Feature | Platform SSO configured | A directory binding or product | Local accounts, unconnected |
|---|---|---|---|
Local password matches the company password | Yes | Usually | No |
Password change propagates automatically | Yes | Sometimes | No |
Local accounts created without pre-provisioning | Yes | Sometimes | No |
Company multifactor policy applies at sign-in | Yes | Varies | No |
Hardware-bound authentication available | Yes | Varies | No |
Works from the login window | Yes | Varies | Not applicable |
Depends on a directory connection | No | Frequently | No |
Shared Macs practical to run | Yes | Awkward | No |
Password reset generates a support call | Rarely | Sometimes | Routinely |
Frequency in the Indian market | Rare | Uncommon | Very common |
Five approaches, and what each one involves.
| Method | What it involves | |
|---|---|---|
| Password | Credential-based, including WS-Trust for federated environments | |
| Web-based | Flexible flows with multifactor support and QR code scanning | |
| Smart card | Hardware token, requiring registration with the identity provider | |
| Secure Enclave-backed key | Local password sign-in using a key bound to the device hardware | |
| Access key | Pass-based authentication through Apple Wallet | |
| Local account creation | Accounts created on demand at first sign-in with an identity provider credential | |
| Password synchronisation | Local password syncs with the identity provider on change, locally or remotely |
Five steps, and the prerequisites check comes first.
- 1
Confirm the prerequisites and the fleet
Four checks: does your management service support Extensible Single Sign-on configuration, does your identity provider publish a compatible extension, and what macOS versions are genuinely running out there against the stated minimum. On Entra ID we add a fourth, verifying Company Portal sits at 5.2404.0 or later before a single user is targeted.
- 2
Choose the authentication method and the account model
We settle which authentication method matches how you already work, whether passwords synchronise, which identity attribute supplies the local account name, and whether shared machines create accounts on demand. Everything built afterwards follows from these four answers, so they are worth an hour of proper discussion.
- 3
Enable the prerequisites the features depend on
Chiefly shared device keys, which Apple makes mandatory for Automated Device Enrollment, Touch ID, web authentication, guest mode, on-demand accounts and network authorisation. Given that list overlaps almost perfectly with why organisations start these projects, treating it as an optional detail is how a deployment ends up delivering less than was promised.
- 4
Pilot on both new and established Macs
A clean enrolment and a three-year-old laptop with a long-diverged password do not behave the same way, and only the second teaches you what the migration actually involves. We test both with genuine users rather than with IT staff who instinctively work around problems, because those users are the ones who reveal the true shape of the rollout.
- 5
Communicate, then roll out in waves
Because this alters how everyone gets into their own laptop, one short honest message covering what will look different and who to contact if it does not work is worth more than any amount of technical rehearsal. After that we move team by team, starting with whichever group will forgive a hiccup, delivered remotely wherever in India those teams happen to sit.
What Indian organisations ask about Platform Single Sign-on.
Fifteen questions worth answering first.
Prerequisites
- Does your management service support Extensible SSO?A stated Apple requirement.
- Does your identity provider have a compatible extension?The other half of the requirement.
- What macOS versions are in your fleet?macOS 13 or later is the stated minimum.
- Are the Macs enrolled in management already?Configuration is delivered through it.
- Do you use Automated Device Enrollment?Shared device keys are required for it.
Design
- Which authentication method fits your identity approach?Five are supported.
- Do you want password synchronisation enabled?It works in both directions.
- Which identity attribute becomes the local account name?Administrators specify this.
- Do any Macs need accounts created on demand?Shared, lab and hot-desk devices.
- Is Touch ID or guest mode in scope?Both require shared device keys.
Existing Macs
- How many local accounts already exist per Mac?The starting state shapes the migration.
- Do local and company passwords currently differ?They almost always do.
- Are any Macs below the minimum macOS version?A refresh or upgrade question.
- How will users be told what is changing?It affects their daily sign-in.
- What is the fallback if something goes wrong?Sign-in changes deserve a rollback path.
The pages around this one.
macOS management
The wider Mac management picture: enrolment, configuration, updates and where identity fits into it.
Learn moreJamf Connect
The Jamf product addressing Mac identity, and how it compares as an approach for a Jamf-managed estate.
Learn moreMac in a Microsoft environment
The integration picture around identity: management ownership, Defender, updates and conditional access.
Learn moreOfficial documentation
- Apple Platform Deployment, Apple Support
- Microsoft Entra documentation, Microsoft Learn
Check two things: your management service and your identity provider.
Platform SSO needs a device management service supporting Extensible Single Sign-on and a compatible extension from your identity provider. Both, not either. If you have them, this is a configuration project. If not, that gap is what to solve first, and we will tell you which it is within 4 business hours of your enquiry.