Dev.to Security 🔐 Cybersecurity 👁 0 📖 7 min read

GrapheneOS Banking Apps: 90% Work. Here's How to Fix Yours (2026 List)

Anyone thinking about GrapheneOS asks the same thing first: will my banking app work? Most of the time it will, about 9 in 10 by the project's own count. On October 23, 2026 the GrapheneOS project posted that roughly 10%

Anyone thinking about GrapheneOS asks the same thing first: will my banking app work? Most of the time it will, about 9 in 10 by the project's own count. On October 23, 2026 the GrapheneOS project posted that roughly 10% of banking apps refuse to run because they block any OS Google hasn't approved, and that a growing number, around a dozen so far, now explicitly allow GrapheneOS alongside the approved ones.

A dozen is small, but it matters more than it looks. The banks in that group that verify GrapheneOS with hardware attestation show the check blocking you was never about security.

I'll go through why Play Integrity rejects GrapheneOS, which banks I could actually confirm allow it, and what to set up if your bank isn't on the list.

Why Play Integrity says no to GrapheneOS

Most banking apps that block GrapheneOS do it through Google's Play Integrity API. GrapheneOS's usage docs still describe it in the older SafetyNet terms, but the result is the same: the OS passes the basicIntegrity check but "isn't certified by Google," so it fails ctsProfileMatch. In Play Integrity terms, that means it fails the device integrity verdict.

The certification has nothing to do with whether your phone is compromised. GrapheneOS doesn't license Google Mobile Services, and the device integrity verdict is mostly a licensing check. In the Hacker News thread on the announcement, the GrapheneOS account said device integrity "barely does anything more than enforcing licensing Google Mobile Services." It also said something I think is fair to the banks: "Nearly all these apps aren't banning GrapheneOS on purpose but rather because they're doing the least possible work."

So a Pixel running a current GrapheneOS build with locked bootloader and verified boot gets rejected, while a cheap certified phone that hasn't had a security patch in two years passes. From a security point of view that's backwards.

The project also gave numbers in the same thread. Around 90% of banking apps work on GrapheneOS today. Without its workarounds for buggy anti-tampering code, it estimates that would be closer to 50%, and closer to 20% without the sandboxed Google Play compatibility layer as well. Most of what's left fails on Play Integrity.

How hardware attestation lets banks verify GrapheneOS instead

Android has a better option, required on every device launched with Android 8 or later: hardware key attestation. The phone's hardware keystore signs a certificate chain that describes the hardware, firmware, OS, and the app's signature. GrapheneOS's attestation compatibility guide calls it "a much stronger form of attestation than the Play Integrity API."

The part that matters here is the verified boot key. When an app gets the attestation result, it checks verifiedBootState:

  • Verified means a stock OS signed with the manufacturer's key.
  • SelfSigned means a locked bootloader with a user-installed key. The app then compares verifiedBootKey against GrapheneOS's official fingerprints.

GrapheneOS publishes those fingerprints as a signed JSON file, and the guide tells developers to check the timestamp to block downgrade attacks and to refresh the list as new devices get support. The check also avoids any dependency on Google Play services or Google's Play Integrity servers.

The developer side comes down to four steps: verify the chain with Google's key attestation library, accept Verified or SelfSigned with an official GrapheneOS key, fall back to Play Integrity on devices older than Android 8, and keep the key list current. That's a sprint of work for a bank's mobile team, and the banks in the next section have done it.

The GrapheneOS banking apps list: banks confirmed to allow it

The GrapheneOS post doesn't name the dozen. In the HN thread the project said it had convinced "around a dozen banks mostly in the EU to use the standard Android key attestation API," and elsewhere said "around 6-8 banking companies" had made changes, several with multiple apps, which "add up to around a dozen apps." Still no names. So I went to the primary posts and the PrivSec.dev compatibility list (last updated October 20, 2026) and kept only entries with a direct source.

