Mobile banking teams should disable autocomplete on password fields and treat third party keyboard behavior as part of the authentication threat model. If a password is stored in predictive text caches, it may be retained in cleartext or transmitted to keyboard vendors. The safest control is to stop the password from ever entering those caches, then verify the app and device paths that handle typed credentials.
Why keyboard autocomplete is part of the sign-in threat model
Autocomplete on a password field is not just a user-interface convenience, it is a credential-handling decision. If the device keyboard learns the password, the secret can be retained in predictive caches, surfaced in suggestions, synced by the keyboard vendor, or reused in another app context. For mobile banking, that turns the sign-in form into a potential secret-disclosure path.
Teams should treat the password entry flow as part of the authentication boundary, not just the app screen. The key question is whether any typed credential can be observed, stored, or replayed by software outside the bank’s control. If yes, the safe default is to prevent the credential from entering those caches at all.
How to reduce leakage on mobile sign-in forms
The first control is to disable autocomplete on password inputs and verify that the implementation actually reaches the device keyboard layer the user is running. That matters because some mobile platforms, browsers, embedded web views, and third party keyboard apps do not behave identically, so one setting can be bypassed by another input path. A secure implementation is the one that blocks storage before the keyboard ever learns the secret.
Teams should also review adjacent sign-in fields such as username, one time passcode, and recovery answer inputs, because keyboard learning can spread across form elements. Where the app uses a native flow, a web view, or an SSO handoff, each path should be checked for different autocomplete defaults and different keyboard behaviors. A control that works in one path but not another is not a complete defense.
For mobile banking, this is also a secure design question: the app should make it hard for any third party input method to retain sensitive authentication material. The safest approach is to minimize typed secret exposure, prefer stronger authentication methods where possible, and ensure the sign-in flow does not rely on the keyboard behaving safely by default.
What teams should verify before trusting the control
Verification should focus on the actual device and app paths, not just the code setting. Test on representative iOS and Android versions, with common third party keyboards, password managers, autofill services, and embedded browser sign-in flows. Then confirm that the password is neither suggested after entry nor discoverable through keyboard prediction, clipboard behavior, or form memory.
It is also worth checking whether the bank’s mobile app, mobile browser, and any hosted sign-in page share the same protection. Authentication failures here are often uneven: one path may be hardened while another still leaks typed credentials to the keyboard layer. The control is only reliable when the weakest supported path is covered.
When teams need a broader mobile control baseline, it helps to map the sign-in flow to mobile app security and secret-handling guidance, not just authentication UX. NHIMG’s iOS apps leaking hard-coded secrets is a useful reminder that mobile applications often expose sensitive material through less obvious paths than the main login screen.
Risk and Threat Considerations
Keyboard autocomplete can convert a one-time sign-in event into persistent credential exposure. If the password is cached, synced, or surfaced in suggestions, an attacker, malicious keyboard app, or compromised device ecosystem may gain access to the secret even after the user leaves the sign-in screen.
Failure mechanism: The password is captured by keyboard prediction, stored locally or remotely, and later recovered through suggestion, sync, compromise, or reuse in another context.
Impact: A leaked banking password can enable account takeover, fraudulent transfers, or reuse against other services if users recycle credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passwords and their handling across devices are credential lifecycle concerns. |
| IA-2 — Identification and Authentication (Organizational Users) | Mobile banking sign-in is an authentication control for user access. | |
| Recommendation — Disable password learning paths and rotate or replace any exposed authenticator promptly. Harden the sign-in flow so user authentication does not expose credentials to third-party input methods. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Sensitive authentication material needs protection in transit and at rest across mobile flows. |
| Recommendation — Protect authentication secrets so they are not stored or exposed by the client input path. | ||
| OWASP ASVS | V6 — Authentication | Autocomplete on sign-in forms affects how credentials are collected and protected. |
| Recommendation — Apply authentication requirements that prevent password capture by unsafe client-side behaviors. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Typed passwords leaking into keyboard caches is a secret leakage pattern. |
| Recommendation — Eliminate client-side paths that can leak secrets into predictive text or vendor sync. | ||
Practitioner Guidance
What to prioritise: Treat the password field as a high-risk secret boundary and test the full sign-in path, including native app, web view, browser, and password manager interactions. If any supported path allows the password to enter predictive caches, fix that path before release.
What to verify: Confirm that disabling autocomplete is implemented consistently across platforms and that the app does not rely on a single framework setting that can be ignored by a keyboard, browser, or embedded component.
Common mistake: Teams often test only with the default keyboard and assume the setting is enough. In practice, third party keyboards and alternate sign-in surfaces are where leakage usually survives.
Practitioner takeaway: The control is effective only when the password never becomes learnable by the device input layer, so verify the weakest supported sign-in path, not the best-case one.
Related resources from NHI Mgmt Group
- How should security teams prevent data leakage from web pages and payment forms?
- How should security teams prevent sensitive data leakage through APIs without blocking legitimate access?
- How should security teams authenticate AI agents in enterprise environments?
- How should security teams implement Client ID Metadata Documents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
