---
sourceDocument: Brazil Platform security
sourceDocumentLink: https://www.servicenow.com/docs/r/platform-security

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Platform security

ft:clusterId :

    - psec

bundleId :

    - psec

workflow :

    - Platform


---

# Limit basic authentication restriction allowed users

# Limit basic authentication restriction allowed users {#ariaid-title1}

Release version: Brazil  
Updated September 10, 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 Limit basic authentication restriction allowed users

Theglide.authenticate.basicauth.alloweduserssystem property in ServiceNow specifies a list of user sysids exempt from the Basic Authentication Restriction gate, allowing them to bypass multi-factor authentication (MFA) when using Basic Auth.
It is designed for narrowly-scoped integration accounts that cannot meet MFA requirements and do not possess roles listed in theallowedrolesproperty.
Show full answer Show less  
This property contains a comma-separated list of sysids and operates unconditionally, meaning any user listed will always bypass MFA enforcement without triggering logging or review mechanisms. The default value is empty, so no users are exempt unless explicitly added by an administrator.

## Key Features

* **Unconditional MFA bypass:** Users listed bypass the Basic Auth restriction gate without any MFA or time-based one-time password (TOTP) requirements.
* **Precedence in authentication checks:** This exemption runs before enforcement-date logic and per-account review in the Basic Auth Exception table.
* **Admin control and configuration:** Administrators add sysids manually through the system properties list (`/syspropertieslist.do`), ensuring only dedicated integration accounts with documented business justification are exempted.
* **No logging or further review:** Matches are never logged as exceptions and permanently lose MFA protection for Basic Auth API access.
* **Security considerations:** Because the bypass is permanent and unconditional, attackers obtaining an exempt account's password can authenticate without MFA, posing a high security risk (CVSS score 8.1).
* **Dependency requirements:** The plugin `com.snc.integration.multifactor.authentication` must be active, and the property only takes effect if `glide.authenticate.basicauth.restriction.active` is true.

## Practical Guidance for ServiceNow Customers

* Use this property exclusively for dedicated integration accounts that cannot use MFA, ensuring each entry has a strong business justification.
* Regularly review and validate all sysids in this property to avoid stale or unnecessary exemptions that could weaken security.
* Understand that removing a sysid from the list does not block access outright but subjects the user to the standard MFA enforcement and review processes.
* Be aware that entries are identified only by sysid, which does not indicate the associated user account, so careful documentation is important.
* Use this property cautiously due to the high-security risk of permanent MFA bypass on API access.  
The glide.authenticate.basic_auth.allowed_users property defines specific user accounts that bypass the Basic Authentication Restriction gate without multi-factor authentication.
This system property contains a comma-separated list of user sys_ids exempt from the [Basic authentication restriction](https://www.servicenow.com/docs/DtVq0Y888SZu2DXEdYVpYg "Basic authentication restriction is a security feature that controls which accounts can use basic authentication on a ServiceNow instance. Administrators can review identified users and assign per-account decisions before enforcement begins.") gate. When restriction is active, any interactive-login user whose sys_id appears in this list can authenticate through Basic Auth without multi-factor authentication or time-based one-time
password. This user check runs unconditionally, before enforcement-date tracking logic and before any per-account review in the Basic Auth Exception table. A user match is never logged as a tracked exception and always bypasses the
gate regardless of whether enforcement is enabled.

The out-of-box value is empty, so no account is exempted unless an administrator explicitly adds one. This property is intended for narrowly-scoped integration accounts that cannot satisfy multi-factor authentication requirements and
do not hold a role listed in the allowed_roles property.

To configure this property:

1. Navigate to /sys_properties_list.do on the instance.
2. Ensure the glide.authenticate.basic_auth.allowed_users property contains only sys_ids for dedicated integration accounts with a documented business justification. Remove any account that no longer requires a standing MFA exemption for Basic Auth API access.

## More information {#sc-limit-basic-auth-restriction-allowed-users__section_more_info-limit-basic-auth-restriction-allowed-users}

{#sc-limit-basic-auth-restriction-allowed-users__table_property_details-limit-basic-auth-restriction-allowed-users__entry__2}

| Attribute | Description |
|-|-|
| Configuration name | glide.authenticate.basic_auth.allowed_users |
| Configuration type | System Properties (/sys_properties_list.do) |
| Data type | String (comma-delimited list of sys_ids) |
| Recommended value | \<Empty\> or limited to specific, individually-reviewed dedicated service accounts |
| Default value | \<Empty\> |
| Fallback value | \<None\> |
| Category | [Authentication](https://www.servicenow.com/docs/SZIHG9SfxVh2_gyMf2ec2Q "The authentication category covers the main elements of modern authentication to confirm an entity and its claims are authentic and correct, resistant to impersonation and prevent interception of passwords.") |
| Security risk | * Severity score: 8.1 * CVSS score: High * Security risk details: Any user sys_id added to this property receives a permanent, unconditional bypass of the Basic Authentication Restriction gate for that one account. This is not a temporary tracking-mode allowance. Unlike an account left to the default review flow, a listed sys_id is never logged and never subject to further review. That account permanently loses multi-factor authentication protection on its Basic Auth API access. An attacker who obtains that account's password through phishing, credential stuffing, or a prior breach can authenticate directly against the API without satisfying a second factor. Entries are added by sys_id rather than username. A stale entry can silently persist and continue exempting an account long after the original justification for adding it is gone. Nothing in the property's own value indicates which account it refers to. {#sc-limit-basic-auth-restriction-allowed-users__ul_security_risk-limit-basic-auth-restriction-allowed-users} |
| Functional impact | This property takes effect for users not already allowed through an earlier check. Earlier checks include WSAO accounts, oauth_token requests, an active TOTP or multi-factor authentication session, or the allowed_roles list. Because this property ships empty, any populated entry is always a deliberate administrator action, never an inherited default. Removing a sys_id from this list does not deny that account access outright. Affected users fall through to the same allowed_roles check and enforcement-date tracking-mode review flow as any other basic-auth user. There is a review safety net before actual denial takes effect. Administrators should periodically re-validate every sys_id in this list against a live user record. Confirm each is still a legitimate, currently-needed integration account rather than a stale holdover. A bare sys_id gives no indication of which account it names. |
| Dependencies and prerequisites | Plugin com.snc.integration.multifactor.authentication must be Active. No effect unless glide.authenticate.basic_auth.restriction.active is true. |
[ ]

{#sc-limit-basic-auth-restriction-allowed-users__table_property_details-limit-basic-auth-restriction-allowed-users}