--- sourceDocument: Australia Platform security sourceDocumentLink: https://www.servicenow.com/docs/r/australia/platform-security Release : - australia ft:locale : - en-US ft:publication_title : - Australia Platform security ft:clusterId : - psec bundleId : - psec workflow : - Platform --- # Troubleshooting MFA enforcement # Troubleshooting Multi-factor Authentication enforcement {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Troubleshooting Multi-factor Authentication enforcement ServiceNow enforces Multi-factor Authentication (MFA) by default for non-SSO logins starting with the Yokohama release to enhance security and reduce breach risks. MFA enforcement is governed by a default MFA policy activated during or after the Yokohama upgrade. This guidance helps ServiceNow customers troubleshoot issues related to MFA behavior changes, login failures, and policy enforcement after upgrades. Show full answer Show less ## Troubleshooting Tools and Logging Customers can utilize several logs and debug options to investigate MFA problems: * **System Logs:** Accessible via *All \> System Log \> System Logs*. * **Node Logs:** Found under *All \> System Logs \> Utilities \> Node Log File Browser*. * **HAR Logs:** Useful for analyzing MFA debug information. To receive detailed MFA debug information, enable debug properties such as: * glide.webauthn.debug.enabled * glide.log.defaultlogdebug * glide.authenticate.policy.debug * glide.authenticate.hybridusertracking.debug ## Common MFA Issues and Resolutions * **User unable to login with second factor:** Reset MFA for the user and delete their old records from *usermultifactorauth* , *sysuserpubliccredential* , and *sysusermultifactorsetup* tables. * **Admin unable to login with second factor:** Another admin can reset the blocked admin's MFA. If unresolved, contact ServiceNow Support. * **Error during MFA setup or validation:** * For TOTP apps, ensure device and instance times are synchronized within ±30 seconds. * For Email, verify user notifications, outbound email configuration, and user setup in the *sysuser* table. * For SMS, ensure SMS service providers like Twilio are correctly configured and active, and the user's mobile number is accurate in *sysuser*. * **MFA enforcement issues after Zurich upgrade:** * Check system logs for *fixmfaenforcement* and upgrade history for *zfixmfacontextupgrade*. * Review defaultpolicy values and Pre/Post Authentication Policy Context records. * Verify properties *glide.authenticate.auth.policy.enabled* and *glide.authenticate.multifactor*. * **Integration accounts appearing in enforcement table:** Integration accounts making API calls must be marked as Web Service Access Only in Security Center or marked as Interactive if not intended for API use. Troubleshooting information due to the MFA enforcement. ServiceNow enforces MFA by default post-Yokohama upgrade and making it mandatory for non-SSO logins (users performing login with only username and password or LDAP based authentication) to ensure a better security posture and reduce the risk of breaches. MFA enforcement is carried though a MFA policy that is activated by default from Yokohama or upgrade to Yokohama. Following are some of the troubleshooting task that you can perform if there's any change to the MFA behavior: * Debug using the troubleshooting tools * Navigate to the Log location and Debug properties * Understand the MFA scenarios based on your users experience while using MFA * Understand the MFA issue due to upgrade from a previous release {#troubleshoot-mfa-enforcement__ul_mvw_5pp_rdc} ## Debug MFA {#troubleshoot-mfa-enforcement__section_gsl_lqp_rdc} Use any of the following tools or a combination to understand the debug information: * System logs or Node logs. * HAR logs to analyze the debug logs for the MFA. {#troubleshoot-mfa-enforcement__ul_fcl_rqp_rdc} ## Log location and Debug properties {#troubleshoot-mfa-enforcement__section_xnz_lqp_rdc} Navigate to the following location to know more about logs: * For system logs, navigate to AllSystem LogSystem Logs. * For node logs, navigate to AllSystem LogsUtilitiesNode Log File Browser. {#troubleshoot-mfa-enforcement__ul_ytq_vqp_rdc} The system debug logs and instance node logs are required for the debug purpose. Following are the debug properties that are required to be enabled: * `glide.webauthn.debug.enabled` * `glide.log.default_log_debug` * `glide.authenticate.policy.debug` * `glide.authenticate.hybrid_user_tracking.debug` {#troubleshoot-mfa-enforcement__ul_mjj_crp_rdc} ## MFA issue based on scenarios {#troubleshoot-mfa-enforcement__section_wh5_mqp_rdc} Scenario 1: User is not able to login using any of their second factor : Reset the MFA for the your users and delete the old user records from the following tables: * `user_multifactor_auth` * `sys_user_public_credential` * `sys_user_multi_factor_setup` {#troubleshoot-mfa-enforcement__ul_yzj_grp_rdc} Scenario 2: Admin is not able to login using any of their second factor : Another user with admin access can reset the MFA for any blocked admin user. If still the issue exist, reach out to ServiceNow Support. Scenario3: Error observed during the MFA Setup or Validation : Check the warning "Associated Error Codes/Warning: Your 6-digit verification code is incorrect. Try again with the correct code". : Perform the following steps: * In case of TOTP Authenticator App, if the date and time of the Authenticator MFA device and instance are not in sync (±30 sec), then the TOTP code is not accepted. Verify the device and instance date and time. * In case of email, configure the user level notification, outbound email configuration, and user correctly in the `sys_user` table. * In case of SMS, configure the Twillio or other SMS service provider integration correctly and set to active. Verify if the user's mobile number is configured correctly in the `sys_user` table. {#troubleshoot-mfa-enforcement__ul_a1k_grp_rdc} Scenario 4: MFA is not enforced, or a policy stopped applying, after an upgrade to Zurich : Check the following: * Search the system log for fix_mfa_enforcement. * Check Upgrade History for `z_fix_mfacontext_upgrade`. * Check the `default_policy` value and the policy on the Pre and Post Authentication Policy Context records. * Check the `glide.authenticate.auth.policy.enabled` and `glide.authenticate.multifactor` properties. {#troubleshoot-mfa-enforcement__ul_zurich_upgrade_debug}For the changes the upgrade makes, see [Changes due to the Multi-factor Authentication enforcement](https://www.servicenow.com/docs/oerSmoZiJQ7zeOMge5SS8g "Information about the changes that are expected due to the MFA enforcement."). Scenario 4: An integration account appears in the enforcement table : Integration accounts that aren't marked as Web Service Access Only and make API calls appear in the enforcement table. In Security Center, select the account and choose Enable Web Service to convert it to a web service access only account, or Mark as Interactive if it isn't supposed to make API calls. For more information, see [Multi-factor Authentication enforcement](https://www.servicenow.com/docs/rQa25DTfTu2AZYPEpGaIlg "Enforcement of MFA for non-SSO logins to ServiceNow from the Yokohama release."). *[\>]: and then