HSBC decided your phone's privacy container looks like an attacker

Somebody kept their HSBC app in Samsung Secure Folder, which is where Samsung tells you to put things you want isolated. This week it stopped working. Not degraded, not warned about. It stopped, and because that app was also the second factor for web banking, they lost access to their online banking too.

Getting back in takes five to ten working days, either for alternative authentication to arrive or for a physical secure key to turn up in the post. In the meantime there's no online banking at all.

The customer's account of the support call, quoted in The Register's report on Thursday, is the part I keep rereading: "I called to complain and was told this is an intentional policy change and I need to store it in the regular part of my phone as they consider this to be more secure. No advance communication of the change, and the policy seems mad to me."

Intentional. No notice. Nothing on the help pages, nothing the chatbot knew about.

What HSBC blocked, and what that actually is

Two containers are affected: Samsung Secure Folder and Android Private Space. It's worth being precise about what those are, because the whole argument turns on it.

Neither is a jailbreak. Neither is a third-party sandbox someone installed from a forum. Secure Folder is Samsung's own Knox-backed container, shipped on the phone, advertised by Samsung as the place for sensitive apps. Private Space is Google's, built into Android, doing the same job. A customer who puts a banking app in one of those is doing the thing the operating system vendor told them to do with sensitive apps.

HSBC's explanation, as given to The Register: "For security reasons, our mobile banking app cannot be used within certain protected private space and virtual space tools, which could prevent or limit the identification of certain threats, or from sending timely fraud notifications."

The notifications half is real and checkable. Apps in these containers are subject to different background and notification behaviour, so a fraud alert can be delayed or suppressed. That's a legitimate concern and I have no argument with it.

The threat identification half is where it gets interesting, because the signal a banking app can actually read here does not distinguish between the OS's own privacy container and a hostile one. Both look like a work-profile-style user container from inside the app. So the rule cannot be "this environment is dangerous". It can only be "this environment is one I can't inspect", which is a different statement with a different set of people caught by it.

This is the second time in nine months

In January, HSBC locked out customers who had sideloaded the Bitwarden password manager from F-Droid, treating it as a potential malware risk.

Bitwarden is open source, widely audited, and recommended by roughly every security guide in existence. F-Droid is the main repository for open source Android software. The signal the app could read was "an APK arrived from outside the Play Store", and that signal doesn't distinguish Bitwarden from anything else.

Two incidents nine months apart, and the same shape in both. A device-integrity heuristic reads a coarse signal, cannot resolve what the signal actually means, and resolves the ambiguity by denying service. In both cases the population it caught was people who had gone out of their way to be more careful than average.

The false positive rate nobody quotes

Every detection rule has a false positive rate, and in security work we're used to that number being about alerts. An analyst looks at the alert, decides it is nothing, moves on. The cost of a false positive is a few minutes of attention, which is why teams tolerate fairly bad rates.

This rule doesn't produce an alert. It produces a denial of service against a named customer, and in the MFA case a denial of access to their money for up to two working weeks. The cost per false positive isn't minutes. It's a person who can't pay a bill.

Nobody outside HSBC knows the rate. But you can reason about who is in the numerator. A customer who moves their banking app into Secure Folder is, almost by definition, not the customer running a device compromised by a remote access trojan. The rule is landing hardest on the segment least likely to be the threat it is written for, which is the textbook signature of a proxy signal standing in for something you cannot measure.

The part that is a delivery failure, not a security decision

The obvious way to argue about this is whether the block is justified. Argue that if you like. I think the more useful observation is that the block and the rollout are separate decisions, and only one of them went wrong in a way nobody can defend.

Suppose the rule is right. Suppose containers really do break fraud notification badly enough to justify refusing service. None of that tells you to ship it silently.

A change that can revoke a customer's access to their own money has a rollout plan attached to it, or it isn't finished. In-app warning first, with a deadline. An email to the affected segment, which the bank can identify precisely because the app is reporting the container. A help page that exists before the change lands, not after. A support script that says the right thing on day one. And a recovery path measured in hours.

What actually shipped had none of that. The customer found out by failing to log in. The support agent explained the policy after the fact. The help pages had nothing, and the chatbot had nothing, which means the change reached production without reaching the documentation, and those are usually the same release. It's the same failure I wrote about in the MCP piece yesterday, in a different register: something lands in production, everything downstream reports normal, and the only thing that notices is a person.

Anyone who has shipped a validation rule or a fraud rule knows the shape of this. The rule is defensible in the abstract and the rollout determines whether it lands as a security improvement or an outage. We treat that as a release engineering question, with a staged rollout and a kill switch, because the rule and the blast radius are separate risks. A bank shipping a device-integrity rule should be held to the same standard as an engineering team shipping a schema constraint, and this one wouldn't have passed our gate.

The five to ten working days is the tell. That's not an incident response window. That's a business as usual fulfilment process being used as the recovery path for an outage the bank caused, which means nobody modelled the recovery at all.

What I would check on Monday

If you own a rule that can deny a user access, three questions, and the first one is the only one most teams can answer.

What is the rule's false positive rate, and who is in it? Not the aggregate. The segment. If the answer is a shrug, the rule is running on faith.

What does a false positive cost the person it happens to, measured in time to recovery? If that number is longer than a day, the rule needs a staged rollout and a warning period, and you already know it does.

Who signs off that the help page, the support script and the rule all ship together? On this one that question has an answer, and the answer is nobody, which is how a support agent ends up explaining a policy the help pages have not heard of.

The thing I can't get past is that both times, the customer's offence was following advice. Put sensitive apps in the secure container, says Samsung. Use a reputable open source password manager, says every guide. Do both and your bank decides you look like a threat, tells you nothing, and posts you a key.

Marking my confidence

Established. The block, the containers affected, the absence of advance notice, the five to ten working day recovery window and HSBC's statement all come from The Register's report of 24 September 2026 by Jude Karabus, which I opened. The January incident involving Bitwarden sideloaded from F-Droid is reported in the same piece.

Thin, and worth saying plainly. This is essentially one outlet, The Register, plus a syndication of its story. I could not find an HSBC-published change notice anywhere, which is itself part of the story but also means the bank's position exists only as a statement given to a journalist. If HSBC has published something I did not find, that changes the release-communications half of this considerably and I'd want to know.

Inferred. That the detection cannot distinguish an OS-native container from a hostile one, and that this is why the rule is written as a blanket denial. HSBC hasn't described the mechanism and I'm reasoning from what a banking app can actually observe about its own environment. If they are reading something more specific, the false positive argument weakens.

Guess. That this gets quietly narrowed within two quarters, once the support cost lands, rather than reversed. Held loosely.

What would change my mind. Published data showing that compromised devices disproportionately run banking apps inside Secure Folder or Private Space. That would make the proxy signal a real signal and most of this piece wrong. I haven't seen such data and would like to.