Each passkey is bound to a relying party ID (RP ID), which is a domain name. The browser only lets a site use credentials whose RP ID matches its own domain or a parent of it. A lookalike domain has a different RP ID, so the passkey is never offered, which is how passkeys resist phishing.
What an RP ID is
The W3C WebAuthn spec says an RP ID is based on a host's domain name. It does not include a scheme or port, unlike an origin. The RP ID determines the credential's scope: the set of origins on which it can be used.
The rule is that the RP ID must equal the origin's effective domain, or be a registrable domain suffix of it. And the page must be served over https (the spec has a narrow exception for localhost in development).
How it plays out
| Page origin | RP ID you may use | Result |
|---|---|---|
| https://login.example.com | login.example.com | Works on that host only |
| https://login.example.com | example.com | Works on example.com and its subdomains |
| https://login.example.com | other.com | Rejected by the browser |
| http://example.com | example.com | Rejected, not https |
| https://examp1e.com | example.com | Rejected, not a suffix of that domain |
The last case is the phishing defence. The user never has to notice the odd spelling. The authenticator receives the RP ID from the browser and will not produce an assertion for a credential created under a different one. The spec notes each credential is scoped to an RP ID, so other sites cannot even probe whether you have an account elsewhere.
Choosing an RP ID
- Use the registrable domain (for example example.com) if you want one passkey to work across several subdomains such as app.example.com and login.example.com.
- Use a specific host if subdomains belong to different teams or trust levels and you do not want credentials shared among them.
- Decide before launch. A credential created under one RP ID cannot move to another. Changing it later means every user registers again.
- Avoid shared suffixes you do not control. You cannot use a public suffix or a domain you do not own as your RP ID.
Server side checks
On both registration and sign in, your server must verify the rpIdHash in the authenticator data equals the SHA-256 of the RP ID you expect, and that the origin in the client data is one you expect. These are separate checks. The RP ID covers the domain scope, while the origin check covers the exact page, scheme and port.
What about native apps and other domains
If your mobile app needs to use the same passkeys as your website, the platform has to be told the app and the site belong together. The details differ by operating system, so check your platform documentation for the association files. The WebAuthn spec itself only fixes the RP ID rules above.
Pitfalls
- Choosing the RP ID from the request Host header instead of fixed configuration. An attacker controlling the header could influence it.
- Sharing a registrable domain with untrusted tenants, such as user content on subdomains. Any subdomain that can run script may be able to ask for credentials scoped to the parent.
- Testing on localhost and shipping the same config.
Quick check
Can I change my RP ID later?
Not without users registering new credentials. Credentials are bound to the RP ID they were created with.
Is the RP ID the same as the origin?
No. The RP ID is a domain without scheme or port. The origin includes scheme, host and port, and you verify both.
Safeguard's SBOM and dependency scanning shows which WebAuthn libraries your apps use and whether any carry known advisories. Try the free scan.
Sources
Last reviewed: 19 October 2026.
