Common ServiceNow Instance Security and Access Control Mistakes and How to Avoid Them

Instance security mistakes in ServiceNow are usually ordinary habits, such as granting roles too widely, sharing admin accounts and skipping access reviews, that build up over time. This page sets out each mistake, the symptom it produces, its root cause and the fix that holds.

Uncontrolled Role Proliferation and Permission Creep

A common mistake in instance security is creating too many roles or granting permissions too broadly. Over time, organizations accumulate hundreds of custom roles, each with overlapping permissions, making it impossible to understand who has access to what or why.

The symptom is that user access becomes difficult to manage: requests for role assignments go to multiple people because no one knows which role grants needed access, or users request new roles when existing roles would suffice. Security reviews become arduous because auditing hundreds of roles is impractical.

The root cause is usually adding roles reactively without a governance model. When a user needs a new permission, a new role is created rather than reusing or adjusting existing roles.

Establish a role governance model. Define a standard set of roles aligned with business functions: user, power user, analyst, administrator. Document what each role can access and modify. Use role-based menus and dashboards to hide features users do not need. When new access is requested, first check if an existing role grants the access. Create new roles only when no existing role fits.

Conduct annual role reviews: audit all roles, identify which are unused, and consolidate overlapping roles. Document each role’s purpose and who should hold it. This keeps the role inventory manageable.

Insufficient Access Reviews and Stale Permissions

Users change roles or leave the organization, but their access often does not change automatically. A common mistake is granting access without formally removing it later, leading to former employees retaining access or employees keeping access from previous roles.

The symptom is that access reviews reveal that users have permissions they no longer need, or former employees can still log in. The root cause is usually that access removal is not systematized: it depends on someone remembering to remove access when an employee leaves.

Implement systematic access reviews. Quarterly, audit all active users and verify that their role assignments match their current job function. For users who changed roles, remove old roles. For users leaving the organization, disable their account the same day they leave.

Integrate your ServiceNow instance with your HR system: when an employee is marked as terminated in HR, automatically disable their ServiceNow account after a grace period for data export. This prevents accidental access by former employees.

Excessive System Administrator Accounts

System administrator access is powerful and dangerous if misused. A common mistake is granting admin access too broadly, or creating shared admin accounts where multiple people know the credentials.

The symptom is that admin actions cannot be audited to individuals: shared admin accounts make accountability impossible. The root cause is usually that organizations want many people to have admin-level access for operational reasons, and creating separate admin accounts feels administratively burdensome.

Minimize the number of system administrator accounts. Create admin accounts only for those who genuinely need unrestricted access: the primary platform administrator and perhaps one backup. For operational work that seems to require admin access, investigate whether you can accomplish it with targeted elevated roles instead.

Implement MFA (multi-factor authentication) for all admin accounts. Log all admin activities and review admin logs regularly for suspicious activity. Separate admin access from day-to-day work: admins should use a standard user account for normal tasks and only switch to the admin account when admin-level changes are needed.

Inadequate Audit Logging Configuration

Audit logs are your evidence trail for security reviews and incident investigations. A common mistake is leaving audit logging in default configuration, which logs too much or too little, or does not capture the information you need.

The symptom is that during security review or incident investigation, needed information is not available in the audit logs. The root cause is usually that logging was not configured with your specific compliance or security needs in mind.

Configure audit logging explicitly. Log authentication events (logins, password changes), role changes, and modifications to sensitive configurations. Do not log every database change (this generates volume and performance impact) but do log changes to security-sensitive tables.

Retain audit logs for a documented period based on your compliance requirements. Archive older logs to external storage so the active system is not burdened by massive log tables. Regularly review audit logs for anomalies: unusual access patterns, failed login attempts from unusual locations, or bulk data exports.

Weak or Default Credentials

ServiceNow instances ship with default credentials, and some organizations fail to change them. A common mistake is leaving default administrator accounts active with unchanged credentials, or using weak password policies.

