Managing passkeys across Apple, Google, and Microsoft platforms

At a glance

What this is: This is a practical guide to managing passkeys across Apple, Google, and Microsoft platforms, with the key finding that cross-platform passkey handling is becoming more interoperable but still platform-specific.

Why it matters: It matters because IAM teams need to govern passwordless recovery, account portability, and lifecycle cleanup without assuming one platform’s passkey model maps cleanly to another.

👉 Read Descope's guide to managing passkeys across Apple, Google, and Microsoft

Context

Passkeys replace knowledge-based authentication with cryptographic keys stored on devices and synchronized through platform password managers. In practice, that makes them a human identity control, not an NHI mechanism, and the governance problem shifts from password policy to device-bound credential lifecycle.

The operational gap is consistency. Apple, Google, and Microsoft each implement passkey storage, sharing, deletion, and recovery differently, so identity teams need a model that covers enrollment, recovery, revocation, and device loss across all three ecosystems rather than treating passkeys as a single universal control.

Key questions

Q: How should security teams govern passkeys for shared application accounts?

A: Security teams should treat the shared account as the governed object and the passkey as the authentication method attached to it. That means assigning ownership, controlling enrolment, logging usage, and removing access when the user, device, or business relationship changes. Without those lifecycle controls, passkeys can improve login security while leaving accountability problems intact.

Q: When does passkey adoption create new governance risk?

A: Risk increases when organisations treat passkeys as a pure authentication upgrade and ignore recovery, device loss, and enrolment governance. If the fallback path is weaker than the primary path, attackers will target the exception process instead of the authenticator itself. Strong adoption depends on managing the full identity lifecycle, not just sign-in.

Q: What do teams get wrong about passkey security?

A: Teams often assume passkeys are either perfect or too risky to adopt. The better view is that they remove the reusable secret that makes phishing and replay so effective, while leaving a smaller set of governance questions around recovery, sharing, and sync protection. The control is stronger, but policy still matters.

Q: How do organisations know whether passwordless access is actually improving security?

A: Look for reduced password dependence, fewer lockouts, lower help desk reset volume, and stronger control over high-risk workflows such as shared workstation access and privileged clinical systems. If user friction drops while identity assurance rises, the programme is moving in the right direction.

Technical breakdown

How platform authenticators store and sync passkeys

Apple Passwords, Google Password Manager, and Windows Hello act as platform authenticators, meaning the passkey is generated as a cryptographic key pair and bound to the device or account ecosystem that stores it. The private key never leaves the protected environment in readable form, while the public key is registered with the relying party. Sync creates convenience, but it also expands the administrative surface because the identity team must account for multiple recovery and deletion paths across ecosystems.

Practical implication: Map where each platform stores the passkey and document how deletion and recovery work before standardising passwordless adoption.

Why passkey sharing changes access governance

Sharing passkeys through AirDrop or shared groups on Apple devices, or through synced password managers on Google and Windows ecosystems, turns passkeys from purely individual authenticators into potentially shared access artifacts. That does not make them weak by default, but it does mean governance has to distinguish between delegated access, shared household or team accounts, and accounts that should never be shared. The control issue is lifecycle accountability, not the cryptography itself.

Practical implication: Define which accounts may be shared, who owns revocation, and how you will detect passkeys left behind in shared groups.

Recovery and device loss are the real lifecycle risk

Passkey guidance often focuses on creation, but the harder identity problem is recovery when a primary device is replaced, lost, or decommissioned. If iCloud Keychain, Google account sync, or Windows Hello recovery is not configured, users can be locked out or routed into weak fallback paths. That makes recovery design part of identity assurance, not an afterthought. The most reliable programmes treat passkey recovery as a governed joiner-mover-leaver concern, even though the subject is a human user.

Practical implication: Require documented recovery methods and test them before large-scale passwordless rollout.

NHI Mgmt Group analysis

