ServiceNow Mobile Experience: Security and Access Design

Mobile access to ServiceNow raises security questions that desktop access does not: a phone can be lost, it may sit off the office network, and cached data lives on the device. This guide covers mobile role design, sign-in and device compliance, offline data, segregation of duties, monitoring and mobile-specific threats.

Mobile access to ServiceNow changes the security questions rather than adding a few: a phone can be lost, the network is not the office network, and cached data lives outside the instance. This page works through role-based access for mobile, authentication and device compliance, offline data and caching, segregation of duties, monitoring and audit trails, mobile-specific threats and their mitigations, and how to classify what a phone may see before writing any mobile access rule.

Role-Based Access Control for Mobile

Mobile users should have restricted access to sensitive data compared to desktop users. Define roles that specify what data and functions are available from mobile. Typical approach: restrict mobile users to read-only access to most data; allow limited create and update for specific record types (incidents, tasks); and prevent access to sensitive data (payroll, health records, executive information).

Implement this through ServiceNow roles and field-level access controls. Create a mobile role that grants limited permissions. Assign mobile users to this role. Use field-level access control to hide sensitive fields from mobile users (e.g., salary, social security number, medical information). Test the mobile interface to ensure only intended data is visible and users cannot bypass restrictions through APIs.

Decisions: should mobile users have full access (same as desktop) or limited access? Full access is more functional but higher risk. Limited access is more secure but more restrictive. Most organizations choose limited access for high-sensitivity data, full access for operational data.

Authentication and Device Compliance

Mobile authentication should require multi-factor authentication. Mobile users authenticate with username and password plus a second factor (time-based one-time password, push notification approval, or biometric). This prevents unauthorized access if a device is stolen and someone has the password.

Device compliance checks: verify that the mobile device meets security requirements before allowing access. Checks might include: device has a password, device has mobile device management (MDM) software installed, device has encryption enabled, device has not been jailbroken (iOS) or rooted (Android). If a device fails compliance, deny access or restrict to read-only.

Implement this through Mobile Device Management integration with ServiceNow. Configure conditional access: if the device is compliant, allow full access; if it is not compliant, restrict access or require a stronger second factor. If a device becomes non-compliant (user disables device password, for example), access is revoked until compliance is restored.

Offline Data and Caching

Mobile users may lose network connectivity and need to continue working. Mobile Experience can cache data locally on the device so users can continue working offline. The application syncs cached changes back to the server when network connectivity is restored. However, caching sensitive data on a device increases risk: if the device is lost, an attacker could potentially access cached data.

Design offline caching carefully: allow caching for non-sensitive data (tickets, tasks, incident status); prevent caching for sensitive data (employee records, financial data, health information). Configure the mobile app to encrypt cached data and delete cached data if the device has not connected to the server within a defined period (e.g., 30 days).

Decisions: which data should be available offline? Start conservatively: only cache data that users need for essential work. Expand caching carefully after you understand the security implications.

Segregation of Duties on Mobile

Some sensitive operations should not be performed from a mobile device even if the user has desktop access. For example, approving high-value expenses, changing user access rights, or deleting records should require approval from a desktop computer with stronger authentication. Implement this by restricting certain record types from mobile: a user with permission to delete records on desktop cannot delete from mobile.

Critical operations should have higher authentication requirements on mobile. For example, if a user tries to approve an expense over a certain amount from mobile, require an additional factor (OTP or push approval) even though they already authenticated to the mobile app.

Monitoring and Audit Trails

Track all mobile access and actions. Mobile activities should be logged identically to desktop activities so you have a complete audit trail. Log: user login from mobile, what data was accessed, what changes were made, when the user logged out. If a mobile user performs an action that triggers a control (e.g., approves a change), the audit log should clearly show the action came from mobile (not just from a particular user).

Monitor for suspicious mobile activity: unusual access patterns (accessing data the user does not normally access), access from unusual locations (a user in the US accessing data from another country in seconds), or access outside normal business hours. Alert security teams if suspicious patterns are detected.

Mobile-Specific Threats and Mitigations

Threat: lost or stolen device with cached data. Mitigation: encrypt cached data, require device password, implement remote wipe (ability to remotely erase data from a lost device), and limit cached data to non-sensitive information only.

Threat: man-in-the-middle attack on a public WiFi network. Mitigation: use certificate pinning (the app only connects to ServiceNow servers with specific certificates) to prevent attackers from intercepting traffic. Use VPN for mobile traffic if available.

