Action Required: Reviewing ServiceNow Basic Authentication Account Security

Swathi_S · 4 hours ago

Recently, some ServiceNow customers may have started seeing a new platform banner from 06/03/2026

This banner appears when ServiceNow identifies accounts that are using, or may be impacted by, Basic Authentication. The update is intended to strengthen instance security by reducing unmanaged or unnecessary Basic Auth usage, especially for accounts used by integrations, APIs, scripts, or service accounts.

ServiceNow’s Basic Auth documentation confirms that Basic Authentication is still a supported authentication method for certain web service scenarios, but ServiceNow has also introduced newer controls such as API authentication policies and REST API access policies to help customers better restrict inbound API access by authentication type.

This banner appears when ServiceNow identifies accounts that are using, or may be impacted by, Basic Authentication. The update is intended to strengthen instance security by reducing unmanaged or unnecessary Basic Auth usage, especially for accounts used by integrations, APIs, scripts, or service accounts.

ServiceNow’s Basic Auth documentation confirms that Basic Authentication is still a supported authentication method for certain web service scenarios, but ServiceNow has also introduced newer controls such as API authentication policies and REST API access policies to help customers better restrict inbound API access by authentication type.

What is Basic Authentication?

Basic Authentication is a username/password-based authentication mechanism commonly used by external systems to connect to ServiceNow APIs.

Typical examples include:

REST API integrations
SOAP integrations
Legacy scripts or schedulers
External monitoring tools
Middleware or ETL tools
Service accounts used by third-party systems
Older automation jobs using static credentials

The concern with Basic Auth is that it relies on reusable static credentials. If those credentials are exposed, reused, or not rotated properly, they can become a security risk. OAuth 2.0, certificate-based authentication, API policies, and other modern controls provide stronger governance and better alignment with enterprise security practices. ServiceNow OAuth allows clients to access resources using tokens rather than sending login credentials with each request.

What changed?

ServiceNow has introduced a Basic Auth restriction/security update that allows administrators to review affected accounts and decide how each account should behave when enforcement begins.

From the Basic Auth Restriction page, administrators are asked to review the Identified Users table and choose one of the following decisions for each account.

Available decisions for identified users

1. Maintain current login

This option allows the account to continue using both:

Basic Auth API login
UI login

When this option is selected, the user is granted the following role:

snc_basic_auth_api_access

This means Basic Auth access will continue for that account when enforcement begins.

This option should be used carefully and only when there is a confirmed business or technical dependency.

2. Revoke Basic Auth API login

This option blocks Basic Auth API login but still allows normal UI login.

Use this when the user should continue accessing the ServiceNow UI but does not need Basic Auth access for integrations or API calls.

This is a good option for normal interactive users who were identified but do not truly need API Basic Auth access.

3. Convert to Web Service Access Only

This option allows Basic Auth API login but blocks UI login.

This is usually the preferred temporary option for true service accounts that are only used by integrations.

With this option:

The account cannot log in to the ServiceNow UI.
Basic Auth can continue for API usage.
No additional roles are assigned automatically.
The account behaves like a web service-only account.

This is useful when an integration still needs Basic Auth temporarily, but the account should not be used interactively.

4. Apply default from system property

This option applies the global default decision configured in the system property:

glide.authenticate.basic_auth.restriction.default_decision

This can be useful if your organization wants a standard decision applied to newly identified users during the tracking period.

However, for production instances, I recommend reviewing critical accounts individually rather than relying only on the default.

How enforcement works

Once enforcement is enabled, Basic Authentication requests are blocked unless the requesting account matches one of the allowed conditions.

Based on the Basic Auth Restriction page, Basic Auth requests are allowed if the account:

Has Web Service Access Only enabled
Presents a valid MFA one-time password
Has the snc_basic_auth_api_access role

If none of these apply, Basic Auth requests can fail once enforcement starts.

Important system properties and controls

The page references the following key configuration areas.

Feature toggle

glide.authenticate.basic_auth.restriction.active

This controls whether the Basic Auth restriction feature is active on the instance.

If unchecked, no enforcement occurs, regardless of the enforcement property.

This appears to be positioned as an emergency disable option to stop the feature without changing the other configuration decisions.

Enforcement toggle

glide.authenticate.basic_auth.restriction.enforce

This controls whether enforcement is active.

When unchecked, the instance appears to be in a tracking or monitoring mode. Accounts using Basic Auth are recorded, but requests are not blocked.

When checked, Basic Auth requests are blocked unless the account is allowed by one of the configured decisions.

Default decision property

glide.authenticate.basic_auth.restriction.default_decision

