Mobile application security

Medallia Mobile and Medallia Voices employ the following techniques to ensure the security of data:

  • Authentication to identify the user and verify the user has authorization to access the system, and to which data the user may access.

  • Enterprise Mobile Management support, enabling centralized management of security in mobile devices.

  • Secure data storage of the data while on the user's device, and automatic purging of the data when the user signs out (whether by specific user request or forced sign-out).

  • Transportation of data is done via secure HTTPS connections between the device and Medallia Experience Cloud severs.

  • Disablement of risky versions of the application.

Important: Medallia regularly releases updates to mobile apps. These releases include security and functional patches. Medallia expects users to automatically upgrade to each release. If there is a critical security issue, Medallia releases the patch to the app store and then disables old versions of the app. Users then must upgrade before they can use the app.

User authentication

Medallia Mobile and Medallia Voices generally authenticate users using the same technique they use to access Medallia Web reporting, via either username and password, or single sign-on (SSO) authentication. The techniques include:

  • Username and password — These are the same username and password to sign in to Medallia Web reporting.

  • SSO — Single sign-on uses a third-party SAML 2.0 SSO identity provider to verify users with their company SSO credentials. When users start the app, they are temporarily directed to their company's internal SSO sign-in page. Once verified, the user is then redirected back to the app. For more information, see Mobile single sign-on (SSO).
  • PIN/Touch ID — A secondary layer of security that optionally allows to the user to use their device PIN or fingerprint scan to re-access the app after some period of inactivity. This test happens when the user switches back to the app after it has been in the background. If the PIN or scan fails three times, the user must re-authenticate using one of the above techniques. For more information, see Activation and verification with PIN/Biometrics, below.

Activation and verification with PIN/Biometrics

PIN/Biometrics is a secondary layer of security that optionally allows the user to use their device PIN or fingerprint scan to re-access the app after some period of inactivity. This test happens when the user switches back to the app after it has been in the background. If the PIN or scan fails three times, the user must re-authenticate.

PIN and biometrics security

Note the following requirements:

  • The PIN is a 4-digit number.

  • Fingerprint ID is only available on devices capable of scanning the fingerprint.

  • Face biometrics is only available on devices capable of facial-recognition.

  • The PIN or fingerprint scan is stored in a secure keychain on the device, and is never sent to Experience Cloud servers.

  • PINs and biometrics are set per device.

  • Users with multiple devices must create an ID on each device.

  • If multiple users are sharing a device, they cannot use biometrics, since those security methods are for a single users only.

PIN/Biometrics configuration settings

You can select from the following options for the PIN/TouchID security property:

  • Disabled — PIN is not available to users. Default re-authentication techniques are used instead.
  • Optional — Users are prompted to use create a PIN after signing in, but users have the option to skip the prompt and not use the feature.
  • Required — Users are prompted to create a PIN before they can use the app.

Biometrics is an optional addition to PIN security. If PIN is disabled, biometrics is also disabled. However, biometrics can be disabled so only PIN is used, allowing for shared devices.

Important: If a user manually or automatically signs out, user data is wiped including the PIN. This requires the user to set up a PIN again when logging back in.

Inactivity lock timeout

Medallia Mobile also supports an inactivity lock timeout. If the configuration is set to use PIN, upon initial activation users are prompted to create an arbitrary passcode (if this is required, as described above). After the PIN is configured, the PIN/biometric prompt automatically requires validation.You can configure the number of minutes of inactivity before users are prompted to re-verify with PIN or Touch ID, as set in the Minutes before PIN/TouchID authentication property. Set that property to zero (0) to force the user to provide a PIN or Touch ID when the app comes to the foreground.

Important: For strong security, companies should require employees to use inactivity PIN lock, and the timeout duration should be zero (0).

Inactivity and re-authentication

Once signed in, users remain signed in for a period of time defined by the OAuth settings for the mobile app and for the company. After the period expires, the user is signed out and must re-sign in. The default is 30 days. Change the length with the Refresh token lifetime property for the app

Apps may optionally automatically sign out users after some period of inactivity. This is disabled by default. To activate this feature, turn on the Expire refresh token after an idle timeout property. Set the length of idle time with the Refresh token idle timeout property on the same page.

These settings are applied to the app when the user signs in to the app, and remain in effect until the session ends. Changing the configuration does not affect already active sessions.

Note: Forced re-authentication is not supported on Medallia Voices.

Enterprise Mobile Management

Medallia mobile apps provide an extra level of security compliance through interoperation with the most popular Enterprise Mobility Management (EMM) suites. EMM is the set of people, processes, and technology focused on managing mobile devices. As more workers have bought smartphone and tablet computing devices, and have sought support for using these devices in the workplace, EMM has become increasingly significant in addressing the associated security concerns.

Data wipe

Whenever the user logs out of the app, either intentionally or unintentionally such as due to re-authentication failure, the app wipes all of the company's Experience Cloud data from the device.

Important: A data wipe only happens when the app is in the foreground. If the app remains inactive in the background, the data remain (encrypted) on the device until the app is returned to the foreground.

Changes to the user's credentials on Experience Cloud or in the company's SSO service provider can automatically trigger a logout and data wipe when the user attempts to login or re-authenticate. This allows companies to trigger a data wipe of confidential information on the device. For example:

  • If a device is lost or stolen, the company should change the user's Experience Cloud or SSO password, depending on the login method being employed.
  • If an employee leaves, the company should deactivate the Experience Cloud account, and if using SSO, deactivate the user's SSO account.

The following chart summarizes the scenarios, actions, and responses by Medallia mobile apps:

Chart illustrating when to wipe upon access, within some count of minutes, and within some count of days


  • Wipe upon access triggers a logout when the user attempts to login or re-authenticate.
  • Wipe within ## minutes triggers a logout when an SSO re-authentication is attempted. This time period (##) is configurable.
Warning: It is the company's responsibility to provide Medallia with accounts to be deactivated or which require a password change.

Data storage

Experience Cloud stores data on the user's device while the session is active:

  • The session refresh token that allows users to automatically re-authenticate while actively using the app
  • Cached data (Responses, Scorecard, and Ranker Settings data)

All data on the device are encrypted using a key stored in the device's keychain, which is protected by the device OS's keychain protection mechanism. Experience Cloud manages the keys used by the app and Experience Cloud servers.  Medallia is not responsible for keychain security jail-broken devices.

TechniqueData affectedDescription
  • Application session state (refresh token)
  • Settings and profile
  • Responses data
  • (Android only) Ranker and Scorecard data
An SQLCypher extension to SQLLite which uses a 256-bit AES in CBC-mode encryption algorithm. For more information, see
Core Data
  • (iOS only) Ranker and Scorecard data
Standard Core Data using a 256-bit AES in CBC-mode encryption algorithm, with CommonCrypto/CommonCryptor.h. For more information, see
  • Keys to encrypt the data in SQLCypher and CoreData
  • PIN code or fingerprint scan

Protected key value store provided by the OS. This data persists even after uninstalling the app. For more information, see

Data transportation

All communication between the device and Experience Cloud servers is encrypted via HTTPS with certificate pinning using REST API calls. This provides privacy and blocks "man in the middle" attempts to reveal the data.

User devices receive public keys from a third party for authentication. While connecting to the server, the client and server negotiate a private shared key. All communication is based on that shared key. Experience Cloud limits the set of certificate authorities to: RapidSSL, DigiCert, and Thawte root certificates.

Depending on the company the server endpoint is located in the United States, Canada, or European Union.

Manual logout

Manually signing out of a mobile app with the Logout option wipes all app data stored on the device, and forgets the PIN code.