I Pointed a Managed Fleet at Apple Passwords—Here’s What Actually Moved

The migration button lies to you. Not maliciously—it just implies something moved that didn’t. When you “migrate to Apple Passwords,” nothing crosses into a new vault. There is no new vault. You’re pouring credentials into the same keychain database Apple has shipped since the iPhone had a home button, and putting a friendlier front door on it.

That distinction is the whole story for enterprise. So let me build it up from the bottom, because the marketing skips the bottom entirely.

The keychain is a database. Passwords is a window.

On every Apple device there is a small encrypted SQLite store called the keychain. Apps don’t read it directly. They ask a system service—Keychain Services—to store or retrieve items, and each item is tagged with a class: kSecClassInternetPassword for website logins, kSecClassGenericPassword for app secrets and tokens, and so on. Think of it as a safe-deposit vault where the clerk is the only one who can open drawers, and every drawer is labeled with who’s allowed to ask.

iCloud Keychain is the sync layer bolted onto that vault. An item only leaves the device if it carries one specific attribute:

1
2
3
4
5
6
7
8
9

let query: [String: Any] = [
    kSecClass as String: kSecClassInternetPassword,
    kSecAttrServer as String: "example.com",
    kSecAttrAccount as String: "alice",
    kSecValueData as String: secret,
    // this single flag decides whether the item syncs via iCloud Keychain
    kSecAttrSynchronizable as String: kCFBooleanTrue as Any
]
SecItemAdd(query as CFDictionary, nil)

Set kSecAttrSynchronizable and the item is encrypted end-to-end and replicated across your trusted devices. Leave it off and it stays local. That flag predates the Passwords app by roughly a decade.

So what did iOS 18 and macOS 15 actually ship? A dedicated app—Passwords.app on the Mac, a first-class icon on iOS—that reads and writes those same keychain items with a UI humans can navigate. It is a window onto storage that already existed. It is not a storage engine, not a new sync fabric, not a new trust boundary. Every security property you care about was decided years ago at the Keychain Services and iCloud Keychain layer. The app changes discoverability, not architecture.

Once you internalize that, the enterprise questions answer themselves in a way the consumer guides never reach.

“Migration” is just SecItemAdd in a trench coat

When a user imports from 1Password or Bitwarden, the Passwords app parses an export file and calls the same SecItemAdd path any app would. The credentials become synchronizable keychain items owned by the user’s iCloud account. Nothing is re-encrypted into a proprietary format, because there is no proprietary format. This is genuinely good news for portability and genuinely bad news for anyone who assumed migration was atomic and lossless. It isn’t. It’s a parser eating a CSV, with all the failure modes that implies.

AutoFill and passkeys don’t notice the migration at all

Here’s where teams get nervous, and here’s where they can relax. Your apps that authenticate with ASAuthorizationController—the passkey and Sign in with Apple flow—never talk to the Passwords app. They talk to the system, and the system routes the request to whichever credential provider is configured.

1
2
3
4
5
6
7
8
9
10

let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
    relyingPartyIdentifier: "login.corp.example.com")
​
let request = provider.createCredentialAssertionRequest(
    challenge: challenge)
​
let controller = ASAuthorizationController(authorizationRequests: [request])
controller.delegate = self
controller.presentationContextProvider = self
controller.performRequests()

A passkey is a WebAuthn/FIDO2 credential—a private key bound to a relying party, stored as a synchronizable keychain item. When your app calls the code above, iOS looks for a platform credential matching the relying party ID. If it lives in iCloud Keychain, the platform provider serves it. If the user has installed a third-party manager that registers an ASCredentialProviderExtension, that provider can serve it instead. The app doesn’t know or care which one answered. It gets an assertion back and validates the signature server-side, exactly as before.

