Skip to main content

Mass Reactivation

In rare occasions, especially after updates of the Android operating system, selected device binding parameters - which are saved on the SSMS - can change. Those parameters are used to identify a distinct device and are central to the security anchors of the AST protocol. Is the device binding broken, the app can not login and has to be activated anew. In case this is happening for a larger group of users, there is an option to address this situation with a automatic and transparent (re-)activation on the SSMS.

Enable Mass Reactivation on SSMS

Navigate to App Security Management > Versions > Mass Reactivation: Here you have an overview of all active and inactive Mass Reactivation configurations/triggers. These will automatically initiate a Mass Reactivation whenever broken device bindings are detected. You will have to add a separate configuration for every device architecture that you use. For Android this would mean that you need one for ARMv8, ARMv7 (and x86 for tests on emulators).

Mass Reactivation on SDK Side

Whenever a mass reactivation is initiated, all affected devices will reactivate upon the next login. The app developer does not have to react to any special events. The SSMS will create a new device entry in replacement for the old broken activation, therefore users will have to set a new device name.

Make sure to check if a device name is set upon every successful login, you can do so by using the GetDeviceInformationEvent.

Example flow for affected devices when mass reactivation was triggered:

SSMS Login

Set/Get Device Information