Migrating the Airlock 2FA app

The Airlock 2FA solution provides a mobile app for second-factor authentication, which can be used together with a business application, such as an e-banking application. However, some Airlock customers prefer to replace the Airlock 2FA app with an alternative 2FA solution (see also Alternatives to the Airlock 2FA App).

• These are possible use cases:
• Bank A wants to replace the Airlock 2FA app with a custom, white-label 2FA app (its e-banking application itself remains in use). The white label 2FA app shows the bank's logo and includes customized content that is more relevant to the bank's clients than the content of the Airlock 2FA app.
• Bank B wants to introduce an entirely new e-banking app for mobile use only, which replaces their previous e-banking solution. With the new e-banking app, the user no longer has to actively confirm their identity on a separate 2FA app. Instead, the e-banking app features a built-in two-factor authentication that runs in the background. The app was developed using the Futurae SDK.

If an Airlock customer decides to replace the default Airlock 2FA app, the customer's clients must migrate the Airlock 2FA app installed on their mobile devices to the new 2FA solution. This article provides several scenarios and corresponding configuration options for the migration from the Airlock 2FA app to a white-label 2FA app or the One App solution. The provided configuration options facilitate the implementation of the use cases above.

In the following, we call the clients of an Airlock customer who must perform the migration end-users (of the business application).

• The following applies to all migration use cases:
• End-users access the business application (e.g., e-banking application) either
• via the browser on their desktop/tablet,
• via the browser on their mobile phone, or
• via the app of the business application on their mobile phone.
• End-users may have installed the Airlock 2FA app on more than one mobile phone, e.g., on their private and their business mobile phone, on two private mobile phones, etc.
• Each combination of end-user/mobile devices registered with the Airlock 2FA service in the Futurae cloud builds a token for the business application. This means that users can have multiple tokens for the same business application if they have the Airlock 2FA app installed on multiple devices.

0. There are two scenarios when migrating the Airlock 2FA app:
1. All tokens of the migrating user for the business application are deleted. As a consequence, the end-user can no longer use the old Airlock 2FA app for authentication on non-migrated devices.
2. Only the token used for the migration is deleted. In this case, an end-user can still use the business application in combination with the old Airlock 2FA app on their other, non-migrated devices. A possible use case for this scenario is:
• End-user Bob owns a private and a business mobile phone and has the Airlock 2FA app installed on both devices. He uses the Airlock 2FA app for second-factor authentication in his e-banking application.
• At work, Bob downloads the new One App solution with built-in two-factor authentication from his bank's website on his business phone and successfully migrates to and activates the new e-banking app.
• However, Bob's employer does not allow using the business phone for private matters, so Bob usually leaves the business phone in the office. To pay private bills outside the office, Bob uses an old e-banking application on his laptop. As the old Airlock 2FA app/token on his private mobile phone is still valid, he can perform the payment transactions – even though he does not have his business phone with the new e-banking app at hand.

• Based on the above-described migration use cases and scenarios, the following configuration options are possible:
• Option 1 – Migration from the Airlock 2FA app to another, white-label 2FA app, where all old tokens of the migrating user are deleted.
• Option 2 – Migration from the Airlock 2FA app and the business application to a new business app with a built-in 2FA solution (One App), where
• all old tokens of the migrating user are deleted (Option 2a).
• only the token used for the migration is deleted (Option 2b).

Currently, it is not possible to only delete the token used for migration when migrating from the Airlock 2FA app to another 2FA app. This is because the corresponding business application cannot know which 2FA app is enrolled on which mobile device.

• The following articles explain how to configure each option:
• Option 1 and 2a (deleting all "old" tokens after migration)
• Option 2b (deleting only the migrated token after migration)

The graphics below show the various configuration options:

Option 1: Migration from the Airlock 2FA app to white label 2FA app. All old tokens of the migrating user are deleted. Advantage: Easy to implement. Disadvantage: No longer possible to use the old Airlock 2FA app on non-migrated devices.

Option 2a: Migration from the Airlock 2FA app and the business application to a new business app with a built-in 2FA solution (One App). All old tokens of the migrating user are deleted. Advantage: Easy to implement. Disadvantage: No longer possible to use the "old" Airlock 2FA app on non-migrated devices.

Option 2b: Migration from the Airlock 2FA app and the business application to a new business app with a built-in 2FA solution (One App). Only the token used for migration is deleted. Advantage: The user can still use the "old" Airlock 2FA app on non-migrated devices. Disadvantage: More complicated to implement.

• Internal link:
• Alternatives to the Airlock 2FA App