---
sourceDocument: Australia Mobile Configuration and Navigation
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/mobile
Release :
- australia
ft:locale :
- en-US
ft:publication_title :
- Australia Mobile Configuration and Navigation
ft:clusterId :
- mobile
bundleId :
- mobile
workflow :
- Development, Data and Analytics
---
# Mobile security
# Mobile security {#ariaid-title1}
* Release version: Australia
*
* Updated March 12, 2026
*
*  7 minutes to read
Summarize
 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 Mobile Security
The ServiceNow mobile platform features robust security measures to protect user data and ensure secure interactions between mobile apps and the ServiceNow server.
The apps utilize a native architecture for iOS and Android, transmitting data securely through encrypted channels and OAuth authorization.
Show full answer Show less
## Key Features
* **Data Encryption:** Data in transit is secured via SSL/TLS, while data at rest employs FIPS 140-2 validated encryption methods on both iOS and Android devices.
* **Mobile Authentication:** The platform supports OAuth 2.0 for authentication, integrating multi-provider SSO, MFA, LDAP, and local database logins through AppAuth.
* **Token Management:** Access tokens and refresh tokens are securely stored and managed, ensuring user sessions are maintained without storing passwords.
* **Data Loss Prevention:** Features include copy/paste restrictions, mandatory PIN entry, and attachment blocking on mobile devices to enhance security.
* **Security Testing:** Regular penetration testing is conducted, with results accessible to customers, ensuring continuous security improvements.
## Key Outcomes
By utilizing these security features, ServiceNow customers can expect:
* Enhanced protection of sensitive data during mobile interactions.
* A seamless and secure mobile experience for users accessing ServiceNow services.
* Compliance with security standards through ongoing testing and patching efforts.
* Increased control over mobile app access and data handling, bolstering organizational security measures.
Learn about the security features of the ServiceNow mobile
platform.
## ServiceNow mobile architecture {#mobile-security-landing__section_bgc_rmw_3lb}
ServiceNow mobile apps consist of ServiceNow server
instance and native apps for iOS and Android. The apps use full
native code and are not a hybrid approach. The mobile apps transmit and receive data with the
server across the wireless network.
Figure 1. ServiceNow mobile architecture
## Overview of key features of ServiceNow mobile platform security {#mobile-security-landing__section_fwd_m5w_3lb}
* The mobile apps rely on the secure ServiceNow platform and its APIs to provide a seamless mobile experience to its users.
* App/server interactions are protected through OAuth authorization framework.
* Most of the user interface on the ServiceNow app is driven through meta data delivered by the ServiceNow platform.
* The ServiceNow mobile apps fetch all their data from the ServiceNow platform and store it in a local cache on the app client layer.
* Data that is transferred to and from ServiceNow instances and data that is stored locally is encrypted.
* For iOS apps, ServiceNow uses the OS level FIPS 140-2 validated disk encryption on Core Data, by forcing a device level PIN or Biometrics security. iOS keeps up to date on FIPS-compliant cipher suites with operating system updates.
* For Android apps, ServiceNow uses the SQLCipher SDK. This SDK provides encryption using FIPS 140-2 validated crypto module for all the app data stored in Room DB.
In client version 20.1.0 of Android apps, the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite has been added and support for the below CBC ciphers has been discontinued:
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
{#mobile-security-landing__ul_gpk_5yg_5fc}
In case of any SSL handshake issues due to cipher mismatch, review the supported ciphers on your instance and add one more supported cipher.
Below is the list of supported ciphers on Android:
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
{#mobile-security-landing__ul_igd_gzg_5fc}
{#mobile-security-landing__ul_yyh_fvw_3lb}
{#mobile-security-landing__ul_bnr_n5w_3lb}
## App flow overview {#mobile-security-landing__section_zl5_yrw_3lb}
ServiceNow mobile apps start fetching the initial user experience after a
successful sign-in. The mobile app fetches the metadata to render the landing home screen from
the instance. The app then uses this metadata to render the home screen.
## Data retrieval {#mobile-security-landing__section_i21_dxw_3lb}
Read data
: When a user requests to view information on the mobile app, the following steps occur.
1. The mobile app sends a request to access data from the instance. The request includes the token and any relevant data field needed for the request.
2. The instance receives the request and checks if the token is valid.
3. If the token is valid, the instance directs the request to the relevant API to fetch the information.
4. The instance returns the information to the mobile app.
{#mobile-security-landing__ol_aqw_fxw_3lb}
Downloading documents
: When a user requests to download documents from the app, the following steps occur.
1. The mobile app sends a request to access the document. The request includes the token.
2. The instance receives the request and checks if the token is valid
3. The instance checks the access control list (ACL) rules.
4. If valid, the document is available to view.
{#mobile-security-landing__ol_smd_mxw_3lb}
Write-backs for updating fields
: When a user updates a field in the mobile app, the following steps occur.
1. The mobile app sends the token and the action metadata to the instance. For example, the ID, or the field to update.
2. The instance directs the action based on the relevant API.
3. The instance completes the action and sends a response to the mobile app.
4. Based on the response, the mobile app reflects the field changes and action availability in the UI.
{#mobile-security-landing__ol_br3_zxw_3lb}
Write-backs for attaching files
: When attaching files, the following steps occur.
1. The mobile app prompts the user to attach a file, for example, an image.
2. The mobile app sends the file and token to the instance.
3. The instance places the file based on the relevant API.
4. The instance sends a response back to the mobile app.
{#mobile-security-landing__ol_nc1_fyw_3lb}
## Mobile authentication {#mobile-security-landing__section_vl2_nyw_3lb}
ServiceNow mobile apps support platform authentication using OAuth 2.0.
Authentication mechanisms include multi provider SSO, MFA, LDAP, Local DB, and Digest. ServiceNow mobile apps use an authentication methodology called AppAuth. AppAuth uses
an external mobile browser to log the user in.
Authentication flow
: When a user signs in to an app on their mobile device, the app uses the user's credentials
to negotiate an OAuth Token with the instance. The iOS Keychain stores the
token for iOS devices. Android device use KeyStore. The
keychain encryption is AES 256 in Galois/Counter Mode (GCM).
At first login, the instance gives the user an access token and a refresh token. These
tokens are valid for an amount of time that can be configured on your instance. When a user
opens the mobile app, the client checks to see if the access token is valid. If valid, the
user can continue with the session. If not valid, the client then checks if the refresh token
is valid. If valid, the refresh token is used to fetch a new valid access token for the user,
and the session can continue. If the refresh token is not valid, the user must
reauthenticate.
Access and refresh tokens
:
* The mobile apps never stores the user password.
* The mobile apps do store the client ID, which is necessary for getting the OAuth token as part of the authentication flow.
{#mobile-security-landing__ul_dtb_nzw_3lb}
User termination
: When an administrator deletes or removes a user from the instance, the access token is no
longer valid, and any operation logs the user out.
: Figure 2. Mobile authentication workflow
Multi-provider SSO
: The multi-providers SSO plugin \[com.snc.integration.sso.multi.installer\] provides SAML
authentication support. The login process (AppAuth) uses this plugin to redirect the user to
the IDP (SAML provider) login page when using SAML.
Multifactor authentication
: Users can access the instance via Multifactor Authentication using the MFA plugin
\[com.snc.integration.multifactor.authentication\]. The mobile app directs users to their login
page after selecting their instance in the mobile app.
LDAP
: Use LDAP authentication to access using LDAP credentials. The user sees the same login page
as the local login (DB based), but the back end to the LDAP server deletes the
authentication.
## Data security {#mobile-security-landing__section_hzq_v1x_3lb}
ServiceNow mobile apps use SSL/TLS over-the-air (OTA) communication encryption
for data security. The OAuth authorization endpoints are HTTPS.
Data at rest
: Application preference data such as favorites, home screen, and the mobile navigator items
are stored and cached locally on the device. The mobile apps do not store record data such as
incidents and problems on the device unless your organization has specifically enabled
offline syncing for field service. Record data stored during offline mode is encrypted with
FIPS 140-2 validated modules. (iOS cryptographic modules and SQL Cipher for
Android which uses this cryptographic module for encryption).
: Figure 3. Data at rest
Data in motion
: Data in motion is over a secure SSL/TLS channel and encrypted with FIPS 140-2 validated
modules.
Data loss prevention
: ServiceNow provides data loss prevention features without the need
for the device and application be managed by an enterprise mobility management (EMM) suite.
These features includes restrict copy/paste, enforce PIN, block attachment, and/or blur
functionality.
Restrict copy/paste
: Copy/paste restrictions are defined by a property in the system properties table.
: {#mobile-security-landing__table_mx1_ncx_3lb__entry__2}
| System property field | Value |
|-|-|
| Name | glide.sg.clear_pasteboard_when_background |
| Type | true \| false |
| Value | true |
[ ]
{#mobile-security-landing__table_mx1_ncx_3lb}
Require an app PIN
: Require users to enter a six-digit PIN each time they sign in from their mobile device, or
when the application has been inactive for five minutes. Requiring an app PIN is controlled a
property in the system properties table.
: {#mobile-security-landing__table_i4w_qcx_3lb__entry__2}
| System property field | Value |
|-|-|
| Name | glide.sg.require_mobile_application_pin |
| Type | true \| false |
| Value | true |
[ ]
{#mobile-security-landing__table_i4w_qcx_3lb}
Disabling attachments on a mobile device
: You can configure ACL rule to block attachments specifically on mobile devices. Use the
`isMobile` method to check if a request comes from a mobile device. For
example, you could add an ACL rule for the attachment \[sys_attachment\] table where the read
and write scripted ACLs includes the following check.
:
if( gs.isMobile() ){
answer = false;
}
: You can also add this code to any existing ACL rules you have for the attachment table. If you have multiple attachment ACL rules, all will need to have the Admin override option unchecked.
Enable the blur app option
: Blur the mobile app when not in focus on a mobile device using the following system
property in the system properties table.
: {#mobile-security-landing__table_ikr_ydx_3lb__entry__2}
| System property field | Value |
|-|-|
| Name | glide.sg.blur_ui_when_backgrounded |
| Type | true \| false |
| Value | true |
[ ]
{#mobile-security-landing__table_ikr_ydx_3lb}
Important:
* The glide.sg.blur_ui_when_backgrounded system property is supported on both iOS and Android devices.
* By default, the value for this property is set to false, which turns it off.
* For Android devices, when this property is enabled by setting the value
to true, the following restrictions apply:
* The screen share feature isn't supported and the shared app screen appears black.
* Users are prevented from taking screenshots.
{#mobile-security-landing__ul_abj_dvd_dwb}
These restrictions don't apply to iOS devices when the
glide.sg.blur_ui_when_backgrounded property is enabled.
{#mobile-security-landing__ul_j5q_dxc_dwb}
Penetration testing
: ServiceNow engages a third party to perform penetration testing of
the mobile app. This typically happens annually but sometimes occurs more frequently. The
results of these tests are available to customers. For more detail on security testing, see
[KB0538598: Customer Instance Security Testing \| Policy and
Procedure](https://support.servicenow.com/kb_view.do?sysparm_article=KB0538598).
Security patching
: In the event a security patch is needed, the mobile development team aligns with standard
SDLC properties in order to patch.
User data collection
: The mobile app does not specifically collect any user data.
User transactions or usage within the app is tracked on the ServiceNow instance just as it is on the web. For user credentials, after a user logs in, the mobile
app negotiates an OAuth Token that is stored in the Apple Keychain or the Android Keystore. User credentials are never saved. If the user opts in, the
following information is collected:
* Location
* Access to camera
* Notifications
{#mobile-security-landing__ul_zb3_m2x_3lb}