How should organisations govern passkeys across multiple domains?

What cross-domain passkey governance needs to decide

Cross-domain passkey use only works safely when the organisation can explain the trust relationship in policy terms, not just in product settings. That means deciding which origins are allowed to share a credential, who owns the related origin entries, and what review process applies when those entries change. The same discipline that governs authentication should also govern the relying-party boundary, as outlined in the Authentication Guide.

For most organisations, the real question is whether a shared passkey reduces friction without weakening control over where that passkey can be used. Passkeys are not interchangeable with passwords here: the trust decision is tied to the relying party and origin relationships, so governance must define the approved use case before rollout. Where passkey design details matter, teams should review the Passwordless and Passkeys Guide alongside the technical implementation.

That governance model should also account for how the credential behaves if the same user journey spans multiple brands, subdomains, apps, or partner-hosted properties. If one domain can authenticate a passkey created for another, the organisation has created a security dependency that must be owned, documented, and justified like any other shared trust path. Teams evaluating whether that boundary is technically sound can use the FIDO2 and WebAuthn Internals Guide to understand relying party verification and related origin behaviour.

How to manage ownership, change control, and exceptions

Passkey governance across domains should sit inside identity governance, not product onboarding or web team preference. The owner of the origin list should be accountable for the approved domains, the business rationale for sharing, and the lifecycle of changes when domains are added, removed, or consolidated. That ownership model should also be consistent with your broader authentication policy, as reinforced by the NIST SP 800-63 Digital Identity Guidelines.

Change control matters because cross-domain trust is easy to overextend. A domain merger, a marketing microsite, a regional rebrand, or a vendor-managed portal can silently expand the places where one passkey works if the origin file is not reviewed carefully. Good governance requires a named approval path, a reason recorded for each shared domain set, and periodic revalidation that the trust boundary still matches the business need.

If the organisation cannot explain why two domains should trust the same passkey, the correct answer is to keep them separate. That is especially important where a shared sign-in path would blur accountability, create unexpected user exposure, or make later incident response harder because the same credential can reach multiple properties.

What can go wrong when passkeys span domains

Cross-domain passkey sharing increases the blast radius of a bad trust decision. If one origin is weaker than the others, an attacker who compromises that weaker domain may gain an easier path to user authentication flows that were assumed to be isolated. The practical issue is not passkey technology itself, but the way shared origin trust can turn one mismanaged property into a broader access path.

Another risk is governance drift. Teams often add domains to improve rollout speed, then forget to retire them, which leaves old brands, staging properties, or acquired businesses implicitly trusted long after the original justification has expired. That is why passkey governance should be treated like a trust inventory problem, not a one-time implementation choice.

Practitioner Guidance

What to prioritise: Start with the origin set, not the user experience. Build an approved inventory of domains that may share a passkey, and require a business owner for each relationship.

What to verify: Confirm that every shared-domain decision has an explicit rationale, an expiry or review date, and a change owner who can approve additions or removals. If those three items do not exist, the trust relationship is not governed.

Common mistake: Treating cross-domain passkey use as a convenience feature that can be widened later. Once a trust boundary is implicit, it becomes much harder to prove why it exists or to unwind it safely.

Practitioner takeaway: Cross-domain passkeys are manageable when the organisation can defend each shared origin as a deliberate trust decision, with ownership and review built into identity governance from the start.

Related resources from NHI Mgmt Group

• How should organisations govern machine identities across multiple regions?
• How should organisations govern reusable digital identity across multiple services?
• How should teams govern SPIFFE federation across multiple trust domains?
• How should NHS trusts govern shared IAM across multiple organisations?