Use both, but prioritise OS-level blocking where Android 12 or later is available because it prevents the overlay from rendering in the first place. App-level touch filtering remains necessary for older devices, yet it should be treated as a fallback, not the primary control.
Why mobile banks should not choose only one overlay defense
The right answer is not app checks or OS blocking, but a layered control model that matches device capability. Overlay abuse is a user-interface attack path, so the control has to stop the malicious screen from capturing interaction, not just detect suspicious touch behaviour after the fact. That distinction matters most when login, approval, or payment flows are exposed to credential theft and transaction manipulation.
App-level touch filtering can still catch some cases, but it depends on the app noticing the condition in time and interpreting the event correctly. OS-level blocking is stronger on supported Android versions because the platform can prevent the overlay from drawing over the protected screen at all. For a bank, that is a material difference in blast radius and reliability.
Device diversity also shapes the decision. Older Android builds and some fragmented OEM environments may not support the same blocking behaviour consistently, so a fallback inside the app remains necessary to avoid leaving part of the user base unprotected. The control choice should therefore be based on coverage, enforcement point, and failure mode, not just implementation convenience.
What each control actually protects
App-level checks are usually a detection-and-response layer. They can warn, pause, or block when the application believes another window is obscuring the active screen, but they still rely on the app process seeing the situation and acting before the user completes a sensitive action. That makes them useful, but inherently reactive.
OS-level overlay blocking is preventive. When the operating system enforces the restriction, the dangerous interaction is stopped earlier in the chain, which is why it is the better primary defense for supported devices. Mobile banks should treat this as the control that protects the highest-risk screens, especially where authentication, step-up verification, and payment confirmation occur.
The strongest pattern is to reserve the app layer for compatibility and secondary signaling, while depending on the OS layer for the primary security decision whenever the platform can enforce it. This is the same principle used in other security designs: block at the strongest enforcement point first, then add application logic where platform gaps remain.
How to set the policy for mixed Android fleets
A practical policy should classify devices by operating system capability, not by user segment alone. If Android 12 or later is present and the OS control is available, the bank should prefer platform enforcement for protected flows. If the device falls below that baseline, the app should fall back to touch filtering, with a clear understanding that this is compensating control rather than equivalent protection.
That means the bank’s risk acceptance decision is really about residual exposure on legacy devices. The question is not whether older devices can be supported, but whether their lower assurance is acceptable for the specific transaction or authentication step. For high-value actions, many banks will want stricter handling, such as step-up checks, transaction confirmation hardening, or a refusal path if the platform control is missing.
Implementation also has to be tested against real overlay behaviour, not just simulated UI states. Controls that look effective in a lab can fail under accessibility tooling, OEM customisations, or rapid screen transitions, so the policy should include verification on the exact device classes the bank actually supports.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V3 — Web Frontend Security | Overlay blocking and touch handling affect client-side interaction security. |
| Recommendation — Validate sensitive screens resist UI overlay abuse and related interaction hijacking. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | Blocking hostile overlays helps prevent malicious UI-driven abuse on mobile endpoints. |
| Recommendation — Apply endpoint controls that prevent or contain malicious UI abuse on protected devices. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Mobile overlay handling depends on enforcing supported device baselines and OS settings. |
| Recommendation — Set mobile OS baselines so supported devices enforce the stronger overlay control. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Sensitive actions should rely on stronger enforcement before trust is granted to user input. |
| Recommendation — Verify the device control path before allowing high-risk mobile transactions. | ||
Practitioner Guidance
What to prioritise: Put OS-level blocking first for any device that supports it, then use app-level filtering only as a fallback for older or inconsistent Android environments. For the most sensitive actions, assume the app-layer signal is weaker and require the platform control where possible.
What to verify: Confirm the exact Android versions, OEM variants, and flow types covered by the OS restriction, and test that the protected screen cannot still be interacted with through accessibility edge cases or race conditions. The control is only as strong as the specific device population you ship it to.
Common mistake: Treating touch filtering as equivalent to overlay prevention. It is not, because detection after exposure is a different security outcome from blocking the overlay before it can influence the user.
Practitioner takeaway: Use the platform as the primary enforcement point wherever possible, and keep app-level checks as a compatibility layer, not as the main assurance boundary.
Related resources from NHI Mgmt Group
- What is the difference between build-level blocking and general device compliance checks?
- How should security teams decide between mobile threat defense and mobile app vetting for enterprise mobile risk?
- How should teams decide between middleware checks and server-side authorization in App Router?
- How should security teams decide between a VPN-style overlay and privileged access management?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org