Managing passkeys across Apple, Google, and Microsoft platforms

At a glance

What this is: This guide explains how passkeys are managed across Apple, Google, and Microsoft platforms and shows that the main challenge is governing portability, recovery, and deletion across ecosystems.

Why it matters: IAM teams need to treat passkeys as governed identity assets, because cross-platform storage and sync can create inconsistent lifecycle control if ownership, recovery, and revocation are not standardised.

Context

Passkeys replace password-based authentication with cryptographic keys, which changes the governance problem from secret memorisation to device-bound credential lifecycle. For IAM teams, the key question is no longer whether passkeys can be used, but how they are created, synchronised, shared, and removed across Apple, Google, and Microsoft environments.

The article shows that each ecosystem handles passkey storage differently through Apple Passwords and iCloud Keychain, Google Password Manager in Chrome and Android, and Windows Hello on Windows 11. That creates a practical identity management issue: the same user may hold multiple passkey copies across accounts, devices, and cloud sync paths, so lifecycle discipline matters as much as enrollment.

Key questions

Q: How should IAM teams govern passkeys across multiple platforms?

A: Treat passkeys as lifecycle-managed authenticators, not as a one-time login feature. Define where they are stored, how they sync, who can share them, and how they are deleted during offboarding. The main failure mode is inconsistent control across Apple, Google, and Microsoft ecosystems, which creates invisible governance drift even when the user experience looks seamless.

Q: Why do cross-platform passkeys create governance risk?

A: Because the credential can exist in more than one control plane at the same time. Apple, Google, and Microsoft each handle storage and recovery differently, so the user sees one sign-in method while the organisation manages several administrative paths. Without standard ownership and review rules, that distribution becomes a lifecycle and recovery risk.

Q: What breaks when passkey deletion is not tied to offboarding?

A: The identity may remain valid on one or more synced devices even after the account owner should no longer have access. That creates a revocation gap, especially where cloud synchronisation preserves credentials beyond the primary device. Deletion must therefore be treated as a formal offboarding control, not a cleanup task.

Q: What is the difference between passkey syncing and passkey sharing?

A: Syncing copies the same credential across a user's trusted devices through the platform's account ecosystem, while sharing transfers access to another person or group through an explicit platform feature. The first supports continuity for the same identity, while the second extends authentication capability to others and therefore needs stronger governance.

Technical breakdown

How passkeys are bound to platform authenticators

Passkeys are public and private key pairs generated for a relying party and stored in a platform authenticator such as Apple Passwords, Google Password Manager, or Windows Hello. The private key never leaves the protected environment in normal use, while the public key is registered with the service. That design reduces phishing exposure because there is no reusable shared secret to steal and replay. The operational trade-off is that access now depends on the platform's recovery, sync, and device trust model rather than a password reset path.

Practical implication: identity teams should classify passkeys as platform-bound authenticators and review how each platform handles sync and recovery.

Cross-platform passkey sync changes the lifecycle model

When passkeys sync through cloud services, the credential is no longer confined to a single device. Apple uses iCloud Keychain, Google uses Google Password Manager, and Microsoft links passkeys to Windows Hello and the Microsoft account. This means enrolment, portability, and deletion can occur across multiple endpoints, not just one handset or laptop. For governance, that introduces inventory ambiguity: the user experience feels simple, but the lifecycle footprint is distributed.

Practical implication: establish an inventory and offboarding process that tracks where passkeys are stored, synced, and revoked across ecosystems.

Shared access and deletion are governance, not convenience, functions

The article's sharing workflows show that passkeys can be transferred through AirDrop or shared groups on Apple devices, and deleted from platform password managers when they are no longer needed. Those actions are security-sensitive because they move or remove authentication capability, not just a saved preference. In identity terms, sharing extends trust to another device or person, while deletion is the control that ends that trust relationship. Both need clear ownership and approval boundaries.

Practical implication: require explicit ownership rules for passkey sharing and make deletion part of offboarding and access review workflows.