So migrating a user’s passwords into the Passwords app does not touch their passkeys, does not break any ASAuthorizationController flow, and does not require an app rebuild. The only thing that changes is which provider is set as the AutoFill default under Settings. If you flip that from a third-party manager to the built-in one, new passkeys get created in iCloud Keychain going forward—and passkeys already minted inside the third-party manager stay there, because passkeys, by design, don’t export. That’s not a migration gap. That’s the security model working as intended. Plan for a period where users have passkeys in two places.

The Managed Apple ID trap

Now the part that actually decides whether you can retire your third-party manager: a Managed Apple ID is not a consumer Apple Account with a work email. It’s a different account type with a different service matrix, provisioned through Apple Business Manager or federated from Entra ID, Okta, or Google Workspace.

Consumer accounts get iCloud Keychain sync on by default. Managed Apple IDs do not inherit that behavior automatically, and iCloud Keychain is one of the services an organization controls. If sync is off, the Passwords app still works—but it becomes a local password store on each device, with no cross-device continuity. A user who saves a login on their MacBook won’t see it on their managed iPhone. For a lot of IT teams evaluating “can we drop the third-party manager,” that single fact is the answer: not until you’ve confirmed sync is actually available and enabled for your account type. Test it on real hardware with a real Managed Apple ID before you promise anything. Do not extrapolate from your personal iCloud.

The MDM controls are the ones you already have

There is no glamorous new “Passwords app” MDM payload. There is no dedicated data-export toggle that appeared with iOS 18. What governs the app is the set of restriction keys that have governed keychain and AutoFill behavior for years, delivered in a Restrictions payload. The one that matters most:

1
2
3
4
5
6
7
8
9
10

<key>PayloadType</key>
<string>com.apple.applicationaccess</string>
<key>allowCloudKeychainSync</key>
<false/>
<key>allowPasswordAutoFill</key>
<false/>
<key>allowPasswordSharing</key>
<false/>
<key>allowPasswordProximityRequests</key>
<false/>

Set allowCloudKeychainSync to false and every credential in the Passwords app stays pinned to the device—the app keeps functioning, sync stops. allowPasswordAutoFill, allowPasswordSharing, and allowPasswordProximityRequests require supervision and gate whether credentials can fill into apps and browsers, be shared to another Apple user, or be handed to a nearby device. That’s your control surface. It’s coarse. It predates the app. And notably, none of these give you an admin-side export, backup, or recovery path for what a user has stored—if the account is lost, so are the local-only secrets. If your compliance model requires central recovery of credentials, the Passwords app does not provide it, and no restriction key changes that.

Audit what’s actually applied rather than trusting the console:

1
2
3
4
5
6
7
8

# macOS 15 — show installed configuration profiles and payloads
sudo profiles show -type configuration
​
# inspect synchronizable internet-password items in the login keychain
security find-internet-password -g -s login.corp.example.com
​
# list which credential-provider extensions are registered
pluginkit -m -p com.apple.authentication-services-credential-provider-ui

Where TOTP quietly dies

The Passwords app stores time-based one-time-code seeds—the little rotating 6-digit codes—as verification codes attached to a login item, sitting in the keychain like everything else. Good. The problem is getting them in. Most third-party managers export to CSV, and CSV exports frequently omit the TOTP secret entirely, or bury it in a format the Passwords importer won’t parse. I have watched a migration where every password came across clean and not one TOTP seed did, and nobody noticed until people started getting locked out of admin consoles the following week.

Treat TOTP as a separate, manual migration. Re-enroll the seeds deliberately, verify each one generates a matching code before you tear down the old manager, and do it while you still have working access. This is the failure that bites six months later—except it usually bites in six days.

The Passwords app is a good window. It’s a real convenience, and for a lot of consumer users it’s the right call. But you’re not adopting a new security platform. You’re adopting a nicer view of a vault whose rules were written a decade ago—and the two things that don’t come along for free, cross-device sync on Managed Apple IDs and your TOTP seeds, are exactly the two things that decide whether the migration is safe.