This controls the default decision applied to new rows in the Basic Auth Exception table during the tracking period.

Per-row decisions in the Basic Auth Exception table override this default.

Why am I seeing this banner?

You are seeing this banner because ServiceNow has detected that action may be required on your instance.

This usually means one or more accounts have been identified as using Basic Auth or being subject to the new Basic Auth restriction review process.

The banner is not necessarily an error. It is a warning/action item asking administrators to review the impacted accounts before enforcement begins.

Recommended approach for administrators

Do not enable enforcement immediately without reviewing the identified accounts.

A safer approach is:

Step 1: Open the Basic Auth Restriction page

Navigate to:

All > Basic Auth Restriction

Review the message, current settings, default decision, feature toggle, and enforcement toggle.

Step 2: Review the Identified Users table

Open the Identified Users table from the link on the page.

For each account, confirm:

Is this a real user or service account?
Is it used by an integration?
Which system owns the integration?
What APIs or endpoints does it call?
Is it used by a MID Server, external scheduler, ETL job, monitoring tool, or vendor connector?
Can it be migrated to OAuth or another modern authentication method?
Does it need UI login?

Step 3: Classify each account

A practical classification model is:

Account type Recommended decision

Normal employee/user account	Revoke Basic Auth API login
Confirmed service account still using Basic Auth	Convert to Web Service Access Only
Critical integration that cannot be changed immediately	Maintain current login temporarily or Web Service Access Only
Unknown account	Investigate before enforcement
Unused/inactive account	Disable account or revoke Basic Auth

Step 4: Prioritize migration away from Basic Auth

Where possible, migrate integrations from Basic Auth to:

OAuth 2.0
Certificate-based authentication
API Authentication Policies
REST API Access Policies
Scoped API access controls

ServiceNow API Authentication Policies evaluate API authentication requests based on policy conditions and allow or deny access depending on matching criteria. REST API access policies can also restrict inbound REST APIs based on authentication type and filter criteria.

Step 5: Validate in sub-production first

Before enforcing this in production:

Enable tracking in DEV or TEST.
Review identified users.
Test all inbound integrations.
Validate REST/SOAP calls.
Confirm vendor integrations.
Confirm MID Server behavior if applicable.
Coordinate with integration owners.
Create a rollback plan.

Step 6: Plan enforcement

Only enable enforcement after:

Identified users are reviewed.
Exceptions are approved.
Business owners are notified.
Critical integrations are tested.
Migration plans are documented.
A support window is planned.

Suggested governance model

For enterprise environments, I recommend treating this as a small security remediation project rather than a simple admin configuration change.

Create a tracking sheet with the following columns:

Field Purpose

User/account name	Identified account
Account type	Human, service account, vendor, integration
Business owner	Who owns the account
Technical owner	Who supports the integration
Source system	External system calling ServiceNow
Authentication method	Basic Auth, OAuth, certificate, etc.
Decision	Revoke, maintain, WSAO, default
Risk level	High, medium, low
Migration needed	Yes/No
Target date	Migration or remediation date
Validation status	Pending, passed, failed
Notes	Dependencies or exceptions

Best practices for service accounts

For any account that must temporarily continue using Basic Auth:

Use a dedicated service account.
Do not use a named employee account.
Set the account as Web Service Access Only where possible.
Apply least privilege roles.
Remove unnecessary roles.
Rotate the password.
Store credentials securely.
Document the integration owner.
Monitor usage.
Plan migration to OAuth or another modern method.
Avoid long-term exceptions unless formally approved.

What could break if enforcement is enabled too early?

If enforcement is enabled without proper review, the following may fail:

Inbound REST integrations
SOAP integrations
External scripts
Scheduled jobs from external systems
Vendor connectors
Monitoring integrations
ETL/data export jobs
Legacy automation using username/password
Custom applications calling ServiceNow APIs

The most common symptom will be authentication failures such as HTTP 401 or failed API calls.

Conclusion

The Basic Auth Restriction banner is an important security action item. It gives administrators time to review accounts that use Basic Authentication and decide whether those accounts should continue, be restricted, or be converted to Web Service Access Only.

The safest path is to treat this as a controlled remediation activity:

Review identified users.
Classify each account.
Revoke unnecessary Basic Auth access.
Convert service accounts to Web Service Access Only where appropriate.
Migrate integrations to OAuth or stronger authentication methods.
Test thoroughly before enabling enforcement.

This update is a good opportunity to clean up legacy integrations, reduce static credential risk, and align ServiceNow API authentication with modern security standards.

References

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3025707

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB3055080