NHI Mgmt Group analysis

Passkeys shift the identity control plane from memorised secrets to managed device trust. The article is not really about convenience features on Apple, Google, and Microsoft. It is about the fact that authentication now depends on where a credential is stored, synchronised, and deleted across platform ecosystems. For IAM programmes, that means the control point moves from password policy to lifecycle governance of a distributed credential.

Cross-platform passkey portability creates governance drift if ownership is not standardised. A passkey that exists in iCloud Keychain, Google Password Manager, or Windows Hello is still one identity artefact, but each platform exposes a different administrative experience. That makes offboarding, recovery, and exception handling easy to fragment across teams. The named concept here is passkey lifecycle drift: the gap between a user's apparent single login experience and the multiple control planes that actually govern it.

Passkey sharing introduces delegated authentication risk even when the underlying cryptography is strong. The cryptographic strength of the credential does not eliminate the governance question of who is allowed to move or inherit that credential. When passkeys are shared through platform features, the real issue becomes authority, not algorithm. Identity teams should treat shared passkey paths as a policy decision, not a user convenience.

Recovery design is the real resilience test for passkey programmes. The article correctly points to backup methods and synced storage, because losing a device should not mean losing access. But recovery that is too easy can weaken assurance, while recovery that is too hard can create support pressure and shadow workarounds. The practitioner conclusion is that passkey rollout succeeds only when recovery policy, device trust, and offboarding are designed together.

Passkeys do not remove IAM work, they relocate it. Passwordless authentication reduces phishing and password fatigue, but it also makes inventory, synchronisation, deletion, and exception handling more important. The organisations that treat passkeys as a UX improvement will accumulate governance inconsistency. The organisations that treat them as an identity lifecycle change will be able to scale them safely.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Passkey lifecycle drift: The more passkeys are copied into cloud-managed platform stores, the more identity teams need a single policy for issuance, recovery, sharing, and deletion. Otherwise the user sees one passwordless experience while operations has three or more separate control paths to govern.

Passkeys will not reduce IAM complexity unless teams tie them to lifecycle controls that are consistent across devices, cloud sync, and account offboarding. The governance work shifts from remembering secrets to managing where trust can persist after a device changes hands.

For practitioners

• Standardise passkey lifecycle ownership Assign clear ownership for enrolment, sync, recovery, and deletion across each platform ecosystem so the same user does not end up governed by three different operational teams.
• Map platform-specific recovery paths Document how users regain access after device loss on Apple, Google, and Windows, then align those paths with your identity assurance requirements.
• Treat passkey sharing as delegated access Set policy for when AirDrop, shared groups, or similar transfer features are permitted, and require review for any shared authentication path.
• Build passkey deletion into offboarding Ensure account closure, device retirement, and employee offboarding include removal of synced passkeys from all relevant password managers and authenticators.

Key takeaways

• Passkeys improve authentication resilience, but they also move the core control problem into identity lifecycle governance across platform ecosystems.
• Apple, Google, and Microsoft each expose different management paths for storage, sharing, recovery, and deletion, which can create control inconsistency.
• IAM teams should treat passkey rollout as a governance programme, with clear ownership for sync, recovery, revocation, and offboarding.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Platform authenticator: A platform authenticator is built into the user’s device and uses the device’s hardware-protected key store for private-key operations. Examples include Touch ID, Face ID, Windows Hello, and Android biometric systems, all of which support phishing-resistant authentication when configured correctly.
• Synced Passkey: A synced passkey is a FIDO credential that can be replicated across multiple devices through a cloud account and recovery system. It can improve usability, but it also shifts trust from a single device to the sync provider, recovery workflow, and account protections surrounding the credential.
• Passwordless Authentication: An authentication approach that removes passwords and uses a device-bound cryptographic key plus local user verification. It reduces phishing and replay risk, but it only improves assurance when enrollment, recovery, and revocation are tightly governed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.