Threat: phishing: an attacker sends an SMS or email with a link that looks like ServiceNow login but is actually a phishing page. Mitigation: educate users about phishing; use multi-factor authentication so even if credentials are stolen, access is not possible; implement conditional access to detect suspicious logins and require additional verification.

Access Control Design Summary

Mobile role with restricted permissions defines what data mobile users can access. Multi-factor authentication and device compliance checks authenticate users and verify devices are secure. Offline caching balances functionality (offline work) against security (data on potentially compromised device). Segregation of duties prevents critical operations from mobile. Monitoring and audit trails track all mobile access.

Test the mobile interface for security: verify that users cannot access data their role does not permit; verify that cache is encrypted and cleared; verify that all actions are logged; verify that device compliance is checked on login.

Classifying what a phone may see before writing any mobile access rule

Many mobile security problems start with a rule written for the desktop and inherited by the phone without anyone looking at it. The desktop access controls still apply on a phone, but the context is different: the screen can be read by a bystander, the device may be shared at home, and a copy of a record can outlive the session that created it. A useful design begins by sorting the tables and fields a mobile user could reach into a small number of classes, then deciding for each class what the phone may do with it. This section is for the security architect and the ServiceNow administrator who will turn those decisions into roles and rules.

A classification matrix for mobile access

Use the matrix below as a starting structure. The classes are deliberately few, because a design with a dozen classes is hard to test and tends to be configured inconsistently. Merge classes until each one has a single answer in every column.

The matrix does not replace the access control list. It tells the administrator which rules to write and which tests to run. A table that sits in no class should be treated as restricted until someone classifies it, because an unclassified table is a common route by which sensitive fields reach a phone.

Session length and re-authentication

Session length is a design decision with both a security cost and a usability cost, and both belong in writing. A long session suits a technician who moves between jobs all day, but it also means a stolen phone that is already open stays signed in. Decide three things: how long a session may stay idle, the longest period before a fresh sign-in is required whatever the activity, and which actions force a fresh check even inside a live session. Approval of spend and changes to access rights usually sit in the last group. Record the chosen values in the design so a later administrator does not loosen them to answer a complaint without review.

A procedure for a lost or stolen device

1. Log the report with the time, the user and the device identifier, and mark the user’s mobile sessions for revocation immediately.
2. Revoke the device registration and any active tokens, then confirm in the session log that no new sign-in from that device is accepted.
3. Review the audit trail from the last known sign-in, paying particular attention to approvals and changes to records.
4. Ask the user to change the account password and confirm that the second factor is registered only to a device they still hold.
5. Record what the device could have reached, so the incident note states the exposure precisely rather than in general terms.

Negative tests matter more than success tests

A test showing that a mobile approver can approve a request proves very little. The useful tests try to do what a restricted user should not be able to do. Run each one from a real phone, with the account set to the mobile role, and record the outcome. Include attempts through the list view, the search box, a direct link inside a notification and a saved report. A restriction that holds on one path and fails on another is still a failure.

Keep the set small enough to run before every release, and fold the most relevant items into the testing checklist rather than keeping a second list. Start with one negative case for each restricted table, one for each approval type that requires a step-up, and one for a session that has passed its idle limit.

Signs the design is holding

The access review shows no mobile user holding rights that were not granted on purpose. Negative tests fail at the first attempt and pass after the fix. Where the audit trail records the channel of each action, an approval made from a phone can be told apart from one made at a desk. When an administrator can explain, from the classification matrix, why a given table is or is not visible on a phone, the design is doing its job.

When not to open a process to mobile at all

Some processes do not belong on a phone, even for users who hold the desktop rights. Bulk changes, access administration and edits to the approval chain itself are examples. Keeping them at the desk is a legitimate control, and it costs little, because the mobile user can still raise the request and leave the desktop approver to complete it.

Frequently asked questions about mobile access rules

Does a desktop access rule automatically protect the same data on a phone?

It protects the data only where the rule covers the path the phone uses. A rule written against a form may not reach a list, a related record or a notification link, so each path needs its own check in the negative tests.

Does turning off offline caching remove the device risk?

It removes the risk of stored data on the device, but it does not address a stolen phone with an active session. Session length and step-up checks still matter with caching switched off.

Can contractors use personal phones for the same tasks as employees?

Often they should have a narrower set of tasks and a managed profile on the device. The answer depends on the contract and the classification of the data, so settle it with the data protection lead before access is granted.

Should a mobile approval ever skip the second factor?

Only where the approval is low risk and the organization has accepted that risk in writing. For most approval types the second factor should remain, because an approval is the action a stolen session would most want to take.

Next step

The mobile service experience article gives general background, and it is worth reading before the mobile role is drafted.