The symptom is unauthorized access to the ServiceNow instance. The root cause is usually incomplete initial setup: default credentials were used for setup but never changed to production credentials.

On initial setup, immediately change default credentials. Establish a strong password policy: minimum length, complexity requirements, password history to prevent reuse. Require password changes periodically on an interval your security policy sets.

Disable default accounts that are not needed. Service accounts (used for integrations) should have unique credentials, not shared passwords. Rotate service account credentials periodically.

Inadequate API and Web Service Authentication

ServiceNow instances often integrate with other systems via APIs. A common mistake is using weak authentication for API calls: hardcoded credentials, credentials in configuration files in plain text, or overly permissive API key scopes.

The symptom is that API credentials are leaked or compromised, allowing unauthorized access. The root cause is usually that API authentication was not designed with security in mind.

Use OAuth 2.0 or similar modern authentication for API access. Do not embed credentials in code or configuration files. Use ServiceNow’s credential management to store API keys securely. Implement API rate limiting and access controls: API keys should have minimal necessary permissions, not blanket access.

Rotate API credentials periodically. Monitor API usage: unusual patterns of API calls could indicate compromised credentials. Disable or rotate credentials immediately if you suspect they are compromised.

Failure to Implement Multi-Factor Authentication

User accounts are vulnerable to password compromise or brute-force attack. Multi-factor authentication adds a second factor (something you have or know) to make unauthorized access much harder. A common mistake is not implementing MFA, or implementing it only for admin accounts and not for regular users.

The symptom is account compromises that might have been prevented by MFA. The root cause is usually that MFA was seen as difficult to deploy or support.

Implement MFA for all accounts, starting with high-risk accounts (admins, users with sensitive data access). Use ServiceNow’s MFA capabilities or integrate with an identity provider that provides MFA. Educate users on how to use MFA and how to recover access if they lose their second-factor device.

Finding a mistake that has already been made

Prevention advice assumes a clean start, which few instances have. Many teams discover access problems during an audit or after a user reports seeing data they should not. The first job is to find the grants that were made outside the intended process, because those are the ones nobody approved and nobody remembers. Start from the role assignment records and compare the grant date with the approval trail. A grant with no matching request is the strongest candidate for a mistake, and it is usually the fastest one to contain.

Containing a suspected overly broad role

Containment should be quick and reversible, and the access recertification article is the companion read on making retain decisions clear. Removing a role from someone who needs it stops work, so take an approach that protects both security and operations.

1. Write down the role, the holders and the date each grant was made before changing anything.
2. Ask the holder’s manager to confirm which tasks the role is needed for in the last month.
3. Remove the role from holders who cannot be tied to a current task, and keep a record of each removal.
4. Where a holder needs part of the role, create a narrower role for that task and move the holder to it.
5. Check the access control rules that depended on the removed role, because they may now block or allow more than intended.

A mistake that repeats across releases

If the same grant pattern returns after each cleanup, the cause is the request process rather than the people in it. Typical causes are a request form that offers the admin role by default, a manager who approves whatever is placed in front of them, or a project that grants temporary elevated access and never removes it. Change the process, then clean up the grants, because the reverse order just repeats the cycle. When the request process is the root cause, the service page on access and segregation of duties describes how that redesign is approached.

How do we find roles granted outside the approved process?

Compare the role assignment records with the approved request records for the same period. Any grant without a matching approval should be investigated, even if it looks harmless, because an unapproved grant is itself the control failure.

Is an admin account that signs in through single sign-on still a shared account?

It is shared if several people know its credentials or use it interchangeably. Single sign-on does not fix shared accounts; it only changes how the sign-in happens. Confirm that each admin is a named person.

What should happen when a former employee still has an active session?

End the session and disable the account first, then review what that person could have done in the period before disablement. Use the audit trail for that review, and record the timing so it can be explained later.