Over a Dozen Banking Apps Officially Support GrapheneOS: A Turning Point for Security and Compatibility

GrapheneOS officially announced on social media that about a dozen banking apps have begun explicitly allowing them to run on GrapheneOS. The news quickly gained 272 points and 73 comments on Hacker News—a symbolic milestone for a privacy-focused operating system that has long been locked out by mainstream financial applications.

From "Detected and Rejected" to "Explicitly Allowed"

GrapheneOS is an open-source, Android-based operating system known for hardened security and privacy. It has long faced a practical dilemma: many banking, payment, and government apps detect whether a device has been modified, and upon identifying an unofficial system, they either crash immediately or refuse login. Users were forced to choose between security and usability.

The keyword in this change is "explicitly allowed." According to information posted by the official GrapheneOS account, about a dozen banking apps no longer treat GrapheneOS as an untrusted environment and have proactively allowed it. This means these apps' integrity detection logic has been adjusted—rather than users bypassing it through spoofing. For people who rely on mobile banking daily, this directly eliminates a long-standing pain point.

Why does GrapheneOS get treated as an "untrusted environment" by banking apps? The core lies in the system integrity verification mechanisms within the Android ecosystem. Google's SafetyNet (later upgraded to the Play Integrity API) checks whether the device's bootloader is unlocked, whether system partitions have been modified, and whether the device has passed Google's compatibility certification. Although GrapheneOS re-locks the bootloader and maintains hardware-level security verification, it does not ship with Google services framework and does not participate in Google's compatibility certification process—so by default it cannot pass Play Integrity's "device certification" and "app integrity" checks. Banking apps call these APIs to determine whether the runtime environment is "trusted," and once the check fails, they outright refuse to run. This "explicit allowance" means some banks have adjusted their risk control logic, no longer treating GrapheneOS's signatures or system properties as anomalies, but instead making comprehensive judgments based on other signals (such as login behavior and device fingerprint stability).

Why Banks Are Loosening Their Stance

Banks' caution toward non-standard systems is not without reason. Financial apps handle money operations, and risk models typically treat "system integrity" as an important signal. Although GrapheneOS maintains a high security baseline through mechanisms like re-locking the bootloader and hardware-level security verification, its identity as "unofficial Android" still easily triggers false positives.

Several forces are driving the loosening stance. First, the GrapheneOS community has continuously communicated with developers to help app providers understand the system's security model. Second, although the user base is small, it is highly loyal—abandoning these users represents a net loss for banks. Third, compatibility with custom systems within the Android ecosystem is improving. According to views in HN discussions, some banks may have evaluated and updated their detection strategies one by one after receiving substantial user feedback.

Re-locking the bootloader is a key concept for understanding GrapheneOS's security model. On standard Android devices, unlocking the bootloader triggers a "device unlocked" warning and lowers the system integrity level. GrapheneOS, however, allows users to re-lock the bootloader after flashing a custom system, and together with hardware-backed Verified Boot mechanisms, restores the device to a "locked and verifiable" state. This means GrapheneOS devices can still guarantee at the hardware level that the system image has not been tampered with and that the boot chain is intact. However, many banking apps' detection logic only recognizes "official signatures" or "Google certification" and does not distinguish between the security difference of "unlocked then re-locked" versus "long-term unlocked state," causing GrapheneOS to be misjudged as a high-risk environment. The fact that some banks are now allowing it suggests they are beginning to understand the nuances of this security model, rather than simply vetoing anything based on "unofficial system."

What It Means for Privacy-Conscious Users

For ordinary users, the direct impact of this news is "one fewer backup phone to carry." In the past, many GrapheneOS users needed to keep an official-system phone specifically for banking. Now this need may shrink.

The deeper significance lies in the demonstration effect. Banking apps are typically regarded as the most conservative category when it comes to compatibility; their approval will reduce other developers' concerns. If financial scenarios can work, the adaptation resistance for social, travel, and government service apps will also decrease accordingly. By making this progress public, GrapheneOS itself is sending a signal to more developers: supporting this system is no longer an edge-case behavior.

Sandboxed Google Play services is another background element of GrapheneOS's compatibility strategy. GrapheneOS does not preinstall Google Mobile Services (GMS), but allows users to install Google Play Store and Play services as ordinary apps, running them in a restricted sandbox environment with system-level permissions stripped away. This design allows banking apps that depend on GMS to still obtain basic capabilities such as push notifications and location services, while users retain fine-grained control over permissions. However, some banking apps detect whether GMS is running as a system app, or check whether Play Integrity certification results come from a "trusted Google environment." GrapheneOS's sandboxed approach cannot forge these system-level attestations, so compatibility has long been limited. Part of the reason these banks are now allowing it may be that these apps have reduced their reliance on strong Play Integrity certification and turned to proprietary risk models, thereby leaving room for sandboxed environments to run.

Boundaries That Still Warrant Caution

A quick note: "about a dozen" is a limited number, and the official announcement did not list the specific bank names one by one in the original information. Banking apps in different regions update at different paces, so users' actual experiences may vary. Moreover, explicit allowance does not equal official technical support—cases where detection logic regresses after app updates have occurred before.

Judging from the atmosphere in HN discussions, the community holds a cautiously optimistic attitude: on one hand, acknowledging this as substantive progress; on the other, reminding people not to overinterpret it as "GrapheneOS has been fully accepted by the mainstream financial ecosystem." For users who depend on specific banking apps, it is still worth confirming whether their bank is on the list before upgrading.

Conclusion

Over a dozen banking apps explicitly allowing operation on GrapheneOS is a pragmatic victory for a privacy-focused operating system on the compatibility battlefield. It shows that security hardening and everyday usability are not irreconcilable, and that sustained user communication can change developers' detection strategies. Whether this progress can spread to more financial applications will determine whether GrapheneOS can truly break out of its niche.