A related origins set lets one passkey be accepted across multiple approved domains that belong to the same relying party family. In practice, it shifts trust from a single hostname to an explicitly governed list, which makes ownership and change control part of authentication design.
What Related Origins Means for Passkeys
Related origins let a relying party define a governed set of approved domains that can share one passkey. That changes passkey trust from a single hostname to an explicitly managed family of origins, so ownership and approval boundaries become part of authentication design.
Why the Model Exists
In modern web estates, one product or brand may span several domains, for example regional sites, separate top-level domains, or distinct login surfaces. Related origins reduce user friction by letting the same credential work across those approved entry points, while still keeping the trust decision bounded to the relying party family rather than the open web.
This matters because a passkey is still tied to an origin-based trust model. When organisations split across multiple hostnames, they must be clear about which domains are equivalent for authentication purposes and which are not, or they risk creating confusing user journeys and inconsistent sign-in behaviour.
How Trust Is Governed
The important security question is not just whether a domain can use the passkey flow, but who is allowed to add, remove, or modify the related-origins list. The allowlist becomes a security control in its own right, because every approved origin inherits authentication trust from the relying party family.
That governance layer is why related origins should be treated as part of identity architecture, not as a convenience setting. The control needs clear ownership, change review, and documentation so that domain expansion, mergers, rebrands, and delegated web properties do not silently widen the trust boundary.
For implementation detail on how relying party verification and related origin requests work in practice, see the FIDO2 and WebAuthn Internals Guide.
Failure Modes and Operational Consequences
If the related-origins set is too broad, a weaker or poorly governed domain can inherit access to the same authentication surface as the primary site. If it is too narrow, users may be forced into fallback login paths that undermine the passkey rollout and increase support friction.
Misconfiguration also creates drift over time. Domains can be retired, redirected, or repurposed, and if the allowlist is not reviewed, authentication trust may survive after the business relationship or technical ownership has changed.
Good practice is to treat related origins as a living inventory of trust relationships. The list should be reviewed whenever a domain is added, moved, sold, or delegated, because the security of the passkey flow depends on the accuracy of that boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Related origins governs how authenticated users can sign in across approved web origins. |
| AC-2 — Account Management | The allowlisted origin set is an account-access governance decision that needs ownership and review. | |
| CM-3 — Configuration Change Control | Related origins is a governed trust configuration that should change under formal control. | |
| Recommendation — Apply IA-2 to ensure each approved origin authenticates users under a controlled trust boundary. Use AC-2 to review and approve origin changes that expand or remove passkey access paths. Use CM-3 to formalise changes to the related-origins allowlist before deployment. | ||
| NIST SP 800-63 | 2 — Digital Identity Model and Enrollment Requirements | The term sits within browser and relying-party identity trust decisions that 800-63 frames. |
| Recommendation — Align origin trust decisions with the digital identity assurance model for the relying party. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org