@chatteberg I just saw your post. If you have a paid support plan you can open a ticket. If you do not have a paid support plan, are you still experiencing the issue?

You can retrieve all identity provider links for a user by sending a GET request to:

/api/identity-provider/link?userId={userId}

Important: The parameter name is case-sensitive and must be userId (with capital "I"), not userid.

The error you're seeing occurs when the parameter is lowercase userid instead of the correct camelCase userId. Using the correct casing will return a list of all identity provider IDs that the user is currently linked to.

Make sure your request looks like:

GET {baseUrl}/api/identity-provider/link?userId=4aa40fcd-0102-4c26-a51c-9a6c5c0c504a Authorization: <your-api-key>

This endpoint works with a standard API key and will return the identity provider link information you need to determine if a user is linked to external providers.

For FusionAuth Cloud deployments, you can obtain the outbound IP address list by opening a support ticket in the FusionAuth Account Portal and providing your deployment hostname.

Key facts about FusionAuth Cloud outbound IPs:

Complete list: FusionAuth will provide the complete list of outbound IP addresses for your specific deployment. These are the only addresses your deployment will use. Note that IP addresses are not exposed through the user interface—opening a support ticket is the only way to obtain them.

Static addresses: The outbound IP addresses are static and will not change during:

Upgrades Maintenance windows Normal scaling operations

For new FusionAuth Cloud deployments, static IP addresses are already configured. If the IP addresses ever need to change, FusionAuth will notify you in advance.

All outbound traffic: All outbound traffic from your FusionAuth Cloud deployment originates from the same set of IP addresses, including:

SMTP/email traffic Webhooks HTTP calls from Lambdas Any other outbound connections

You can safely use these IP addresses to configure firewall rules, SMTP server allowlists, and other security restrictions for services that need to accept connections from your FusionAuth Cloud deployment.

Important: The provided IP addresses should only be used to allow outbound traffic through firewalls and network control layers. Do not use them for HTTP/API calls, as they won't respond to such requests. In addition to IP allowlisting, consider using custom headers, TLS transport, and client certificates to further secure outbound traffic.

Related Documentation Deployment IP Addresses - Official documentation on obtaining IP addresses for FusionAuth Cloud deployments FusionAuth Account Portal - Support - How to access the support portal to request IP addresses FusionAuth Cloud Overview - General information about FusionAuth Cloud deployments

You are correct — FusionAuth can add SMTP headers under Tenant → Edit → Email → Advanced → Additional headers, but those headers apply to all emails sent for that tenant. There is currently no way to set headers per-user or per-email.

Your two workarounds are both valid approaches:

Option 1: SMTP Proxy

Route FusionAuth's outgoing SMTP traffic through an SMTP proxy or mail-relay service. Your proxy can inspect the recipient, determine their consent state, and inject the required tracking headers before final delivery.

Option 2: Webhooks + External Mailer (Recommended for full control)

Disable FusionAuth's built-in email templates and handle all email sending via webhooks to your own backend or third-party mailer. This gives you complete control over templating, state checking, and headers per user.

Webhook-based flow:

Disable the built-in email templates in FusionAuth so it doesn't send anything itself. Navigate to Tenants → Edit → Email → Templates and set each template to disabled or leave it unassigned. You can also configure this at the application level under Applications → Your Application → Email → Templates to override tenant-level settings.

Set up webhooks under Settings → Webhooks, pointing to your backend endpoint. Enable the specific events you need.

Your backend listens for events, pulls relevant data from the webhook payload, checks user consent state, and sends the email through your own mailer with appropriate headers.

