Multi-Factor Authentication (MFA) Enforcement FAQSummary Table of Contents MFA Enforcement Requirements – What and Why What is MFA?Why is the MFA enforcement mandate?Why is it important to enable MFA? Why is ServiceNow requiring MFA?What is the MFA requirement for existing customers?What is the MFA requirement for new customers? MFA Enforcement Scope: Which user, login, and environment types require MFA?Is MFA required for Single-Sign-On (SSO) logins?Is MFA required for external users (users with snc_external role)?Is MFA required for Mobile App logins?Is MFA required for sub-production and test environments?Is MFA required for developer instances?Is MFA required for API authentication/integrations?Will there be any impact on the clone setup process due to MFA?Will there be any impact on the update set retrieval due to MFA?Will there be any impact on RPA bots accessing ServiceNow instances?Is MFA required for OAuth-based integrations?Is MFA required for on-prem, self-hosted and regulated market environments? MFA Enforcement Timeline When will MFA be enforced?How can I adjust the MFA enforcement timeline?How will the end-users be informed about this upcoming change?How can I turn off the message displayed to end-users about completing the MFA setup when they log in?How can I turn off the message displayed to admins about the MFA enforcement?I have already defined the MFA policy using adaptive authentication based on my organization's security needs in the instance. Will this mandate impact my instance? Different MFA Types What types of verification methods are available for MFA?Can a user set up multiple MFA factors/verification methods?What steps do users need to perform to complete the MFA setup?Can I limit SMS and Email OTP-based MFA to only certain users?Our users do not have a mobile phone where they can set up an authenticator app. How can these users enable MFA?As an end-user, how can I set up MFA? MFA Exemption How can the MFA mandate be relaxed for specific users?How can the MFA mandate be relaxed for certain roles?How can the MFA mandate be relaxed for specific groups?How can the MFA mandate be relaxed for trusted networks?How can the MFA mandate be relaxed for trusted locations?Can I control how frequently MFA is enforced?How does MFA work for accounts shared by multiple users? MFA Reset I have lost the authenticator app setup. How can I reset?How can we prevent admins from lockout due to MFA? MFA Adoption How can I check the count of local logins not undergoing MFA? 1. MFA Enforcement Requirements – What and Why What is MFA? MFA, or Multi-Factor Authentication, is a security process that requires users to provide two or more forms of verification before they can access an account or system. Think of it as an extra layer of protection beyond just a password. For example, if you log in to your bank account online, MFA might ask you to enter your password (something you know) and then confirm a code sent to your phone (something you have). This way, even if someone else knows your password, they wouldn’t be able to access your account without also having your phone. Using MFA makes it much harder for unauthorized users to get into your account, helping protect your personal information and keeping your account more secure. Why is the MFA enforcement mandate? We're enforcing the MFA mandate to make sure your accounts and data are as secure as possible. Cyber threats are constantly evolving, and passwords alone are no longer enough to protect against unauthorized access. With MFA, even if someone guesses or steals your password, they still need a second form of verification to log in, like a code from your phone or a fingerprint scan. This extra layer helps block most unauthorized attempts and keeps your information safer. By making MFA a default setting, we're reducing the risk of security breaches and protecting your account by default—giving you greater peace of mind without needing to make any additional security choices. Why is it important to enable MFA? Why is ServiceNow requiring MFA? Enabling MFA is essential because it significantly strengthens your account security. Passwords alone are often not enough to fully protect your account. They can be guessed, stolen, or exposed in data breaches, putting your personal information at risk. With MFA, even if someone learns your password, they still can’t access your account without that second form of verification. We're requiring MFA to help protect you from these kinds of threats. It’s a simple but powerful way to reduce the chances of unauthorized access to your account. By requiring MFA, we're making sure that every account has a strong layer of protection, reducing security risks for you and everyone on the platform. What is the MFA requirement for existing customers? For existing customers upgrading their instance to the Yokohama or a later release: If the instance doesn’t already have the adaptive authentication – MFA context policy turned on, we’ll automatically enable a default MFA policy. This means that all internal users (users who do not have snc_external role) logging in with local or LDAP authentication will need to set up MFA within 30 days of their first successful login. During this time, users can log in normally but will see a message at the time of login to enroll in MFA. After 30 days, MFA will be required by default, and users won’t be able to log in without completing the MFA setup. Example scenario 1 for Acme Corp: Currently, the instance does not have an active MFA policy. Imagine Sarah uses local authentication to access an instance. Upon upgrading to the Yokohama release, she’ll see a message about enrolling for MFA when she logs in. She has 30 days to complete this setup. If she doesn’t, after 30 days, her account will require MFA to log in, and she won’t be able to access it until MFA is set up. Example scenario 2 for Acme Corp: In the same instance, Anita was already using MFA along with local authentication. She will continue to require MFA without the 30-day self-enrolment window. Example scenario 3 for Acme Corp: In the same instance, Olivia uses SSO for authentication. There will be no impact on her login experience, and she will not be enforced for MFA. Example scenario 4 for Globex Corp: The Globex ServiceNow instance already had an MFA policy requiring MFA for all local login attempts outside the company’s trusted network. Upon upgrading to Yokohama or a later release, MFA enforcement behavior for user logins will remain the same as before the upgrade. What is the MFA requirement for new customers? For any instance provisioned with the Yokohama or a later release, MFA will be active by default for all internal users (users who do not have snc_external role) logging in with local or LDAP authentication from day one. This means internal users who log in without SSO must set up and use MFA from their first login. 2. MFA Enforcement Scope Which user, login, and environment types require MFA? From the Yokohama release onwards, with the new default secure MFA policy, MFA will enforced for All users except those who have snc_external roleAnd when they are performing username and password-based local or LDAP authentication.This policy will be enforced for all customer instances, including production, sub-prod, and test instances, that did not already have an active MFA policy before the upgrade. The instance admin can modify the enforcement scope by changing the MFA context policy, policy criteria, or policy conditions. Is MFA required for Single-Sign-On (SSO) logins? No. With the default secure MFA policy, MFA is not required for SSO (SAML, OIDC, Certificate Based Authentication etc.) logins. Customers can collaborate with their Single Sign-On (SSO) provider (Identity Provider, or IdP) to enforce Multi-Factor Authentication (MFA) on the IdP side. If enforcing MFA on the IdP side is not feasible, customers also have the option to enable the ServiceNow platform's MFA for SSO logins by following the instructions provided here. Is MFA required for external users (users with snc_external role)? No. With the default secure MFA policy, MFA is not required for users having the snc_external role. Admins can modify this behavior and enforce MFA for external users by updating the MFA policy conditions.External users already undergoing MFA before the upgrade to Yokohama or later release will continue to have MFA.External users can visit their profile and self-enroll for MFA. Is MFA required for Mobile App logins? Yes. The MFA policy will be applied to both web and mobile app logins with username and password-based non-SSO logins. Is MFA required for sub-production and test environments? Yes. If an active MFA policy does not exist on an instance before upgrading to Yokohama or later versions, MFA will be enforced for all customer instances, including production, sub-production, dev, and test environments. Is MFA required for developer instances? Yes. MFA will be enforced for all developer instances that are on Yokohama or later release versions. Is MFA required for API authentication/integrations? No. From Yokohama or a later release, MFA is only required for username and password-based interactive user logins. This means API authentication with basic auth will work without requiring MFA. We strongly recommend customers use alternative secure API authentication methods such as OAuth or mTLS. Will there be any impact on the clone setup process due to MFA? No, the clone setup process will continue to work with username and password and will not require MFA. Will there be any impact on the update set retrieval due to MFA? No, the update set retrieval will continue to work with username and password and will not require MFA. Will there be any impact on RPA bots accessing ServiceNow instances? If the RPA bot uses the interactive username and password login to access the ServiceNow instance, it will be forced to undergo MFA. Admins can add RPA bot accounts to the MFA Exempted User Group if they want to relax MFA for RPA bot accounts. Is MFA required for OAuth-based integrations?The OAuth Resource owner password credential (ROPC) will work with a username and password without requiring MFA. However, for the Authorization code grant type, MFA will be required as part of the user login flow before giving the OAuth consent.Is MFA required for on-prem, self-hosted and regulated market environments? Yes, the MFA mandate applies to all instances, including on-prem, self-hosted, and instances hosted in regulated market environments. 3. MFA Enforcement Timeline When will MFA be enforced? According to the MFA policy, eligible users who have not completed the MFA setup will have a 30-day self-enrollment period. This is controlled using the system property glide.authenticate.multifactor.self_enrolment_period . The property's default value is 30 days. It can be updated to a maximum of 90 days. All internal users (users who do not have snc_external role) logging in with local or LDAP authentication will need to set up MFA within 30 days of their first successful login. During this time, users can log in normally but will see a message at the time of login to enroll in MFA. After 90 days of upgrading to Yokohama or a later release, if an internal user (a user without the snc_external role) logs in with local or LDAP authentication for the first time, they will be required to use MFA immediately. These users will not have the 30-day MFA self-enrollment window. This period is governed by a system property: glide.authenticate.multifactor.enforcement.max_relaxation_period. The maximum value for this property is 270 days. How can I adjust the MFA enforcement timeline? Admins can provide a smaller or larger self-enrollment window by updating the value of the property glide.authenticate.multifactor.self_enrolment_period. Setting this property value to 0 means users must complete the MFA setup after their first login attempt with local or LDAP login after upgrading to Yokohama or a later release. The maximum duration of the self-enrollment window can be 90 days. Property value set higher than 90 will be treated as 90.By updating the value of the property glide.authenticate.multifactor.enforcement.max_relaxation_period, the admin can decide how many days post upgrade to the Yokohama or a later release a user will get the MFA self-enrollment window. How will the end-users be informed about this upcoming change? End users performing local or LDAP authentication (who will be enforced with MFA) will see an information message after logging in. The same message will also be available when users visit their profile. Platform User Profile Employee Service Center User profile This message will not appear for non-admin users performing SSO logins. Users with the admin role will see a different information message after a successful login, regardless of the authentication method used for logging in. This message will continue to be displayed until one of the admin users acknowledges the update by setting the below property value to true. glide.authenticate.multifactor.enforcement.acknowledged How can I turn off the message displayed to end-users about completing the MFA setup when they log in? Admins can update the value of the below system property to false to turn off the MFA enrolment information message shown to end users upon login. glide.authenticate.multifactor.enforcement.show_user_info_message How can I turn off the message displayed to admins about the MFA enforcement? The information message regarding MFA enforcement shown to admin users upon login will stop appearing when one of the admin users acknowledges it by updating the value of the below system property to true. glide.authenticate.multifactor.enforcement.acknowledged I have already defined the MFA policy using adaptive authentication based on my organization's security needs in the instance. Will this mandate impact my instance? No, if the instance already has an active Adaptive authentication—MFA context policy, we will not enforce the new default secure MFA policy. Suppose the instance had MFA property enabled (glide.authenticate.multifactor), but the MFA policy was not active. In that case, the default secure MFA policy for enforcing MFA for all internal users (users who do not have snc_external role) performing username and password-based local or LDAP login will be enabled. 4. Different MFA Types What types of verification methods are available for MFA? ServiceNow platform, out of the box, supports these verification methods. PasskeyTOTP-compliant Authenticator apps such as Google Authenticator, Okta Verify, Microsoft Authenticator, Authy, DUO, etc.Biometric Authenticator (FIDO2) such as Windows Hello, Apple Touch ID, Face ID, android fingerprint sensor etc.Hardware Security Keys (FIDO2) such as YubiKey, Thetis, etc.Email OTPSMS OTP - Multi-factor authentication with SMS com.snc.authentication.sms_mfa plugin installation and factor configuration are required to enable SMS OTP-based MFA. Can a user set up multiple MFA factors/verification methods? A user can enroll for multiple MFA factors by visiting their user profile. For example, users can enroll their laptop’s biometric authenticator, use their mobile phone as a passkey, and have an authenticator app setup. What steps do users need to perform to complete the MFA setup? Please refer to MFA setup – Product Doc for more details on setup steps. Can I limit SMS and Email OTP-based MFA to only certain users? Admin can set up MFA factor policies for email and SMS OTP-based MFA factors to limit these factors to specific user groups/roles. Please refer to the production documentation here for more details. Our users do not have a mobile phone where they can set up an authenticator app. How can these users enable MFA? From the Xanadu release onwards, users can use a Biometric authenticator, passkeys, FIDO2 hardware security keys, and email OTP-based MFA without requiring an authenticator app set up on their mobile phone. As an end-user, how can I set up MFA? Please refer to MFA setup – Product Doc for more details on setup steps. 5. MFA Exemption How can the MFA mandate be relaxed for specific users? As part of the Yokohama release, we have added a new user group, “MFA Exempted User Group.” Based on the default condition we have added to the MFA policy, any user who is a member of this group will not be enforced for MFA. So, if you want to exempt a user from undergoing MFA, you can add the user to the “MFA Exempted User Group”. Step 1: Search for “MFA context” in the navigator. The Step-Up MFA Policy associated with the MFA context record should be “Enforce MFA for non-SSO logins” Step 2: Under the “Policy Input” related list, click on the “Is a member of MFA exempted group” filter criteria record. Step 3: Click on the “MFA Exempted User Group” in the groups list. Step 4: Add users to this group as a member to exempt them from MFA enforcement. Note: if you have a different policy associated with the MFA context, you can add “Is a member of MFA exempted group” filter criteria to your policy and modify the policy conditions to exempt users of this group from MFA enforcement. How can the MFA mandate be relaxed for certain roles? As part of the Yokohama release, we have added an empty new role filter criterion, “Has MFA exempted role”. We have also added conditions to the MFA policy to exempt users who have a role(s) part of exempted role criteria from MFA enforcement. Step 1: Search for “MFA context” in the navigator. The Step-Up MFA Policy associated with the MFA context record should be “Enforce MFA for non-SSO logins” Step 2: Under the “Policy Input” related list, click on the “Has MFA exempted role” filter criteria record. Add the roles you want to add to the condition. You can add multiple roles using the OR operator. Note: if you have a different policy associated with the MFA context, you can add “Has MFA exempted role” filter criteria to your policy and modify the policy conditions to exempt users having exempted roles from MFA enforcement. How can the MFA mandate be relaxed for specific groups? As part of the Yokohama release, we have added a new user group, “MFA Exempted User Group.” Based on the default condition we have added to the MFA policy, any user or group who is a member of this group will not be enforced for MFA. So, if you want to exempt a group from undergoing MFA, you can add the group to the “MFA Exempted User Group”. Step 1: Search for “MFA context” in the navigator. The Step-Up MFA Policy associated with the MFA context record should be “Enforce MFA for non-SSO logins” Step 2: Under the “Policy Input” related list, click on the “Is a member of MFA exempted group” filter criteria record. Step 3: Click on the “MFA Exempted User Group” in the groups list. Step 4: Add the groups you want to exempt from the MFA enforcement to this group. How can the MFA mandate be relaxed for trusted networks? Step 1: Navigate to Adaptive Authentication > Filter Criteria > IP Filter Criteria and create a new criterion to specify a trusted network. You can specify a list of IP ranges or subnets as part of the trusted network. Step 2: Navigate to Adaptive Authentication > Auth Policy Contexts > MFA context and open the policy associated with the context. Step 3: Click the edit button to add the IP Filter Criteria you created in Step 1 to the Policy inputs-related list. Step 4: Modify the policy condition to ensure it is evaluated as false when users are part of the trusted network. Note: if you have a different policy associated with the MFA context, you can add the IP filter criteria created as part of Step 1 to your policy and modify the policy conditions to exempt MFA enforcement on the trusted network. How can the MFA mandate be relaxed for trusted locations? This can be achieved using the Location Filter Criteria that become available when the Zero Trust – Location Based Access (requires an additional subscription) plugin is installed. Please refer to this article for detailed instructions. Can I control how frequently MFA is enforced? We have a checkbox on the MFA validation page to remember a browser. MFA is not enforced on the remembered browser The duration specified by this system property. glide.authenticate.multifactor.browser.fingerprint.validity The default value of the property is 8 hours. This duration can be increased by up to 24 hours. Similarly, using the glide.authenticate.multifactor.remember.browser.default system property, the default value of the checkbox can be set to true. You can navigate to Multi-factor Authentication > Properties and adjust these four properties to control the remember browser feature. How does MFA work for accounts shared by multiple users? Single accounts shared by multiple users are a security risk. It is not recommended to share an account with multiple users. 6. MFA Reset I have lost the authenticator app setup. How can I reset? We recommend that users enroll in multiple factors so they are not locked out due to MFA. For example, users can have the TOTP authenticator app, passkey, and email OTP-based MFA. If users are unable to use any of the enrolled MFA factors, the system administrator can reset the MFA by following these steps. Step 1: Clearing the Authenticator app setup: Navigate to Multi-factor Authentication > User Multi-factor SetupSearch for the user in the tableDelete the record associated with the user Step 2: Clearing the FIDO2 authenticators and passkeys Navigate to Multi-factor Authentication > Web Authentication > User Public CredentialsSearch for the user in the tableDelete the records associated with the user Step 3: Clearing other multi-factor setups related to the user Navigate to Multi-factor Authentication > User Recent Used FactorsSearch for the user in the tableDelete the records related to the user In case no one, including the admin, can access the instance, the admin can perform a self-service MFA reset using a catalog item available at our Now support portal https://support.servicenow.com/now How can we prevent admins from lockout due to MFA? We recommend that admins enroll for multiple MFA factors so they are not blocked from accessing the instance. In case no one, including the admin, can access the instance, the admin can perform a self-service MFA reset using a catalog item available at our Now support portal https://support.servicenow.com/now 7. MFA Adoption How can I check the count of local logins not undergoing MFA? Admin can navigate to Security Center > Security Console > Security Metrics Under metrics for users, click on Local logins not protected by MFA.