How do you stop a random person from logging into your company's help desk and deleting every open ticket? That's the core problem that user accounts and authentication solve — they make sure the right person gets access and the wrong person gets blocked. For your CSA exam, you must understand exactly how ServiceNow identifies users, what passwords and multi-factor authentication do, and how roles control what each user can see and change.
Jump to a section
A simple way to picture User Accounts and Authentication
Have you ever tried to get into a private event and been stopped by a security guard holding a clipboard?
The clipboard itself is just a list — it doesn't do anything. The guard uses the list to check if you belong. In a big corporation, every employee is like a person trying to enter a different part of the building. The front door is the first check — that's authentication. The guard asks who you are and if you have a badge. If your badge says 'Floor 5' but you try to enter Floor 10, the guard says stop — that's authorisation based on your role.
Now imagine the guard doesn't just check your name — they also check a secret handshake that changes every time you visit. That's multi-factor authentication. Your badge might expire, and they'll send you a new one only if your manager approves — that's a password reset policy.
In this analogy, the guard is the ServiceNow platform checking every click. The clipboard is the list of users. The badge colours and floors correspond to roles and access controls. If the guard loses the clipboard, nobody gets in — that's what happens if the user account database is corrupted. This is exactly how ServiceNow decides who can see tickets, who can close them, and who can change the system settings.
User accounts are the digital identities that let people sign in to a ServiceNow instance. An instance is your company's private copy of the ServiceNow software — think of it as a secured office building full of data. Each account has a unique username and a password. When you type your username and password on the login screen, ServiceNow checks if that combination exists in its user table. The user table is a giant spreadsheet hidden in the database that stores every person who is allowed in.
But just having an account isn't enough. You also need authentication — the process of proving you are who you say you are. The most basic authentication method is a password. But passwords are weak because people share them, write them down, or choose 'Password123'. That's why ServiceNow supports multi-factor authentication (MFA). MFA adds a second check — for example, a code sent to your phone or a fingerprint scan. Even if someone steals your password, they cannot log in without that second factor.
Once you are authenticated, the next question is: what are you allowed to do? That's authorisation. In ServiceNow, authorisation is managed through roles. A role is like a job title that comes with a set of permissions. For example, the 'itil' role might let you create and update incidents, but the 'admin' role lets you change system settings. A user can have multiple roles. Roles are assigned by an administrator in the user record.
Authentication methods determine how users prove their identity. The most common options are:
Local passwords stored inside ServiceNow.
Single Sign-On (SSO), where a separate company system (like Microsoft Entra ID) handles the login and sends a token to ServiceNow saying 'this user is verified'.
Multi-factor authentication (MFA), which requires a second factor like a phone app code, a text message, or a hardware key.
Certificate-based authentication, where a digital certificate on your computer proves your identity without a password.
User accounts also have a state. The three main states are:
Enabled: the account can log in.
Disabled: the account exists but cannot log in — useful for employees who leave but you might need their data.
Locked out: temporary block after too many failed login attempts — prevents brute force attacks where someone tries thousands of passwords.
ServiceNow also has a password policy that you can configure. The policy forces users to pick complex passwords, change them every X days, and not reuse old passwords. You set these rules in the system properties.
Why does this matter to a beginner? Because every single ticket, every configuration item, every report in ServiceNow is locked behind these accounts. If you get user accounts wrong, people cannot work. If you get authentication wrong, hackers get in. The CSA exam asks you to know the difference between local and SSO authentication, the role hierarchy, and how to reset a user's password.
Create a user account
Navigate to User Administration and click New. Fill in the User ID (login name), first name, last name, email, and set the Active checkbox to true. This creates the digital identity in the sys_user table.
Assign a role
Open the user record and scroll to the Roles related list. Click Edit and select the roles you need (e.g., itil, admin). Roles grant permissions — without a role, the user cannot perform any tasks even after logging in.
Set the password
Click the 'Set Password' button on the user record. Enter a new password and confirm it. ServiceNow hashes the password so it cannot be read later. The user must use this password (or SSO) to log in on their first attempt.
Configure authentication method
In System Security > SSO Configuration, set up the identity provider if you want SSO. Alternatively, leave the default local password authentication. For MFA, go to Multi-Factor Authentication and define which users or groups must use a second factor.
Test the account
Log out and log in as the new user. Verify the role permissions work by trying to access a module like Incident. If the login fails, check account status, password expiry, and SSO configuration.
Monitor and audit
Use the Security Operations > User Lockouts module to see locked accounts. Use reports to list which users have which roles. Review logs to detect unusual authentication attempts. Adjust password policies and unlock accounts as needed.
Imagine you are an IT administrator at a company called GreenLeaf Manufacturing. The company has 500 employees. Until now, everyone shared one generic login — 'admin' — to use ServiceNow. The help desk is a mess because nobody knows who made which change. Your boss tells you to fix it.
Here is what you actually do, step by step:
First, you go to User Administration in ServiceNow. You import a CSV file from HR that has every employee's name, email, and department. ServiceNow creates 500 user accounts. You set each account to 'enabled' so they can log in tomorrow.
Next, you set up the password policy. You go to System Security > Password Rules. You set the minimum length to 12 characters, require at least one uppercase letter, one number, and one symbol. You set password expiry to 90 days. You also turn on account lockout after 5 failed attempts.
Then you configure authentication. You decide to use Single Sign-On because the company already uses Microsoft Entra ID for email. You set up the SSO configuration in ServiceNow: you give it the Entra ID metadata URL, test the connection, and turn it on. Now employees log in with their work email and Entra ID password — they never see a ServiceNow login screen.
After that, you assign roles. You create a role called 'help_desk_agent' that includes the 'itil' role plus custom permissions for closing high-priority tickets. You create another role called 'incident_viewer' for managers who only need to read reports. You assign these roles to the user records using the Roles related list. You also set up role inheritance: the 'help_desk_agent' role automatically gets all permissions from the 'itil' role.
Finally, you test. You log in as a new help desk agent, create an incident, and assign it to yourself. You log in as a manager and try to delete the incident — it fails because the manager role doesn't have delete permission. You verify that a locked-out user cannot log in until an administrator unlocks them.
Throughout this process, you use the ServiceNow platform's reporting to check who has which role, and you document every change in a change request. This is exactly the kind of real work a CSA does every day.
The SNOW-CSA exam tests User Accounts and Authentication in several specific ways. You must memorise the difference between authentication and authorisation — authentication proves who you are, authorisation determines what you can do. This is the single most tested distinction.
Here are the exam topics that appear most often:
Password policy configuration: know where to change password rules (System Security > Password Rules). The exam will ask what happens if a user types the wrong password three times — account lockout after the configured threshold.
SSO setup: you need to know that SSO uses a separate identity provider (like Microsoft Entra ID or Okta) and that ServiceNow trusts that provider's authentication. The exam will not ask you to configure SSO step-by-step, but it will ask you what SSO replaces (it replaces local password authentication).
Role inheritance: if Role A inherits from Role B, then a user with Role A gets all permissions from Role B. The exam loves to ask who can perform an action when roles are nested.
User record fields: know that the 'User ID' field is the login name, and that you can search by that field. The 'Active' checkbox controls whether the account can log in.
Account lockout: lockout happens automatically after too many failed logins. An administrator must manually unlock the account — it does not unlock by itself.
MFA: ServiceNow supports MFA through the 'Multi-Factor Authentication' module. You configure which users or groups must use MFA.
Common traps on the exam:
They ask about 'authentication' but give an answer about authorisation. Read every answer carefully.
They give a scenario where a user cannot log in but the account is active. The answer is typically a password issue or SSO misconfiguration, not a disabled account.
They describe role inheritance backwards — make sure you know the direction: the child role gets the parent role's permissions.
They ask 'Which authentication method is most secure?' MFA is the correct answer, not just 'password'.
Key definitions to memorise:
Authentication: verifying identity (who you are)
Authorisation: granting access (what you can do)
SSO: all systems trust one external login
MFA: two or more proofs of identity
Lockout: temporary block after repeated failed attempts
Role: collection of permissions assigned to users
Authentication proves who you are; authorisation determines what you can do — these are two distinct concepts tested repeatedly on the CSA exam.
User accounts have three states: active (can log in), inactive (cannot log in), and locked out (temporarily blocked due to failed attempts).
Role inheritance works downward: a child role automatically gains all permissions from its parent role.
Multi-factor authentication (MFA) adds a second verification step and is the most secure authentication method ServiceNow supports.
Single Sign-On (SSO) delegates authentication to an external identity provider like Microsoft Entra ID, so users log in once and access multiple systems.
Password policies are configured under System Security > Password Rules and control complexity, expiry, and lockout thresholds.
These come up on the exam all the time. Here's how to tell them apart.
Authentication
Proves who you are (identity)
Happens first during login
Examples: password, fingerprint, SSO token
Authorisation
Determines what you can do (permissions)
Happens after authentication
Examples: roles like itil, admin, incident_viewer
Local Password Authentication
Passwords stored inside ServiceNow
Manually manage password resets
Works even if external systems are down
Single Sign-On (SSO)
Authentication handled by external provider (e.g., Microsoft Entra ID)
Users log in once for multiple systems
Requires network connection to identity provider
Role
Controls permissions (what you can do)
Can inherit from other roles
Assigned to users via the Roles related list
Group
Organises users for work assignments
Does not grant permissions by itself
Used for manual assignments, escalations, and notifications
Account Lockout
Temporary block after failed login attempts
Lifts automatically after a configurable time or manually
User can still be active after unlock
Account Disabled
Permanent block set by administrator
Active checkbox set to false
User cannot log in until checkbox is re-enabled
Mistake
If a user account is active, the user can always log in regardless of authentication method.
Correct
An active account only allows login if the authentication method works. If SSO is broken or the password is expired, the account cannot be used even if it is active.
Beginners confuse account state (active/inactive) with authentication success. They assume active = always able to log in.
Mistake
Roles and groups are the same thing in ServiceNow.
Correct
Roles determine permissions (what you can do). Groups are collections of users for routing work (like assigning tickets). A user can be in a group without having a role, and vice versa.
Other systems like Microsoft Entra ID use 'group' to mean both permissions and user grouping. ServiceNow separates these concepts.
Mistake
Once you set up SSO, you cannot use local passwords at all.
Correct
You can configure ServiceNow to allow both SSO and local passwords. SSO can be the default, but local login may remain an option for specific users or administrators.
People assume SSO completely replaces all other login methods, but ServiceNow supports multiple authentication sources simultaneously.
Mistake
Multi-factor authentication requires a smartphone.
Correct
MFA can use a hardware token, a phone call, a text message, or an authenticator app. A smartphone is not mandatory.
Common marketing shows phone-based MFA, leading beginners to think it is the only option.
Mistake
An administrator can see a user's password in the user record.
Correct
ServiceNow stores passwords as hashes (scrambled text). Administrators cannot see the actual password. They can only reset it or force a change.
In many legacy systems, passwords were stored in plain text. Beginners expect the same from ServiceNow.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Open the user record from User Administration, then click the 'Set Password' button. Type the new password and confirm it. The user must change it on next login if you check the 'Force password change' option.
A disabled user has their Active checkbox unchecked — they cannot log in until an administrator re-enables them. A locked out user is temporarily blocked due to too many failed login attempts, and an administrator must manually unlock them.
Yes. You can have SSO for most users and local password authentication for administrators or external contractors. You can also require MFA only for specific roles or groups.
Go to System Security > Password Rules. You can set minimum length, required character types, password history, and expiration period.
Yes. Permissions are cumulative. If one role grants read access to incidents and another grants write access, the user gets both read and write.
Open the user record and scroll to the Roles related list. Every role assigned to that user is listed there. You can also run a report on the sys_user_role table.
You've finished User Accounts and Authentication. Continue through the SNOW-CSA study guide to build a complete picture of the exam.
Done with this chapter?