In the modern world, a large percentage of banking and eCommerce is done on a singular device, where a transaction can be started, verified and completed. As you might have guessed, this singular device is typically a smartphone, and if left unsecured, becomes vulnerable to malicious attacks.

In this reality, criminals and hackers have little mercy for the end-users who have unknowingly given them access to their mobile applications, their transaction authentication methods, and their ability to finalise purchases without ever being detected.

Some time ago, we wrote an article on the mobile OS headache where we explained that today’s banks and fintechs must deal with +50% of their customer-base using devices that no longer receive security updates. And while a user’s ability to receive security updates is important as a stand-alone subject, there are still other potential problems that need our attention, most notably how devices get infected, and how the operating system handles access to potentially vulnerable functionality.

While there is a growing list for how a device can get infected, the most common channels are:

• 3rd party applications that have tricked the user into installing something
• Security issues with the web browser
• Phishing-links over email or text messages

When it comes to mobile operating systems, by far the most common is Google Android. Used in phones running as low as USD 30, Google has a history of being quite liberal with their software rights, allowing nearly anyone to make Android devices.

However, this comes at a huge disadvantage; traditionally, the device producer provided all operating system updates. But today, Google enforces a rule whereas device vendors only need to supply two years of updates. Some choose to do better, of course; for instance, my Samsung S8, bought back in the spring of 2017 received security updates until October 2020.

Over the last few years, we have watched Google become increasingly stricter with its updates, having moved many of them from being vendor-provided to Play Store-provided. While this helps make updates more widely available even after vendors stop sending them to users, it also places the responsibility in the user’s hands to search for updates and download them themselves.

Additionally, on the OS side, Google has allowed software installations from third parties, and have not been strict in enforcing their own guidelines outside of obviously criminal or fraudulent software.

With Apple’s iOS, the situation is a bit simpler: Apple typically only releases updates for the latest major version of their mobile operating system. This means that as of November 2020, the iPhone 6s and up are fully supported. The iPhone 6s was released back in September 2015, so users receive updates for about 5 years.

Of course, there are some cases where security updates for older versions of iOS are released as well, such as the latest series of security patches which aimed to protect devices from root-level malware infections after users visited certain web pages. This security patch was widespread and even made available for iPhone 5s users, whose OS was released in September 2013.

Speaking of the OS side, Apple’s iOS is also a lot more restrictive in the installation origin of applications. As of today, it is not possible to install anything from anywhere except Apple’s walled garden, nor is it possible to install an alternative web browser engine (as all alternatives to the Safari browser must be based on the Safari engine).

This gives a lot less freedom to the user, but it also means that there are fewer “entry points” for malware. This is both because a user can’t be tricked into installing an application from somewhere else, and there is no vendor or third-party provided web browser that can be a vector for malware.

As an added note: Apple does seem to protect their iTunes store more than Google protects its Play store.

It is easy to take into account the actions of large multinational companies. But what do our regulatory friends in the European Banking Authority (EBA) think about security updates and the threat from malware? Who is responsible for fraud enabled by lacking operating system security?

Sadly, this is hard to say, as there is not a clear answer anywhere in the text of the Payment Services Directive 2, the Regulatory Technical Standard, or the Rule Book. The closest answer we can find is from the RTS where it states:

“PSPs shall adopt security measures, where any of the elements of SCA or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised. The mitigating measures shall include each of the following: (a) the use of separated secure execution environments through the software installed inside the multi-purpose device; (b) mechanisms to ensure that the software or device has not been altered by the payer or by a third party; (c) where alterations have taken place, mechanisms to mitigate the consequences thereof.”

The easiest way to interpret this is that the responsibility for any given devices’ security falls on the payment-service provider. And, even if the device is found to be vulnerable, it is not something that can be used as an excuse if there should be a dispute over a payment. This shows how important it is for PSPs to take the device security into account. 

So, what can end-users do to avoid trouble with security issues? If one is paranoid about security, it is best to verify payments on a device dedicated to only that one function. For everyone else, the advice is simple:

• Try to keep your device updated
• Avoid installing applications from insecure locations
• Be careful about the links sent to you via email or SMS

— — —

Are you an issuer or PSP who is required to secure payments? Do you have ideas on how SCA and OS will intersect in the future? Make sure to send us your thoughts and keep the conversation going.