Enrolment and re-enrolment are two of the most security-sensitive aspects of a banking app. One could argue that re-enrolment in particular is the most sensitive of the two procedures, even more sensitive than verifying transactions. The reason is simple: when you do an app-based strong customer authentication (SCA), the user has been authenticated on the device before. This means that it is possible to check the ‘possession’ factor using a device fingerprint from before.

But what about when the customer has lost their device, and needs to be re-enrolled in the service? In that case, the possession factor cannot be verified, and email addresses, passwords and secret codes are no longer strong enough on their own to identify the user. 

If this happens, it is fairly easy for a user to be impersonated by an attacker who has gotten a hold of their personal credentials. There have been many data breaches where passwords and phone numbers have been leaked, especially since many people use the same password and email address combination everywhere. This makes re-enrolment a very tempting target for those attackers wanting to impersonate customers.

That is why if a customer does have an existing device registered to their account, we recommend using SCA through that device to enrol any potential new devices. A typical way to do this would be to use a QR code that the user can scan from one device to another. In the case where there are no existing devices linked to an account, we recommend that the customer go through a full “know your customer” (KYC) procedure in order to re-enrol their new device.

While the EBA and other regulatory bodies haven’t been very clear regarding their requirements for re-enrolment, it is implicitly stated in Article 24 of the RTS that:

 “The association by means of a remote channel of the payment service user's identity with the personalised security credentials and with authentication devices or software is performed using strong customer authentication.” 

In other words, doing a full KYC procedure is currently the only way to complete proper strong customer authentication in the re-enrolment scenario. The only other alternative would be to send a message to a known phone number or email address - both of which are unfortunately typical targets for an attacker.

One could argue that using a secret code known only by the user (the “knowledge” factor) combined with the phone number registered to the SIM card (“possession”) would be strong enough for SCA. But, re-enrolment typically is for accounts that carry a balance, which makes them a very tempting target. Text messages can be stolen with malware, and access to email addresses is far from secure.

One of the ways we’ve helped our customers strengthen their re-enrolment process is to implement a mechanism known as ‘magic link’. A magic link is a link received through a semi-secure channel that authorises the customer to use a particular device. Using a link like this can be practical, as the re-enrolment procedure might be stretched out over time. 

It typically begins with the user re-installing their banking app on their new device. Once the user opens the app and enters their credentials. If they don’t have any other devices they are asked to go through a KYC procedure. In the background of the app, the Okay SDK has created a cryptographic key which identifies the device, and shares this with the customer’s back-end. The KYC procedure typically requires the user to identify themselves using an ID card through a video call. 

Once the procedure has been completed, the user receives an email or SMS with the magic link. And once opened, the re-enrolment procedure on the device will be complete. Using the link makes it possible to verify the user more securely than during the initial customer onboarding, and it is even possible to check that the onboarding process finishes on the same device as it was started.

But what can you do as a normal user to protect you from impersonation attacks? Besides using unique passwords per individual service, another tip is to use the website ‘Have I Been Pwned’ to check if your credentials have been compromised. If you’re interested in some of the other issues around onboarding customers, I’ve written a blogpost about this earlier as part of a series about SCA industry challenges.