Does sharing passkeys via the /.well-known/webauthn endpoint cause authentication or enrollment issues on either domain?

No. Passkeys cryptographically bind to the configured Relying Party RP ID. When configuring the RP ID to a custom domain, for example, <login.domain.com>, the passkey permanently ties to that domain.

Related origins that are defined in the /.well-known/webauthn file simply allows the web browser to present that credential on other trusted origins, such as the default Okta domain. This does not change the underlying RP ID, allowing authentication and enrollment to function normally on both domains without conflict.

If a user enrolls a passkey while on the default Okta domain, is the passkey still tied to the custom domain?

Yes. Even if a user signs in and enrolls a passkey from the default Okta domain, the passkey remains tied to the configured RP ID (the custom domain). Because the default domain is added as a related origin, the browser recognizes the trust relationship and allows the credential to be used and registered appropriately to the custom domain.

What happens to authentication if the default domain is removed from the trusted associated domains in the future?

If a related origin is removed (that ist is, removing the default Okta domain from the /.well-known/webauthn file), users will no longer be able to use their passkeys when signing in from that removed origin.

However, this does not break the passkeys. The passkeys themselves remain perfectly valid and will continue to work normally when users authenticate directly through the RP ID (the custom domain).

Does this configuration impact access from mobile (Android/iOS), desktop, or native applications?

No. The /.well-known/webauthn configuration specifically governs browser-based WebAuthn flows. It does not directly impact native desktop or mobile app access, unless those specific applications rely on a browser context (like an embedded web view) to perform WebAuthn.

Are updates to the Apple App Site Association or Android Asset Link endpoints required in addition to the .well-known endpoint?

No. For standard WebAuthn passkey sharing across domains in a browser, only the /.well-known/webauthn endpoint is required.

The Apple apple-app-site-association and Android assetlinks.json files are not needed for this specific use case. Those files are only required if you are implementing platform-specific app-to-web credential sharing (for example, sharing a passkey between a native iOS app and a Safari website).

Related References

• Passkeys and custom domains