WebAuthn gives an application a strong way to bind a credential to an origin and a relying party. It does not decide which tenant owns an account or whether a user handle is safe to reuse. Those are application decisions made around the ceremony. Multi-tenant systems need to treat the relying party identifier and the user handle as security-boundary data, not as convenient configuration defaults.
The Web Authentication specification defines the relying party identifier, or RP ID, as a valid domain string that identifies the relying party. A credential is scoped to that RP ID. The browser also supplies the caller's origin in the collected client data, and the relying party verifies that origin. A server that checks an assertion signature but ignores the RP ID or origin policy has checked only part of the ceremony.
Use a domain that belongs to the tenant boundary
The RP ID must be equal to or a registrable domain suffix of the caller's effective domain. It cannot be an arbitrary string chosen by the server. An application hosted at login.example.com may use login.example.com or example.com as its RP ID, subject to the specification and browser rules. It cannot use m.login.example.com for that origin.
That domain rule creates a design choice. If many tenants share one parent RP ID, the browser treats the associated credentials as belonging to that RP ID. The application must then keep tenant identity, user handles, credential IDs, and server-side account mappings isolated. Reusing the same user.id for different tenants can turn a valid assertion into the wrong account if the lookup ignores the tenant context.
A cleaner pattern is to assign each tenant its own RP ID when its deployment has a distinct DNS boundary. The server should also derive the tenant from the request origin and authenticated session rather than accepting a tenant ID from the browser as authoritative. If a tenant moves domains, plan credential migration explicitly. Do not silently re-register an existing credential under a new RP ID and assume it remains the same security object.
Bind registration and authentication records
During registration, store the RP ID, origin policy, credential ID, public key, user handle, tenant, authenticator flags, and creation time in one server-side record. During authentication, use the requested credential and the session's tenant to find that record. Verify the signature over the authenticator data and client data hash, and verify that the rpIdHash matches the expected RP ID.
Do not look up an account by email address alone. Email addresses can be changed, duplicated across identity providers, or reused after account deletion. A credential belongs to a stored user handle and a RP ID. If an administrator merges accounts, the merge workflow must decide which credentials remain valid and record that decision.
The origin check needs a policy for legitimate subdomains. A mobile app, a web application, and an embedded enterprise portal may produce different origins. List the expected origins for each RP ID. Do not use a prefix match that accepts example.com.attacker.net. Do not accept an origin merely because its path starts with the expected hostname.
Treat user verification as a variable
The user-verified flag describes whether the authenticator performed user verification for that ceremony. It is not a permanent property of a credential. A policy that requires user verification must request it and reject a response that does not satisfy the requirement. A policy that permits a security key with a PIN and a separate factor should state which condition it actually enforces.
The same care applies to discoverable credentials and account selection. If the browser returns a credential without a username, the server still needs to resolve the credential and tenant before showing account-specific information. Rate-limit account enumeration at the application layer and return neutral errors. WebAuthn does not remove the need for ordinary authorization checks after login.
Test the tenant matrix
Build tests that register the same-looking username in two tenants, authenticate each credential, and prove that neither assertion can be replayed into the other tenant. Repeat with subdomains that share a parent RP ID. Test an assertion from a stale origin allowlist, a credential after an account rename, and a disabled tenant.
Record the RP ID and origin policy in the audit evidence for each registration. Monitor signature failures, RP ID hash mismatches, and unknown credential IDs by tenant. A sudden increase in unknown credential IDs may indicate a misconfigured domain or a credential database problem before it indicates an attack.
WebAuthn is strongest when the application treats the ceremony as part of an account model. The RP ID defines where a credential may be used. The application must define who may use it, for which tenant, and with which authorization rights.