--- 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 --- # Changes due to the MFA enforcement # Changes due to the 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 Changes due to the Multi-factor Authentication enforcement This guidance details the changes introduced with the Multi-factor Authentication (MFA) enforcement as part of the Australia release and subsequent upgrades like Yokohama and Zurich. It explains how MFA enforcement impacts user login experiences, administrative configuration options, and changes occurring during upgrades. Show full answer Show less ## Key Features * **Integration Impact:** MFA enforcement does not affect integrations. * **User MFA Enrollment and Enforcement:** * Users already enrolled in MFA continue to be challenged during local login. * Users not yet enrolled receive a 30-day exemption period post-Yokohama upgrade to self-enroll in MFA. * After the exemption period, MFA becomes mandatory for login; failure to enroll blocks access. * After 90 days from enforcement, MFA is mandatory for all first-time logins without a grace period. * Administrators can configure exemption periods and enforcement settings. * **Authentication Scenarios:** * **Local Authentication without MFA:** Users prompted to enroll with a 30-day window. * **Local Authentication with MFA:** Users continue normal MFA challenges without grace periods. * **Single Sign-On (SSO) Users:** No change or MFA enforcement impact on login experience. * **Conditional MFA Policies (e.g., network-based):** Existing MFA policies remain effective post-upgrade. * **Upgrade to Zurich Specific Changes:** * If MFA policy enforcement was disabled and authentication contexts existed, a fix script activates MFA enforcement and resets related properties. * The script disables prior policies by assigning inactive placeholders and resets MFA enrollments, requiring users to re-enroll. * Administrators may need to reassociate custom policies to authentication contexts after upgrade. * Logs and upgrade history entries can confirm changes applied during upgrade. * **Administrative Guidance:** * Review and adjust MFA Context Policies and enforcement properties to align with business needs. * Use default exempted groups or add additional exemptions as needed. * Monitor post-upgrade logs for fixmfaenforcement entries to verify changes. ## Key Outcomes ServiceNow customers can expect enforced MFA for all local logins after configured grace periods, ensuring strengthened security. Administrators gain control over exemption periods and policy conditions to tailor MFA enforcement to organizational requirements. Upgrade processes may reset some MFA settings, necessitating user re-enrollment and policy reassociation, which administrators should plan for to minimize disruption. Information about the changes that are expected due to the MFA enforcement. MFA enforcement changes that are expected as follows: * No impact on integration. * Users who have already enrolled MFA continue to be challenged with MFA during local login. * If a user has not set up MFA yet, after the Yokohama upgrade, they'll be initially exempted from undergoing MFA for a certain period during which they can enroll MFA. * If the user fails to self-enroll, then they have MFA enforced on the completion of the exemption period (default 30 days) and must set up MFA. * After 90 Days, MFA will be enforced by default. There will be no self-enrollment period for first-time logins after 90. Administrators can configure this period. {#changes-mfa-enforcement__ul_qxd_cfz_3dc} As an administrator, you can prepare for the MFA enforcement based on the following: * Review the MFA Context Policy configuration and adjust the policy conditions according to your business requirements. * Add the exempted group provided by default, if there are any other users who must be exempted. * Review the MFA Enforcement Properties and adjust based on your requirements. To learn more, see [MFA enforcement properties](https://www.servicenow.com/docs/IzAaWbvNVoxABtkyrA3KOw "Configure the properties for MFA enforcement from Yokohama and upgrade to Yokohama."). {#changes-mfa-enforcement__ul_ryq_kfz_3dc} ## MFA enforcement scenario after 30 days of the MFA enforcement {#changes-mfa-enforcement__example_pth_4s3_jdc} * Scenario 1 for Acme Corp: In the instance, if the user doesn't have an active MFA policy. Imagine Sarah uses local authentication to access an instance. On upgrading to the Yokohama release during login, a message to enroll in MFA is displayed. There's 30 days to complete this setup. If Sarah doesn't complete the setup, after 30 days, the account requires MFA to log in, and won't be able to access it until MFA is set up. * Scenario 2 for Acme Corp: In the instance, Anita was already MFA along with local authentication. Anita continues to require MFA without the 30-day self-enrollment window. * Scenario 3 for Acme Corp: In the instance, Olivia uses Single Sign-On (SSO) for authentication. There's no impact on the login experience, and Olivia isn't enforced for MFA. * Scenario 4 for Globex Corp: In the instance, if a user already had an MFA policy requiring - MFA for all local login attempts outside the company's trusted network. On upgrading to the Yokohama or a later release, MFA enforcement behavior for user logins remain the same. {#changes-mfa-enforcement__ul_u3n_rs3_jdc} ## Changes on upgrade to Zurich {#changes-mfa-enforcement__section_zurich_upgrade_changes} When you upgrade to Zurich, a fix script runs if both of the following were true before the upgrade: * The glide.authenticate.auth.policy.enabled property was set to `false`. * A Pre or Post Authentication Policy Context was configured. {#changes-mfa-enforcement__ul_zurich_upgrade_trigger} The script makes the following changes: * Sets the Default Policy of the context to Deny Policy. See [Authentication policy contexts](https://www.servicenow.com/docs/0NUvigqMNrjQzghg~OU2ZA "Use authentication policy contexts to determine how and when your instance enforces authentication policies.") for what each option means. * Points the context to an inactive placeholder policy, Demo Post Auth policy or Demo Pre Auth policy, in place of the policy you configured. * Sets glide.authenticate.auth.policy.enabled to `true`. * Sets glide.authenticate.multifactor to `true` and rewrites several glide.authenticate.multifactor.\* properties. See [MFA enforcement properties](https://www.servicenow.com/docs/IzAaWbvNVoxABtkyrA3KOw "Configure the properties for MFA enforcement from Yokohama and upgrade to Yokohama."). * Schedules a job that deletes existing MFA enrollment data. Users must enroll in MFA again. {#changes-mfa-enforcement__ul_zurich_upgrade_changes} The result depends on the instance. An upgrade can change a Production instance and leave a Sub-production instance unchanged if the Sub-production instance already had glide.authenticate.auth.policy.enabled set to `true`. After the upgrade, a policy you configured can stop being enforced. For example, an IP allow list might stop applying to SSO logins. Re-associate your policy with the context to restore it. To confirm what the upgrade changed, search the system log for fix_mfa_enforcement. You can also check Upgrade History for `z_fix_mfacontext_upgrade`.