Passkey management is a human identity lifecycle problem, not just an authentication upgrade. The article shows that passkeys are only useful when enrollment, sync, sharing, deletion, and recovery are all governed as one process. That is the same lifecycle discipline IAM teams already apply to passwords and MFA, but the control points move into device and cloud account ecosystems. Practitioners should stop treating passkeys as a point feature and govern them as an identity state that can be created, shared, lost, and revoked.

Cross-platform passkey interoperability creates policy drift unless ownership is explicit. Apple, Google, and Microsoft each expose different management paths, which means users can end up with multiple passkey stores and different revocation paths for the same account. That increases the chance that stale access survives device replacement or account migration. The practical conclusion is that passkey policy must name the owning ecosystem and the fallback path, not just the credential type.

Shared passkeys are governance exceptions that need documented intent. When a passkey can be moved into a shared group or shared through a platform feature, the identity control resembles delegated access more than private authentication. Without explicit rules, teams will confuse convenience with approval. That makes shared passkeys a recertification and ownership issue, not just a usability choice.

The real security win comes when passkey rollout removes weak recovery paths rather than adding another login option. Passwordless adoption only reduces risk if it replaces reusable secrets and unsafe account recovery, not if it sits beside them as an extra method. Identity teams should measure whether passkeys are reducing password dependence, shrinking recovery abuse, and improving account cleanup. Otherwise the programme is modern in appearance but unchanged in governance.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• Top 10 NHI Issues helps teams translate identity governance into controls for machine and human access boundaries alike.

What this signals

Passkey rollout should be measured by lifecycle closure, not just adoption counts. If teams cannot prove that deleted devices, changed roles, and account removals actually revoke passkey access, the programme is only partially governed. The next maturity step is to tie passkey administration into NHI and IAM lifecycle discipline, even though the credential itself belongs to human identity.

A passkey estate becomes manageable when recovery is designed as a controlled exception path rather than a convenience path. That means testing the recovery chain, documenting shared access decisions, and making stale credential cleanup part of routine identity operations.

Passwordless programmes often stall because organisations modernise login but leave recovery and ownership untouched. The identity signal to watch is whether passkeys reduce password dependence without creating new shared-access ambiguity or device-loss lockouts.

For practitioners

• Define platform ownership for passkey lifecycle management Assign a clear owner for enrollment, sharing, deletion, and recovery across Apple, Google, and Microsoft ecosystems so users are not left with conflicting cleanup paths.
• Document approved recovery methods before rollout Require trusted recovery methods for lost-device scenarios and test that those methods do not fall back to weak, reusable secrets.
• Set rules for shared passkey exceptions Allow shared groups only for explicitly approved use cases, and tie them to named owners who can revoke access when the relationship changes.
• Review stored passkeys on a fixed cadence Schedule periodic reviews to remove unused passkeys, close stale access, and confirm that deleted accounts no longer have live credentials in platform stores.

Key takeaways

• Passkeys simplify authentication, but they do not simplify identity governance.
• The main risk is not the cryptography, but the recovery, sharing, and deletion lifecycle around it.
• IAM teams should treat passkey adoption as a controlled human identity programme with explicit ownership and revocation rules.

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.
• Passwordless Recovery Flow: The fallback path used when a user cannot complete passwordless authentication because a device is lost, enrolment fails, or account recovery is needed. In practice, this flow often becomes the easiest path to abuse if it is less controlled than the primary authentication method.
• Shared Passkey: A shared passkey is a passkey intentionally made available to more than one person or device through a platform sharing feature or shared group. It creates a governance exception because the identity team must define approval, ownership, and revocation rules for access that is no longer purely individual.

What's in the full article

Descope's full article covers the platform-specific operational steps this post intentionally leaves for the source:

• Step-by-step passkey enrollment and deletion flows for iOS, macOS, Android, Chrome, and Windows 11.
• Platform-specific sharing workflows, including AirDrop, shared groups, Google Password Manager sync, and Windows Hello.
• Device and account settings needed to enable passkeys, such as iCloud Keychain, two-factor authentication, and Windows Hello setup.
• Practical handling details for users who need to manage passkeys across multiple browser and operating system combinations.

👉 Descope's full guide covers the platform-by-platform steps for creating, sharing, and deleting passkeys.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.