Unable to disable the Authentication Factors menu item in Application Menus

[George Cutrell]

Platform: Zurich patch4-hotfix3

Context:  Our platform use is specifically targeted to customer service agents via a customized CSM application.  CSM is the only real licensable product on our instances.  No other products are installed.  Users access the instance via a SSO integration with an external IdP.  Besides local access for administrative needs, all end-user access is through SSO and users are provisioned via an LDAP integration.  

As is typical after a family release upgrade, we go in after the fact and disable menu items that are perceived as noise to end users.  No different with Zurich.  However, we are unable to disable the Authentication Factors menu item as it seems to be protected by some protection policy.  I am unable to figure out how to get around that protection policy so that we can disable the menu item.  Has anyone else faced this issue?

[Naveen20]

The "Authentication Factors" module is protected by a Read-only protection policy that ships with the platform's MFA/authentication framework, and Zurich tightened protections on several of these components.

You have two paths forward:

Option 1 (Recommended): Use Navigation Filters instead of disabling the module

Rather than fighting the protection policy, create a Navigation Filter to hide the menu item from your end users. Navigate to System UI > Navigation Filter and create a filter that excludes the "Authentication Factors" module for the appropriate roles. This approach is upgrade-safe, doesn't require touching protected records, and achieves the same end result — your CSM agents won't see it.

Option 2: Clear the protection policy via Background Script

If you specifically need to disable the module record itself, you can use a Background Script (with elevated privileges enabled) to strip the protection policy and then deactivate the module:

var gr = new GlideRecord('sys_app_module');
gr.addQuery('title', 'Authentication Factors');
gr.query();
if (gr.next()) {
    gr.sys_policy = '';  // Remove protection policy
    gr.active = false;   // Disable the module
    gr.update();
    gs.info('Module disabled: ' + gr.sys_id);
}

Be aware: This is a customer modification to an OOB record. Future upgrades/patches may re-enable the protection policy or revert your change. Also note that officially, Read-only protection policies can only be altered by ServiceNow — this background script approach is a community workaround, not a supported method.

I'd strongly lean toward Option 1. Navigation Filters give you the same UX cleanup without the upgrade maintenance overhead.

[George Cutrell]

Thanks Naveen.  I like Option 1 but I don't see System UI > Navigation Filter.  

[Naveen20 · Accepted solution]

Try these

Option 1A: Restrict module visibility by role

The standard way to hide a module from users is by adding a role to it. Since the module record itself is protected and you can't edit it through the UI, use a Background Script (System Definition > Scripts - Background) with elevated privileges to add a restrictive role:

```javascript

var gr = new GlideRecord('sys_app_module');

gr.addQuery('title', 'Authentication Factors');

gr.query();

if (gr.next()) {

gr.sys_policy = ''; // Clear protection policy

gr.roles = 'admin'; // Only admins will see this module

gr.update();

gs.info('Updated module: ' + gr.sys_id);

}

```

This way, only users with the `admin` role will see the Authentication Factors menu item. Your CSM agents won't see it at all.

Option 1B: Before Query Business Rule on sys_app_module

If you'd rather not touch the protected record at all, create a Before Query Business Rule on the `sys_app_module` table that filters out the module for non-admin users:

```javascript

(function executeRule(current, previous) {

if (!gs.hasRole('admin')) {

current.addQuery('title', '!=', 'Authentication Factors');

}

})(current, previous);

```

This is the least invasive option — no protected records modified, upgrade-safe, and easy to maintain. Just be mindful that Before Query BRs on `sys_app_module` run on every navigator load, so keep the logic lightweight.

[Tanushree Maiti]

Hi @George Cutrell ,

Follow this article : How To Modify a file with a Read-only Protection Policy

If above method is not permitted, the only way to modify a read-only protection policy on core ServiceNow application files is to raise a case to ServiceNow Customer Support (HI) to update the policy designation.