Yes, you would need something on your end to poll the Audit Log to fetch changes made to the Entities. Currently. there's no way to enter a log into the system logs (fusionauth-app.log) or otherwise control what goes in there. We do have a similar example for Cloudwatch on exporting Login Records to Cloudwatch which should be helpful.

https://fusionauth.io/docs/operate/monitor/cloudwatch

Having only one user be able to log in with username/password is relatively straightforward with FusionAuth. You could use a Login Validation Lambda or transactional user.login.success Webhook to check the authentication type on each login, which will tell you if they are logging in via a specific Identity Provider or with a password then stop users from logging in based on that criteria. Then set it up so that only the break glass user is able to login with a password.

The slightly trickier part here is only having the username/password field show up for that user. The only way to accomplish this with Simple Themes would be to have managed domains setup such that all normal users are directed to IdPs but the break glass user is on a separate domain so they get to see the login page. With managed domains, the login field changes just to email address for the first step. Then it will check the users email address against domains you have setup for specific IdPs and if they match a IdP then a user is directed straight to that IdP. Any user with a domain that does not match gets sent to the regular email/password login page.

https://fusionauth.io/docs/extend/code/lambdas/login-validation

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success

https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/#managed-domains

This is a little tricky since a user could log in from either provider at any given time. The JWT populate lambda only has access to the user object and the registration object so you would need something on either of those to reference in the lambda. Each time a user logs in from a Identity Provider, the user in FusionAuth gets updated with the user data from the IdP. So for the JWT populate to work, you would need both providers to have a custom data field that maps to the same user.data field in FusionAuth. Then have the JWT populate Lambda map this user.data to either a custom claim or to the roles claim in the JWT, whatever works to determine the internal role on your side. Essentially this field would get updated or overwritten every time the user logs in and which would means the JWT from that login should have the correct "role".

https://fusionauth.io/docs/extend/code/lambdas/jwt-populate

A JWT populate lambda runs whenever a JWT is minted and the reconcile lambda runs whenever a user logs in from an IdP. Which means there is a scenario if a user is logged in on both networks at the same time, it would not be accurate since the JWT from both sessions would be reading from user.data which got updated by the last IdP login. Something like the following feature would also likely be enough to solve this problem for you, we have a similar field on Webhooks but not in JWTs or Lambdas which would detail which IdP used to login.

https://github.com/FusionAuth/fusionauth-issues/issues/1483

It makes sense that this problem is happening. Once we have a SSO session on the computer/browser, then if MFA is required as part of the hosted workflows, FusionAuth will prompt for it based on the existing SSO session.

To solve this problem, you could opt to not make use of the FusionAuth SSO session. So, if you are using our Advanced themes, you could remove the option for an SSO session by removing the Keep Me Signed In checkbox from the theme. Using our Simple Themes, you would set the SSO Session to a really short duration in Tenant Settings (2 seconds, for instance) thus effectively removing the SSO session. Both of these options would eliminate this problem described above.

If you still wanted to generate a FusionAuth SSO session, and you wanted to solve this specific problem, you could use Advanced Themes and hardcode a logout link on this MFA page to allow a user to reset the session and login again. This same solution is not possible using Simple Themes, but a feature request could be logged if you wanted to see this logout link included in Simple Themes at a later date.

To upgrade the FusionAuth deployment, you just need to visit account.fusionauth.io and go to the Hosting tab. From there, each deployment has a drop down button where you can select Upgrade. From there you can upgrade version by version or leapfrog to the latest version, we always recommend testing out the upgrade on dev before rolling it out to production. For your dev instances, there will be downtime of up to 60 minutes but usually I see it takes 20-30 minutes. For production we do a rolling node upgrade since it's a multi-node instance, therefore it should not have much downtime at all(seconds) as traffic just gets routed to nodes 2 & 3 while node 1 is getting upgraded.

