--- 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 --- # MFA enforcement timeline # MFA enforcement timeline {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 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 MFA enforcement timeline This document explains the timeline and enforcement process for Multi-Factor Authentication (MFA) setup in ServiceNow instances starting from the Yokohama release and later, including how the enforcement can be customized, communicated, and managed by administrators. Show full answer Show less ## Key Features * **MFA Enrollment Period:** Eligible internal users (without the `sncexternal` role) authenticating via local or LDAP login have a default 30-day self-enrollment period to set up MFA after their first login. This period is controlled by the `glide.authenticate.multifactor.selfenrolmentperiod` system property and can be adjusted up to a maximum of 90 days. * **Immediate MFA Enforcement After Upgrade:** After 90 days of upgrading to Yokohama or a later version, any internal user logging in for the first time via local or LDAP authentication will be required to use MFA immediately, without a 30-day grace period. The timeframe before this strict enforcement is controlled by `glide.authenticate.multifactor.enforcement.maxrelaxationperiod`, which can be set up to 270 days. * **Customizing Enforcement Timeline:** Administrators can modify the self-enrollment window and the post-upgrade relaxation period by updating the respective system properties mentioned above. Setting the self-enrollment period to 0 enforces MFA setup immediately on first login after upgrade. * **User Notifications:** Users authenticating with local or LDAP credentials who are subject to MFA enforcement receive informational messages upon login and within their profile, prompting them to enroll in MFA. These messages are not shown to users authenticating via SSO. * **Administrator Notifications:** Admins receive a persistent informational message about MFA enforcement until one acknowledges it by setting `glide.authenticate.multifactor.enforcement.acknowledged` to true. * **Managing Informational Messages:** Admins can disable end-user MFA enrollment messages by setting `glide.authenticate.multifactor.enforcement.showuserinfomessage` to false, and can stop admin notification messages by acknowledging them as described above. * **Policy Impact:** Existing active Adaptive Authentication MFA policies are not overridden by this default secure MFA policy enforcement. Instances without an active MFA policy but with MFA enabled will have the default secure MFA policy applied for internal users using local or LDAP login. * **Upgrade Effects:** Upgrading to Zurich can delete existing MFA enrollment data under certain conditions (if `glide.authenticate.auth.policy.enabled` was false and a Pre or Post Authentication Policy Context existed), requiring users to re-enroll in MFA. ## Key Outcomes * ServiceNow customers can control the MFA enforcement timeline to balance security needs and user convenience by configuring system properties. * Users receive clear communication about MFA enrollment requirements to ensure compliance. * Administrators retain control over notification management and acknowledgment of MFA enforcement changes. * Existing MFA policies remain unaffected unless inactive, ensuring continuity of security configurations. * Awareness of upgrade impacts on MFA enrollment helps customers plan user communications and enrollment strategies accordingly. FAQ related to MFA enforcement timelines and why it's important. 1. When is MFA enforced?According to the MFA policy, eligible users who haven't completed the MFA setup has a 30-day self-enrollment period. The behavior 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 don't have a `snc_external` role) logging in with local or LDAP authentication must set up MFA within 30 days of their first successful login. During this time, you can log in normally but 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 (user without the `snc_external` role) logs in with local or LDAP authentication for the first time, they'll be required to use MFA immediately. You don't 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. 2. How can the MFA enforcement timeline adjusted? * By updating the value of the property `glide.authenticate.multifactor.self_enrolment_period`, admins can provide a smaller or larger self-enrollment window. Set the property value to 0. The users are required to 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` admin can decide how many days post upgrade to the Yokohama or a later release you get the MFA self-enrollment window. {#faq-mfa-enforcement-timeline__ul_kpy_y1j_jdc} 3. How are end users 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 is available when users visit their profile. {#faq-mfa-enforcement-timeline__table_ypx_dwf_b2c__entry__2} | On the User Profile | On Employee Service Center | |-|-| | | | [Table 1. Enforcement Message] {#faq-mfa-enforcement-timeline__table_ypx_dwf_b2c} This message won't appear for non-admin users performing SSO logins. The admin role will see a different information message after a successful login irrespective of the authentication method used for logging in. This message continues to be displayed until one of the admins acknowledges the update by setting the `glide.authenticate.multifactor.enforcement.acknowledged` property value to true. 4. How to turn off the message displayed to end users about completing the MFA setup when they log in?Admins can update the value of the `glide.authenticate.multifactor.enforcement.show_user_info_message` system property to false to turn off the MFA enrollment information message shown to end users after login. 5. How to turn off the message displayed to administrators about the MFA enforcement?The information message regarding MFA enforcement shown to admin users after login, stops appearing when one of the admins acknowledges it by updating the value of the `glide.authenticate.multifactor.enforcement.acknowledged` system property to true. 6. There's already an MFA policy defined using adaptive authentication based on the security needs of my organization in the instance. Is the policy impacted by the mandate?No, if the instance already has an active Adaptive authentication---MFA context policy, the new default secure MFA policy isn't enforced. If the instance had MFA property enabled (`glide.authenticate.multifactor`) but the MFA policy wasn't active, then the default secure MFA policy for enforcing MFA for all internal users (users who don't have `snc_external` role) performing user name and password-based local or LDAP login is enabled. 7. Does upgrading to Zurich change existing MFA enrollments?Yes, under the conditions in [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."). If `glide.authenticate.auth.policy.enabled` was `false` before the upgrade and a Pre or Post Authentication Policy Context was configured, the upgrade deletes existing MFA enrollment data. Users must enroll in MFA again. {#faq-mfa-enforcement-timeline__ol_pfr_zfz_3dc}