Bank / app Country What's confirmed Source
Yuh Switzerland Whitelisted GrapheneOS via hardware attestation, the first Swissquote app to do it GrapheneOS, July 2025, PrivSec
Swissquote Switzerland Release notes: "We now officially support GrapheneOS!", verified via hardware attestation GrapheneOS, Aug 20 2025, PrivSec
UBS & UBS key4 Switzerland "This app officially supports GrapheneOS." PrivSec
Triodos Bankieren NL Netherlands Added explicit support and said it will test on GrapheneOS going forward. PrivSec currently flags it as broken on the Pixel 10 series GrapheneOS on X, forum thread, PrivSec
AmeriCU Credit Union United States "This app officially supports GrapheneOS!" PrivSec

One HN commenter added Starling Bank to this group. Starling sits on the PrivSec list, but its entry has no note about explicit support, so I left it out. If you know otherwise, link it in the comments.

The HN thread also covered two others. Revolut works right now, GrapheneOS says it's in contact with them, and a commenter pointed out Revolut is changing its terms around custom firmware, so I wouldn't call it settled. Curve works, but only with sandboxed Google Play installed.

One caveat: "officially supports" doesn't always mean attestation. The project said in the thread that some of these apps simply fixed their own anti-tampering code or stopped calling Play Integrity. Only some added hardware attestation as an alternative.

Setup that gives your bank app the best odds

If your bank isn't in the table, it probably still works. The project's own post says most banking apps do, and that many failures come from memory corruption bugs and broken anti-tampering code in the apps, not deliberate blocking. Work through these in order.

  1. Install sandboxed Google Play in the profile where the bank app lives. Open the GrapheneOS App Store, select Google Play services, install. Lots of banking apps need Play services without telling you, for push notifications or the integrity call itself. The docs recommend the Owner profile for the simplest setup. If you'd rather keep Google in a box, put Play and the bank app in a separate user or work profile, but test there first, since some apps behave differently outside the main profile.

  2. Turn on the per-app exploit protection compatibility mode. Go to Settings > Apps > [your bank app] > Exploit protection compatibility mode. For that app only, this swaps hardened_malloc for Android's standard Scudo allocator, drops the address space from 48 bit to 39 bit, disables memory tagging (unless the app opted in), and allows ptrace. That's the fix for a bank app that crashes on launch because of its own memory bugs. Leave it off for every other app.

  3. Re-enable native code debugging if you turned it off. Settings > Security & privacy > Exploit protection. Some anti-tampering code breaks without it, and the docs say to try enabling it again if you hit problems.

  4. Check the app-specific weirdness. One HN commenter reported the HSBC app refusing to run with a keyboard other than Gboard or Samsung's, and another said the app locks you out if you speed up animations in developer options. Read your bank's PrivSec entry for notes like these before you blame the OS.

  5. If it still fails on Play Integrity, email the bank. Be specific. Something like:

Your Android app blocks GrapheneOS through the Play Integrity API. GrapheneOS has a locked bootloader and verified boot, and it can be verified with the standard Android hardware key attestation API. Swissquote and Yuh already do this, and UBS and Triodos officially support GrapheneOS. The implementation guide is here: https://grapheneos.org/articles/attestation-compatibility-guide

A support ticket that says "your app doesn't work" goes nowhere. One that names the API, links the guide and lists competitors who already shipped it has a real chance of reaching the mobile team. And this kind of pressure does work: in the HN thread, GrapheneOS said it has "convinced dozens of apps to drop using attestation with user pressure."

Where this leaves tap-to-pay

Payments are still the weak spot. In a follow-up reply, GrapheneOS said Google Pay bans GrapheneOS and most banks worldwide hand tap-to-pay to Google Pay. In Europe you have options: Curve Pay, PayPal and many European banking apps allow tap-to-pay on GrapheneOS. For everywhere else, the project's summary was: "Google Pay has a monopoly outside of Europe which is the main problem."

My take: a dozen apps is a rounding error, but it ends the argument that blocking GrapheneOS is about security. The project says the hard part is getting a bank to accept the first alternative to Apple and Google; after that, adding more is a much easier sell. The rest of that 10% are doing what GrapheneOS called "the least possible work," and a specific, polite email is how you make that cost them something.

Which bank still refuses to run on your de-Googled phone? Name it, with the country, so the next person knows before they switch.

Sources

📰 Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.