Key webhook events and payloads: Email Verification: verificationId to build the verification link Forgot Password: changePasswordId to build the reset link Setup Password: check user.password is null to confirm they need setup Breached Password (user.password.breach😞 user.email to notify them to change their password Suspicious Login (user.login.suspicious😞 event.info for device and location details (Enterprise feature) Registration Verification (user.registration.verified😞 verificationId to build the verification link MFA Method Added/Removed: method object with the method type and identifier

Important: If you use the webhook approach, make sure to disable all relevant email templates in FusionAuth. If you leave some templates enabled while your third-party mailer is active, users will receive duplicate emails — one from FusionAuth and one from your mailer.

Related Documentation Configure SMTP - Custom Headers - Information on configuring tenant-level SMTP settings including additional headers Announcing FusionAuth 1.32 - Custom Email Headers - Details on the custom email headers feature added in version 1.32 Events & Webhooks - Complete documentation on FusionAuth's webhook system Email Templates - Managing and disabling email templates Application-Specific Email Templates - Overriding email templates at the application level User Login Suspicious Event - Webhook payload for suspicious login events User Password Breach Event - Webhook payload for breached password events User Registration Verified Event - Webhook payload for registration verification events

Yes, FusionAuth Cloud uses static outbound IP addresses that you can whitelist in your downstream services. The specific IPs depend on your deployment's region.

These IP addresses are static and will not change under normal circumstances. If FusionAuth ever needs to modify or add to these addresses, customers will receive advance notification.

To obtain the specific outbound IPs for your region, you'll need to open a support ticket through the FusionAuth Account portal with your deployment name and details.

Important Notes:

New deployments receive static outbound IPs by default. If you have an existing deployment created before static IPs were standard, you may need to request them via support ticket. The provided IP addresses are intended only for allow-listing outbound traffic (such as SMTP services, webhooks, LDAP connectors, etc.). These IPs should not be used to make inbound API calls, as they won't respond to such requests. Static IPs are available for all FusionAuth Cloud deployments, including both standard and High Availability (HA) configurations. Related Documentation FusionAuth Cloud - Deployment IP Addresses - Official documentation on obtaining IP addresses for your deployment FusionAuth Cloud - Support - How to access support and open tickets for IP address requests FusionAuth Cloud Overview - General information about FusionAuth Cloud hosting

This is going to vary based on your publishing system, but you can use FusionAuth's OIDC prompt=none to see if users have an active SSO session.

If the user has checked remember me and has logged in within the tenant session timeout, the request will succeed, otherwise it will fail.

Step 1: Main Page

This creates the iframe and listens for the result.

On your main page, create the hidden iframe targeting FusionAuth with prompt=none. You also listen for a message event from the iframe to know whether to display or hide the CTA <div>, which needs the id trial-cta:

// 1. Listen for the result sent back from the iframe callback page window.addEventListener('message', (event) => { // Verify the origin matches your application domain for security if (event.origin !== window.location.origin) { return; } const ctaDiv = document.getElementById('trial-cta'); if (event.data && event.data.type === 'SILENT_AUTH_RESPONSE') { if (event.data.status === 'authenticated') { // User has an active SSO session; keep CTA hidden if (ctaDiv) { ctaDiv.style.display = 'none'; } } else if (event.data.status === 'login_required') { // User is not authenticated; show the trial CTA popup/div if (ctaDiv) { ctaDiv.style.display = 'block'; } } } }); // 2. Create the hidden iframe to initiate the prompt=none request const iframe = document.createElement('iframe'); iframe.style.display = 'none'; iframe.src = 'https://<your-fusionauth-instance>/oauth2/authorize?' + 'client_id=<YOUR_CLIENT_ID>&' + 'response_type=code&' + 'redirect_uri=https://<your-app-domain>/silent-callback.html&' + 'scope=openid&' + 'prompt=none&' + 'state=<YOUR_STATE>'; document.body.appendChild(iframe); Step 2: Callback Page

Configure this page as an authorized redirect URI in your FusionAuth application [Request Parameters].

When FusionAuth redirects back with the authorization code code or error=login_required, this page parses the URL and communicates back to the parent window:

// Parse query parameters from the redirect URI const params = new URLSearchParams(window.location.search); const code = params.get('code'); const error = params.get('error'); if (code) { // Session exists: notify the parent window window.parent.postMessage({ type: 'SILENT_AUTH_RESPONSE', status: 'authenticated', code: code }, window.location.origin); } else if (error === 'login_required') { // No active session: notify the parent window to show CTA window.parent.postMessage({ type: 'SILENT_AUTH_RESPONSE', status: 'login_required' }, window.location.origin); } Cautions And Additional Considerations

This won't work across all browsers, especially those with privacy features or if your FusionAuth instance isn't on the same root domain as the application. More details here.

Test the scenarios you need to support.

The CTA should include information about how to sign up or log in if the user already has an account.

You may want to add server or client side logic to obfuscate the page contents.

This is expected behavior for certain authentication flows in FusionAuth. When authentication happens via methods like refresh token grants, SSO handoffs, or silent authentication (where the user already has an active session), the event may not include an applicationId because the authentication isn't directly tied to a specific application registration at that moment.

Workarounds and Best Practices 1. Check the JWT for Application Context

Your applications should be validating the JWT claims after authentication, including:

applicationId (or aud claim) — identifies which application the token was issued for Other application-specific claims

See JWT Components Explained for details on these claims.

2. Enable Automatic Registration on Proxy Applications

If you're using a proxy or gateway application that performs authentication on behalf of other applications, enable automatic registration for that proxy application. This ensures users are properly registered to the proxy app, which can help maintain application context.

Refer to the Application Suite edge cases documentation for scenarios where this pattern is useful.

3. Alternative Event Sources

For complete application attribution, consider:

Using user.registration.create events when users first register to applications Combining user.login.success events with application-level audit logs Implementing custom event enrichment in your webhook consumer that correlates login events with subsequent token validation Important Note

Self-service registration, if enabled, allows anyone to register to that application. Your applications should always validate that the user has a proper registration (jwt.applicationId) and any other business-specific claims required for access.

The user.update.complete event intentionally does not fire when the verified flag changes through email verification. This is by design.

Email verification is considered a distinct workflow separate from the general user update process in FusionAuth's event model. As noted in a related GitHub issue, the decision was made to introduce dedicated verification events rather than triggering user.update.complete because email verification "does not occur due to the Update User API, but because of a separate workflow." The user.update.complete event is reserved for changes made through the Update User API, while verification-specific changes trigger their own dedicated events.

Recommended Solution

You should listen to these specific webhook events for verification state changes:

user.email.verified — fires when an email address is verified (available since 1.8.0) user.identity.verified — fires when an identity (email or phone number) is verified (available since 1.59.0) Handling Race Conditions

If you're concerned about race conditions when multiple events fire simultaneously:

Adjust your Kafka partitioning strategy to key on userId — this ensures all events for the same user go to the same partition and are processed in order Use event timestamps in your downstream consumers to deduplicate or order events correctly. Each event includes a createInstant field in the event object that can be used for ordering Design your sync logic to be idempotent so that processing events out of order doesn't cause inconsistent state

The separate user.email.verified and user.identity.verified events provide more granular control over what verification changes you respond to, which is generally more useful than a generic user update event.

Related Documentation User Update Complete Event — documentation for the user.update.complete event User Email Verified Event — documentation for the user.email.verified event User Identity Verified Event — documentation for the user.identity.verified event Kafka Integration — comprehensive guide to FusionAuth's Kafka integration for consuming webhook events Webhook Event Log — review events sent by FusionAuth with timing and result information

Yes, this is possible with some configuration adjustments.

The key insight is that you can use an MFA requirement lambda to selectively enforce MFA during login based on user attributes (like a user type or role), while still allowing all users to participate in step-up authentication flows later. The MFA requirement lambda is an enterprise plan feature.

Recommended Approach Configure MFA methods for all users (both staff and non-staff), but differentiate their login behavior using an MFA requirement lambda Set the tenant MFA login policy to something like Required or Enabled Create an MFA requirement lambda that: Returns true (require MFA) for staff users Returns false (skip MFA) for other user types during login

This way:

Staff users will be challenged for MFA on every login Non-staff users will skip MFA during login but still have MFA methods configured All users can participate in step-up authentication flows when your application calls the step-up APIs, because they all have MFA methods available Example Lambda Logic function checkRequired(result, user, registration, context) { // assumes there's a role assigned to the user registration. could also examine other attributes or make a fetch call var userRoles = registration && registration.roles || []; if (userRoles.includes('staff')) { result.required = true; } else { result.required = false; } }

This approach delegates the step-up authentication flow and code sendout completely to FusionAuth while maintaining your login MFA requirements.

The /oauth2/logout endpoint only removes the SSO session (the front-channel session controlled by the "Keep Me Signed In" toggle). It does not automatically revoke the refresh token (also known as offline_access).

To properly implement logout, you need to handle both sessions separately:

Recommended Logout Flow User initiates logout in your application Your backend revokes the refresh token using the Revoke Refresh Tokens API:DELETE /api/jwt/refresh/{refreshTokenId} Or revoke by user and application:DELETE /api/jwt/refresh?userId={userId}&applicationId={applicationId} Destroy your local application session (clear tokens, cookies, etc.) Redirect to /oauth2/logout with id_token_hint to clear the SSO session Why This Approach?

Revoking the refresh token from your application (step 2) is better than relying on the logout URL callback because:

You have direct access to the user's session data You know exactly which refresh token to revoke You can handle errors gracefully The flow is more deterministic

The /oauth2/logout endpoint can call a logout URL configured in your FusionAuth OAuth application settings, but handling revocation proactively in your app provides better control.

Important Note About JWTs

Since JWTs (access tokens) are stateless, they cannot be immediately revoked by FusionAuth. If you need to invalidate JWTs before their natural expiration, you'll need to implement your own revocation strategy, such as maintaining a token denylist in your application.

Related Documentation OAuth Logout API - Details on the /oauth2/logout endpoint Revoke Refresh Tokens API - How to revoke refresh tokens programmatically Logout and Session Management - Comprehensive guide on logout strategies and session types Revoking JWTs - Strategies for JWT revocation JWT Refresh Token Revoke Event - Webhook event when refresh tokens are revoked

Yes, this is intentional behavior in FusionAuth.

When a user provides a recovery code to disable an MFA method — whether through the hosted pages or the API — FusionAuth removes all MFA methods from the account. The hosted pages use the same underlying MFA API, so the behavior is consistent across both interfaces.

Why does this happen?

Recovery codes are designed as a last-resort mechanism. The assumption is that if a user must resort to a recovery code to disable MFA, they may have lost access to all their authentication factors. Removing all MFA methods ensures the user can regain access and re-enroll fresh methods.

When a recovery code is used for disabling MFA:

All MFA methods are removed from the user's account, regardless of which specific methodId was targeted All remaining recovery codes are invalidated at the same time If the user later adds a new MFA method, a brand new set of recovery codes will be generated Why is login different?

When a user logs in with a recovery code (instead of a verification code), FusionAuth only consumes that specific recovery code without removing MFA methods. This is because login is not an administrative action — the user is simply authenticating, not managing their MFA configuration.

Current limitations

Unfortunately, there is currently no way to configure FusionAuth to remove only the targeted MFA method when a recovery code is used. This is a known design constraint.

Workaround considerations

If this behavior is problematic for your use case, you could:

Provide clear messaging to users before they use a recovery code to disable MFA Implement a custom flow outside the hosted pages that uses the API with tighter control over which methods are removed Encourage users to contact support or use an alternative recovery flow that doesn't rely on recovery codes for MFA management

Feedback on this behavior has been passed along to the FusionAuth Product team for future consideration.

Related Documentation Multi-Factor Authentication (MFA) - Disable MFA Guide - Explains the behavior when using recovery codes vs. verification codes to disable MFA Disable Multi-Factor API - API documentation for disabling MFA methods Recovery Codes Overview - Information about MFA recovery codes and when they're generated Self-Service Account Management - Documentation on the hosted account management pages including MFA management

Now I have enough information to improve the answer. Let me create an enhanced version with documentation links.

To grant a user access to the FusionAuth admin UI, you need to:

Create the user in the Default tenant (not a custom tenant) Register them for the FusionAuth application (the built-in admin application) Assign them an appropriate admin role during registration (e.g. "admin" for full access or a more limited role)

The key distinction is that the Tenant Manager Application is intended for granting third-party users limited admin access to manage users and identity providers within a specific tenant (this is an Enterprise feature). For full admin UI access, you must use the FusionAuth application in the Default tenant.

If the user's password setup email is being filtered as spam, you can set a temporary password manually and they'll be prompted to change it on first login.

Steps to add an admin user: Navigate to Users in the Default tenant Create a new user or select an existing one Go to the Registrations tab Click Add registration Select the FusionAuth application Choose the appropriate admin role from the dropdown Save the registration Available Admin Roles

Here are the main admin UI roles you can assign:

Role Description admin Can manage everything, including creating new users with administrator privileges user_support_manager Limited scope — recommended for tier 1 support staff user_support_viewer Can view user information only user_manager Can add and edit users (note: this role has similar power to admin, so use user_support_manager for restricted access) user_deleter Can delete users

Important: A user must have a registration in the FusionAuth application to access the admin UI — group membership alone is not sufficient.

Related Documentation FusionAuth Admin UI Roles - Complete list of admin roles and their capabilities User Support Guide - Detailed guide on creating admin users Default Tenant - Why the Default tenant cannot be deleted and its relationship to the FusionAuth application Tenant Manager Application - Enterprise feature for providing limited admin access to third-party users within specific tenants

The issue is related to the email template configuration for the mfa_deleter role. The mfa_deleter role has additional requirements beyond just assigning the permission - it needs a properly configured notification system to alert users when their MFA is removed by an administrator.

Key Requirements for the mfa_deleter Role

For the mfa_deleter role to work properly, the target user (the user whose MFA is being removed) must be notifiable through at least one verified primary identity:

Verified email: Requires the "Admin two-factor method removal" email template to be configured in your tenant's email settings Verified phone number: Requires the equivalent message template to be configured in your tenant's phone/messaging settings

The system enforces this as a security measure - when a non-admin user removes someone's MFA method using the mfa_deleter role, the affected user must be notified. If the target user doesn't have a verified email or phone number, OR if the corresponding template isn't configured, the operation will fail.

Resolution Steps Navigate to Tenants → [Your Tenant] → Email tab In the Template settings section, locate the "Admin two-factor method removal" field Assign a valid email template to this setting (you may need to create one first if it doesn't exist) Ensure the target users have verified email addresses Test MFA removal again with a user who has the mfa_deleter permission

Note: You only need to configure the notification method (email or phone) that matches the verified identity your target users have. You don't need both configured if all users have verified emails, for example.

Why Admins Can Remove MFA Without This

Users with the full admin role can remove MFA methods without these template requirements because they have elevated privileges. The mfa_deleter role is specifically designed for support teams and has additional safeguards to prevent abuse, including mandatory user notification.

Related Documentation The mfa_deleter Role - Official documentation on the role and its requirements User Support Guide - Remove MFA Method with mfa_deleter - Step-by-step guide for support teams Disable MFA on a User - General MFA management documentation Admin Two-Factor Authentication Method Removed Email Template - Template variables available for customization Tenant Configuration - Understanding tenant-level template settings

This behavior changed due to the introduction of Intelligent MFA in FusionAuth 1.68, which significantly expanded the risk signals used to trigger suspicious login detection.

What Changed

Prior to version 1.68, suspicious login emails were primarily triggered by Impossible Travel detection (when a user appears to log in from geographically distant locations in an impossibly short time).

Starting in 1.68, FusionAuth added many more risk signals to the suspicious login detection system as part of the Intelligent MFA feature. This means more login scenarios now trigger the suspicious activity email.

How to Tune the Detection

If you want to restore the previous behavior or customize the risk detection to reduce false positives, you can configure this in your tenant settings:

Navigate to Tenant > Edit > Security > Client Risk Config Configure the risk signals that should trigger suspicious login alerts To match the pre-1.68 behavior, set it to only trigger on "Impossible Travel"

You can customize these settings to find the right balance between security and user experience for your application.

Both entry points, and especially the anti-enumeration behavior on the known-tenant path, are best built by calling FusionAuth's passwordless APIs directly from your own UI rather than relying on the hosted login pages. Here's more on the difference.

Using the API is the only way to get full control over what the UI shows on a failure.

Known-tenant entry (acme.ourapp.com) Maintain your own slug/domain → tenantId table (outside FusionAuth), populated when you provision each tenant via the Tenant API. FusionAuth has no built-in hostname-to-tenant mapping. You can learn more in the multi-tenant guide. At request time, resolve the subdomain to a tenantId from that table (outside FusionAuth). If nothing matches, show "Workspace not found" — this never touches FusionAuth. Build your own "enter your email" screen for this workspace (not FusionAuth's hosted page — you need to control what's shown on failure, which the hosted page won't let you do). When the user submits an email, your backend calls /api/passwordless/start with that tenantId + your Universal Application id + the email as loginId. Universal Application docs here. Branch on the response, entirely inside your backend: 200, code sent → hang onto the returned code value, respond to your frontend with a generic "we sent you a code" message, and show your own "enter the code" screen. 404, no user found → this is the real signal Slack is hiding. FusionAuth returns a 404 with an empty body when no user matches the tenant. Instead of surfacing that: send your own "no account with this email in this workspace" notice through your own transactional email provider (outside FusionAuth or using the send email API), then respond to your frontend with the exact same "we sent you a code" message. Show the identical "enter the code" screen either way. Completing the challenge: Real branch: verify the code the user types via /api/passwordless/login (tenantId + code), which returns tokens; pair this with the Hosted Backend / BFF if it's a SPA. Alternatively, redirect the browser to /oauth2/passwordless/{code}?tenantId=<tenantId>&client_id=<id> and let FusionAuth's hosted page take over the code-entry step. This is the URL FusionAuth's own passwordless email template constructs for the "click to log in" link, so redirecting there yourself just skips the email round-trip. Fake branch: there is no FusionAuth code to hand off, so there's nothing to redirect to on FusionAuth's hosted domain — you have to own the "enter code" screen yourself here. Whatever the user types, respond with the same generic "invalid or expired code" error you'd give a real wrong code; never a distinct message. If you're using the hosted-page redirect for the real branch, don't try to fake that redirect for this branch — just render your own equivalent screen and always reject, rather than attempting a look-alike hosted destination. Pad the fake branch's response time to roughly match a real Start call, so the two paths don't diverge on timing, which would leak the same thing you're hiding in the UI. Generic entry (ourapp.com/login) Call /api/user/search with a global (not tenant-scoped) API key and no tenantId filter, searching by the submitted email. Each matching User record already includes its own tenantId, so this single call tells you every workspace the email belongs to. This pattern (global key, /api/user/search?queryString=<email>, results include per-tenant matches) is answered on the forum. Keep the key server-side only. If you'd rather not run a global-key search on every anonymous request (latency, or wanting the key confined to a webhook receiver instead of a public endpoint), you can maintain your own email → tenantId[] table fed by FusionAuth's user.create / user.update / user.delete webhooks instead. Docs at https://fusionauth.io/docs/extend/events-and-webhooks/. Either is fine — this is a trade-off, not a hard requirement. Branch on the result (outside FusionAuth): No match → "No account found," stop there. One match → continue with that tenant. Multiple matches → show a workspace picker, then continue with the chosen one. This is currently functionality you have to build yourself, though there is an open issue. Once a tenant is resolved, it's the same steps as section 1 from "build your own enter-email screen" onward — including the fake-challenge branch, if you want the same anti-enumeration behavior here too (Slack's generic "find your workspaces" entry also avoids confirming or denying a match directly, for the same reason). A few things worth flagging FusionAuth users are tenant-scoped records — the same person needs a separate User object per workspace they belong to. API key scope matters: the cross-tenant search in section 2 needs a global key; the tenant-specific calls in section 1 can safely use a tenant-scoped key. [Docs](Docs at https://fusionauth.io/docs/apis/api-keys). The SSO session cookie isn't tenant-aware across hostnames — FusionAuth doesn't currently support true multi-tenant SSO through the hosted pages, so the user behavior when switching tenants requires another login. Always pass tenantId explicitly on every call. Passwordless API reference for the exact Start/Login request and response shapes:

This behavior is likely due to changes introduced in FusionAuth 1.68.0 related to Intelligent MFA and Risk Signals.

Starting in 1.68.0, FusionAuth uses a variety of "Risk Signals" to determine when to trigger the Suspicious Login email. The email is sent whenever any enabled risk signal returns a HIGH value. One common signal that can cause this is:

DormantPassword: This signal triggers when a user's password hasn't been changed "in the last few months." If your users do not regularly rotate their passwords, this risk signal could be flagging every login as suspicious. Solution

You can fine-tune which Risk Signals are considered for your tenant:

Navigate to Tenants > Edit Tenant > Security > Customize Risk Signals Review the enabled risk signals Consider toggling off the Dormant Password signal if password rotation is not part of your security model, or adjust other signals as appropriate for your use case Testing

To verify this is the cause:

Try changing a user's password, then logging in again to see if the suspicious login email still triggers Alternatively, disable the Dormant Password risk signal temporarily and test login behavior

This should allow you to re-enable suspicious login notifications while avoiding false positives for normal login activity.

No, you cannot configure the same custom domain on two different FusionAuth Cloud deployments at the same time.

The recommended migration sequence is:

Remove the custom domain from the production deployment Configure the custom domain on the dev deployment Configure a CNAME record pointing your custom domain directly to the dev deployment's durable hostname Validate the certificate for the domain on the dev deployment Important Considerations

DNS Propagation Time

DNS changes take time to propagate Expect up to 30 minutes for DNS servers to recognize the changes Propagation may take longer depending on your DNS TTL settings Plan for this downtime window during your migration

Certificate Validation

Certificate validation uses DNS-based methods You must complete the DNS configuration before certificate validation can succeed

To minimize downtime, prepare all configurations on the dev deployment beforehand, then execute the domain removal, DNS update, and certificate validation in quick succession.

FusionAuth does not perform Unicode normalization on passwords before hashing.

Passwords are hashed using the raw bytes exactly as received from the client. This means:

If a user sets a password with Unicode characters, those exact byte sequences are hashed Different Unicode representations of visually identical characters (e.g., é as a single composed character U+00E9 vs. e + combining acute accent U+0065 U+0301) will result in different password hashes No normalization forms (NFC, NFD, NFKC, NFKD) are applied

This behavior means you should ensure consistent encoding at the application level if Unicode normalization is important for your use case. The password validation will only succeed if the exact same byte sequence is provided during authentication.

Additional Context

FusionAuth fully supports Unicode characters in passwords, which is recommended for both usability and security reasons. When FusionAuth validates passwords for special characters, it processes them as Unicode strings (using Java's Character.isAlphabetic() and Character.isDigit() methods on 16-bit Unicode values), confirming that passwords are handled as Unicode throughout the system.

There are no inherent limitations on which Unicode characters can be used in passwords stored in FusionAuth, though you can configure password validation rules to enforce specific requirements for your tenant.

Related Documentation Password-Hashing Algorithms - Overview of FusionAuth's password hashing schemes (PBKDF2, Bcrypt, etc.) Custom Password Hashing - Information on implementing custom password hashing schemes Password Validation Rules - API for retrieving and configuring password validation rules Client-side Password Rule Validation - Guide for implementing password validation in your client application Are there any disallowed characters in passwords? - Community discussion confirming no inherent character limitations

There are several ways to monitor your hosted FusionAuth deployment:

Basic Health Monitoring

You can use the System Status API to get basic information about your deployment, including whether it is healthy. For dedicated health checks (particularly useful for load balancers), there's also the Health API available since version 1.51.1.

Detailed Metrics with Prometheus

For more detailed performance monitoring, you can configure Prometheus to retrieve system metrics from FusionAuth. FusionAuth exposes:

JVM-level gauges: memory usage, garbage collection stats, thread counts, class loading, buffer pools Request timers: endpoint latency and request counts (e.g., prime_mvc_* metrics)

You can then set up Prometheus dashboards to visualize this data and track CPU, memory, and other performance metrics over time.

See the FusionAuth Prometheus documentation for configuration details and the Prometheus Metrics API for endpoint information.

Important Considerations for Hosted Deployments

If your hosted FusionAuth deployment has multiple compute nodes, be aware that both the Status API and Prometheus metrics endpoints return data per-node. Since requests are round-robined across nodes, successive API calls may hit different nodes and return inconsistent data. This makes direct polling less reliable for multi-node deployments.

Additional Monitoring Options

Beyond Prometheus, FusionAuth can integrate with other monitoring tools:

Datadog: Use the Datadog Agent with OpenMetrics integration CloudWatch: Monitor FusionAuth metrics in AWS environments Grafana: Visualize Prometheus data with pre-built dashboards

You can also access:

System logs: Available via API (exportable as ZIP files) Audit logs: Track administrative actions via API or webhook Event logs: Debug information for external integrations Login records: Successful login history with timestamps, IPs, and user details Webhooks: Get real-time notifications for specific events Related Documentation Monitoring FusionAuth Overview System Status API System Health API Prometheus Integration Guide Prometheus Metrics API Datadog Integration CloudWatch Integration

Yes, successfully logging in with a passkey will update the user's last login instant.

However, there are edge cases where a passkey can be used without updating the last login timestamp:

Scenarios where passkey use doesn't update last login:

Login flow interrupted — The user authenticates with the passkey, but the login is stopped before completion due to:

Failed MFA challenge User action requirement (e.g., forced password reset) Account lock or suspension Login validation Lambda or transactional webhook rejecting the login

WebAuthn assertion without login — If the user performed a WebAuthn assertion directly via the API, this counts as using the passkey but does not constitute a full login flow and therefore doesn't update the last login instant. The Complete a WebAuthn Passkey Assertion API validates the WebAuthn ceremony but "does not authenticate the user into an application." This is different from the Complete a WebAuthn Passkey Authentication API, which validates the passkey and authenticates the user, thus updating the last login instant.

Summary

A passkey being "used" is not the same as a completed login. The last login timestamp only updates when the authentication flow completes successfully and issues a token.

Related Documentation Complete a WebAuthn Passkey Authentication - The API that validates passkeys and authenticates users (updates last login) Complete a WebAuthn Passkey Assertion - The API that only validates passkeys without authenticating (does not update last login) Authentication With WebAuthn & Passkeys - Complete guide to WebAuthn/passkey authentication in FusionAuth Update Login Instant API - Manual API for updating login instants when implementing custom SSO Setting Up User Account Lockout - How account lockouts can interrupt login flows