home › Forums › Devices, Platforms & Apps › Contents & Applications › HSBC Blocks Samsung Secure Folder Access -Commentary

Viewing 1 post (of 1 total)
  • Posts
  • HSBC’s decision to block its mobile banking app from running inside Samsung Secure Folder and similar private Android environments may be intended as a security measure, but the way it has been implemented creates a different problem: customers can effectively lose access to a service that has become central to how they bank.

    This is particularly relevant in Malaysia, where the HSBC Malaysia Mobile Banking app is more than an optional companion to online banking.

    HSBC increasingly relies on the app for authentication. Its Mobile Secure Key can generate security codes for online banking, while HSBC Secure Logon requires customers to use the registered HSBC Malaysia app to scan a QR code and authenticate access from a desktop browser. HSBC also limits Mobile Secure Key registration to one device at a time.

    When access to that app is suddenly blocked, the issue is therefore not simply that a customer cannot check a balance from a particular part of their phone. Depending on how the customer has configured their banking access, HSBC may also be interfering with their ability to authenticate online banking sessions.

    That makes advance notice important.

    If HSBC intends to stop supporting Samsung Secure Folder, Android Private Space or any other environment that customers have been using successfully, customers should be told well before enforcement begins. A warning inside the app followed by a reasonable countdown, perhaps 30 days, would give users time to move their banking setup, obtain an alternative authentication method or contact HSBC if they need assistance.

    Simply allowing a working configuration to stop working is difficult to justify as good customer service.

    Security does not automatically justify removing customer choice

    There is a legitimate security argument behind HSBC’s approach.

    HSBC UK says private or virtual environments may prevent its app from identifying certain threats or delivering timely fraud notifications. HSBC Malaysia already applies malware shielding on Android and says that access can be suspended when it detects what it considers potential risks on the device.

    Malware attacks against Malaysian banking customers are also a real problem. The Association of Banks in Malaysia said in 2024 that banks were introducing malware shielding capable of identifying malicious APK files, suspicious remote-access capabilities and other potentially dangerous behaviour. Bank Negara Malaysia subsequently reported that fraud involving sophisticated malware continued to be a problem in 2025.

    None of that means every restriction imposed in the name of security is necessarily proportionate.

    Samsung Secure Folder is specifically designed to isolate apps and data from the rest of the device using Samsung Knox. Many users deliberately install financial apps there because they want another layer of separation between sensitive applications and their normal phone environment.

    HSBC may have technical reasons for deciding that this isolation prevents some of its own security checks from operating properly. But there is an important distinction between HSBC saying, “we cannot fully assess this environment”, and HSBC effectively saying, “you are not allowed to use our banking service from this environment”.

    The first is a security assessment. The second directly affects how customers are permitted to use their own devices.

    Give customers a clearly explained override

    A more reasonable approach would be to warn customers prominently and let them decide whether to proceed.

    For example, HSBC could display a message explaining that its malware detection or fraud-notification capabilities may be limited inside Secure Folder, outline the specific consequences, and require the customer to acknowledge them before continuing.

    Something along the lines of:

    “I understand that some HSBC security checks may not function within this protected environment and choose to continue.”

    The bank could record that acknowledgement and periodically remind the customer.

    There may be regulatory or liability reasons why HSBC would be reluctant to offer such an override, particularly where the bank believes allowing the transaction would expose customers to a serious and identifiable threat. But if HSBC believes an outright prohibition is necessary, it should explain precisely why a less restrictive approach is insufficient.

    At present, the customer largely receives the consequence without being given much visibility into the underlying risk assessment.

    HSBC should also be more transparent about what it considers dangerous

    This is not limited to Secure Folder.

    HSBC Malaysia already states that its Android app may refuse to operate when certain applications have accessibility permissions or when apps have been installed from sources it does not consider official. Customers may have to disable permissions or uninstall software before HSBC will restore access.

    HSBC does publish the app stores it recognises as official, including Google Play Store, Samsung Galaxy Store, Amazon Appstore, Huawei AppGallery and several manufacturer stores. However, it does not appear to publish a comprehensive list of individual apps or categories that its detection system may classify as risky.

    That leaves customers in an awkward position.

    A banking app should certainly be capable of detecting obvious indicators of compromise such as root access, malicious screen-control software or applications abusing powerful accessibility permissions.

    But the further a bank extends that detection into legitimate software installed elsewhere on a personal device, the stronger the need for transparency.

    Customers should be told exactly what triggered the block, which application or permission caused it, what security capability HSBC believes is affected, and what options are available.

    A generic “your device is at risk” message is not enough when the bank is effectively asking someone to modify software on a device that belongs to them.

    A bank should not become the administrator of a customer’s phone

    There is also a broader question about where a bank’s responsibility should end.

    HSBC has every right to protect its banking platform. It can secure its own app, verify device integrity, detect transaction anomalies, use strong authentication and refuse transactions where credible signs of compromise exist.

    It is much more contentious when access to banking begins depending on what other legitimate software a customer chooses to install on their personal device.

    HSBC itself says that its malware protection does not continuously monitor customer activity or conduct surveillance on the device.

    That is welcome, but customers are still being placed in a position where the bank’s software evaluates aspects of their device configuration and can deny access based on that assessment.

    Banks are financial institutions, not mobile operating-system vendors, antivirus companies or device-management providers.

    They should be careful about crossing the line from protecting their own application into dictating how an otherwise uncompromised personal smartphone should be configured.

    Secure Folder being blocked does not mean normal Android is automatically safer

    There is another problem with the messaging around these restrictions.

    If HSBC blocks Secure Folder because some of its security mechanisms cannot operate properly inside it, that does not establish that running the banking app in the normal Android profile is inherently secure.

    Moving HSBC outside Secure Folder does not prevent a customer from installing malware elsewhere on the phone. It does not eliminate phishing, social engineering, malicious accessibility services, zero-day vulnerabilities, account takeover or other forms of fraud.

    Likewise, HSBC’s malware shielding does not turn an Android device into a guaranteed secure banking environment.

    Bank Negara Malaysia’s own discussion of malware shielding describes these controls as part of a wider set of protections, not as an absolute defence. Banks also rely on transaction monitoring, authentication controls, supported operating systems, device-integrity checks and customer vigilance.

    So there is an obvious question HSBC should be prepared to answer: if customers comply with every device restriction demanded by the bank, does HSBC guarantee that mobile banking is secure?

    The answer, realistically, can only be no.

    No bank can guarantee that fraud or account compromise will never occur.

    That does not make HSBC’s security controls pointless. It means the controls need to be presented honestly as risk-reduction measures rather than treated as justification for unrestricted control over a customer’s device.

    There are also accessibility implications

    HSBC Malaysia’s existing malware controls deserve scrutiny for another reason.

    Its own FAQ explains that Android accessibility services can be used by people who have difficulty interacting with their device, including through screen readers and text-to-speech functions. HSBC also acknowledges that these powerful permissions can be abused by malware.

    The security problem is therefore genuine, but so is the possibility of affecting legitimate users.

    A bank should be particularly careful when security controls interfere with accessibility software. Detection needs to distinguish malicious behaviour as accurately as possible rather than treating powerful permissions themselves as sufficient evidence that a device is unsafe.

    False positives matter when the consequence is losing access to banking.

    Alternative authentication should be readily available

    HSBC should also ensure that customers who cannot or do not want to comply with its mobile-device requirements retain a practical way to access their accounts.

    HSBC Malaysia still documents the use of a Physical Security Device for some customers, while its online banking documentation increasingly directs customers towards Mobile Secure Key and Secure Logon through the mobile app.

    An alternative authentication method should not become something customers discover only after they have already been locked out.

    If HSBC decides that certain phones, software configurations or secure environments are unsupported, customers should be offered an alternative before enforcement begins.

    Security should not create a single point of failure where losing access to one mobile app means losing convenient access to online banking as well.

    HSBC’s security responsibility does not end with blocking customers

    The strongest argument against this type of restriction is ultimately not that HSBC should ignore security threats.

    It is that security has to be balanced with availability, transparency and customer control.

    Blocking access is the easiest possible response to uncertainty. If the app cannot confidently assess an environment, deny access.

    But banking infrastructure should be designed to handle more than the easiest case.

    HSBC should be able to explain the exact risk, warn customers in advance, provide an appropriate transition period, offer alternative authentication, minimise false positives and, where technically and legally possible, give informed customers a way to continue.

    It should also publish clearer documentation about the device conditions and software behaviours that can trigger restrictions.

    A customer should not suddenly discover that a perfectly functional phone, or an intentionally isolated security environment such as Samsung Secure Folder, has been declared unacceptable only after opening their banking app.

    HSBC is entitled to protect its systems.

    Customers are equally entitled to expect predictable access to their money and reasonable control over their own devices.

    Good banking security should deliver both.

    0
Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.