As far as rollbacks and backups, we keep snapshots of the database for your production deployment since its High Availability. Your dev and staging instances do not have backups since they are Basic Cloud. If you want to enable backups and rollbacks, you would need to move the Dev or Staging instance to the next tier of hosting, Business Cloud. For production, we will take a snapshot of the database every time right before you upgrade. These backups are available for up to 30 days. Then we also have 3 days of general rolling backups for your production that we can rollback to. Rolling back is a manual process from our end so that's something you have to contact us to initiate. Something to keep in mind is that it's a complete database rollback, so any logging or changes made since the snapshot will be lost so there is data loss with these rollbacks.

https://fusionauth.io/docs/get-started/run-in-the-cloud/cloud#upgrading-a-deployment

With the Essentials plan, you do have MFA available to you on a Tenant level under Tenant>Multi-Factor. To have users set up MFA you either need to set MFA to Required, where users will need to set up MFA to complete a login or you will need to enable the “Self Service Account Management” page so users can visit it to set up MFA. So you can set up MFA for any Tenant to make it available to users.

https://fusionauth.io/docs/lifecycle/authenticate-users/multi-factor-authentication

https://fusionauth.io/docs/lifecycle/manage-users/account-management/

In order to change MFA settings at the Application level for enabling MFA on a project by project basis, you would need to upgrade to the Enterprise plan.

Thanks for the question! If you navigate to Applications > Index View - FusionAuth > Multi-Factor Tab then you can see an option to require MFA for the FusionAuth Admin UI Application. You will likely want to enable application specific trust as well.

Currently, FusionAuth lambdas cannot call the API without including an API key in the code — there’s no built-in secret manager for this yet (feature request).

Alternative approaches:

Webhook filtering (recommended)
Use the user.login.success webhook to check if the user is linked to an IdP, and reject the login by returning a non-200 response. This avoids storing API keys in lambdas, but adds an extra network call to each login.

Store link data in user.data
Push IdP linking info into a custom user.data.links[] field so it’s accessible in most lambdas without needing an API call. You’ll need a process to keep this data current.

You can remove claims from the SAML response using a SAML v2 populate lambda. For example:

samlResponse.assertion.attributes['firstName'] = null; samlResponse.assertion.attributes['lastName'] = null;

Attach this lambda to your SAML Identity Provider configuration for that application.

Documentation: SAMLv2 Response Populate Lambda

First check out the information you are getting from the docker log. Look at the log from the spin up and search for "kickstart." Was the container able to find the kickstart.json file? (In this case yes.)

If the kickstart file was found, continue searching through the log for a potential error in the running of the kickstart. You might see something like.

fusionauth-1 | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Failed to execute request to [PATCH][/api/user/registration/000000000001] Status [404] fusionauth-1 | Request body: fusionauth-1 | { fusionauth-1 | "registration" : { fusionauth-1 | "applicationId" : "e72dca1d-626c-4f4b-8f36-b7c8c2c0af33" fusionauth-1 | } fusionauth-1 | } fusionauth-1 | 2025-07-02 05:14:05.177 PM ERROR io.fusionauth.api.service.system.kickstart.KickstartRunner - Error response: fusionauth-1 | null

This will let you know there was an error and you need to resolve it. In this specific case, The PATCH request should have been a POST. Once that was changed, the kickstart ran fine.

Yes—using FusionAuth access tokens to secure partner-facing APIs is a solid approach. The key is ensuring the tokens contain the right claims to enforce proper authorization for your endpoints.

Separating partners into a different tenant or application can improve security and simplify management. Different tenants fully isolate users and tokens, but would require duplicating application configs. Alternatively, you could keep partners in the same tenant and distinguish them via roles, claims, or separate applications.

If partners are accessing APIs server-to-server, the client credentials grant (Entities in FusionAuth) is the correct choice. Be sure to carefully scope each partner’s access to avoid over-permissioning.

More on these topics:

API Authorization with FusionAuth Tenants Overview JWT Anatomy Authorization Models

Yes—you can safely add a fourth custom URL. The “replace” label appears because the system expects you to submit the entire list of domains each time. To avoid losing any URLs, make sure all four domains—including your existing three—are entered in the form before you submit. Only custom domains omitted from the list will be removed.

More details here:
Updating Custom Domains

Yes! FusionAuth stores MFA details on the user object, and you can search for users with MFA enabled using Elasticsearch queries.

For example, in the Admin UI’s User search, you can run:

_exists_:twoFactor

This returns all users with at least one MFA method configured. You can also perform similar searches via the User Search API to build custom reports. For more details on searchable user fields and Elasticsearch queries, see:

User Fields Reference User Search with Elasticsearch

This is definitely an uncommon scenario, so there’s no out-of-the-box flow documented for it, but here’s one way to handle it:

Create a second Google IdP: FusionAuth supports only one native Google IdP, but you can set up an additional Google connection as a generic OpenID Connect (OIDC) IdP. This second IdP can request the elevated scopes you need for email access. See the OIDC docs here: OpenID Connect IdP in FusionAuth. Trigger reauthentication: When a user opts into the email client feature, redirect them through the second IdP’s OAuth flow to acquire the elevated scopes. This effectively escalates their session without forcing all users through additional authentication unnecessarily.

This approach allows you to avoid reauthentication for users who don’t need the extra scopes while supporting a higher-privilege flow for users who do.

Great question—this often causes confusion.

In FusionAuth, logging in after a Forgot Password flow is tracked as ONE_TIME_PASSWORD. That’s because, technically, FusionAuth uses a one-time password during that process. For example, if you look at the Change a User’s Password API, it returns a one-time password token. On the hosted pages, FusionAuth automatically consumes this token to sign the user in immediately after they reset their password via the forgot password link in their email.

So even without traditional OTP or MFA configured, these login events can appear as ONE_TIME_PASSWORD due to password reset flows.

Good question—it’s a common challenge.

By default, the email verification flow breaks the OAuth/PKCE context because the user leaves the registration page to check their email and clicks a verification link. FusionAuth can’t continue the OAuth flow automatically from that email link, which is why your hard-coded redirect URI fails without the required OAuth code.

A better solution is to switch your email verification strategy from Clickable Link to Form Field (under Tenant → Email → Email Verification → Verification Strategy). With this approach, users stay on the original registration page, enter the verification code from their email, and the OAuth/PKCE flow remains intact—including the authorization code. This enables seamless redirecting back into your app after verification.

If you’re creating and registering users for an application at the same time, remember to also check the app-level registration verification settings under:
FusionAuth Admin UI → Applications → Edit Application → Registration tab.

More details are in the docs: Registration Email Verification

You’re correct that user_support_manager is the right role, but it has a limitation: it can only remove MFA devices if the manager has the user’s MFA code or recovery codes. Only admins can disable MFA without those.

If you want to remove MFA without needing a code, you’d need to use the User API to clear the user’s MFA data. Also, confirm that both support managers have the same role assigned under their registrations in the FusionAuth application. Check this under each user’s Source tab in the Admin UI under registrations.roles.

More details:

Update a User via API

FusionAuth Admin UI Roles

Yes, you can localize social login buttons, but it requires customizing your theme.

In the Theme Helpers file, locate the macro for each IdP button—for example, the Google button macro (starting around line 409). Change the text like this:

From:

<div class="text">${identityProvider.lookupButtonText(clientId)?trim}</div>

To:

<div class="text">${theme.message('google-login')}</div>

Then, define google-login in your Theme → Messages bundles for each supported language. Repeat the same process for the Apple button macro (starting around line 363).

This allows the social login button text to display localized strings based on the user’s selected language.

This error usually means FusionAuth doesn’t have the public key it needs to verify the JWT signature.

Make sure you’ve imported the public key that Keycloak uses to sign tokens into Settings → Key Master in FusionAuth. Check whether your JWT includes a kid (Key ID) claim. If it does, the key you import into Key Master must have a matching Key ID. You can confirm the Key ID after importing by clicking the view (🔍) icon next to the key.

Once the correct key is imported and matches the kid from the JWT, FusionAuth will be able to verify the token’s signature.

FusionAuth doesn’t currently support setting a default IdP for an application or automatically forcing logins through an IdP. You’re welcome to submit a feature request on our GitHub issues page.

If all your users share the same email domain, you could try Managed Domains to route them to the correct IdP.

Another option is to place a proxy in front of FusionAuth. The proxy could inspect incoming requests and append the idp_hint before forwarding traffic to FusionAuth. You can learn more about using a proxy setup here.