What happens when you tap a password field
You tap a login field and your keyboard vanishes, replaced by Apple’s. Nothing failed. iOS made a decision on your behalf before your keyboard could load.
- The app marks the field as secure text entry.
- iOS presents the system keyboard for that field.
- Your third-party keyboard is not shown and receives no keystrokes.
- You move to a normal field and your keyboard returns.
The important part is the third step. The keyboard is not asked to behave. It is not in the conversation, so there is nothing to log even if the code wanted to.
The same rule covers the device passcode screen, which never uses a third-party keyboard at all. If you have wondered why your custom keyboard never appears at the lock screen, that is the reason.
The security model in plain terms
A custom keyboard on iOS is an app extension: a small piece of software the system loads inside another app’s text-entry flow. It runs in a sandbox with tight limits, and by default it has no network access.
- The extension sees the text of the fields it serves. That is its job.
- Without Full Access it cannot reach the network or a shared container.
- With Full Access it can call a server, which is how AI features work.
- Secure fields are removed from its reach whether Full Access is on or off.
Put those together and the design makes sense. A keyboard sees your keystrokes and can be granted network access, so credentials must never enter the same path. Apple splits the risk instead of trusting every vendor in the App Store to behave.
You cannot audit a keyboard from the outside. You cannot see what it sends, and an update can change behavior after you install it. A restriction the operating system enforces holds regardless of what any vendor promises in a privacy page.
Which fields are restricted
The restriction follows how a field is declared rather than the app’s category, which is why coverage feels uneven between apps.
| Field or context | Third-party keyboard | Why |
|---|---|---|
| Password fields | Never shown | Marked as secure text entry |
| Device passcode screen | Never shown | System-level entry |
| Card number fields | Usually not shown | Declared as sensitive payment input |
| Two-factor code fields | Varies by app | Depends on the field type used |
| Managed work devices | May be blocked entirely | Device management policy |
Because coverage depends on the app’s implementation, treat the fallback as strong protection with edges rather than a promise about every field you will ever meet. A poorly built app can mark a sensitive field as ordinary text.
On a managed work phone, an administrator can disable third-party keyboards for everything. If your keyboard works at home and not on the work profile, check policy before you file a bug.
Why the tradeoff is worth the annoyance
The inconvenience is small and the risk it removes is large. A keyboard with network access that also saw password fields would be a keylogger with distribution, and it would only need one bad update or one breached vendor.
- You cannot inspect what a keyboard sends after you install it.
- A vendor can be acquired, breached, or change its policy.
- Credentials are reused, so one capture spreads across accounts.
- Nothing about typing a password benefits from a smarter keyboard.
Password entry is also the moment you least need help. There is no rewrite pass, no suggestion, no dictation that improves typing a stored secret. Losing custom keyboard features there costs you nothing real.
The design also protects vendors. A keyboard that never touches credentials is a keyboard whose worst-case breach does not include your bank login, which is a better position for everyone.
What it means for your daily workflow
Once you know the rule, the friction mostly disappears because you stop trying to type secrets by hand.
- Use your password manager’s autofill or a passkey with Face ID.
- Let Apple’s keyboard handle the field and expect yours back afterwards.
- Keep two-factor codes in an authenticator app with autofill where supported.
- Never dictate a password out loud, in any app, on any device.
That last point catches people who have grown comfortable with voice input. Speaking a credential exposes it to anyone nearby and puts it into whatever text field, history, or draft it lands in.
If a login flow forces manual typing, take the extra five seconds. That is the only cost, and it happens a handful of times a week.
How password managers fill fields without a keyboard
Autofill works in secure fields because it is a different mechanism with a different permission. A password manager registers as a credential provider, so iOS asks it for a matching login and places the value into the field directly.
- The credential provider is separate from the keyboard extension.
- It is invoked by iOS for that field, and it does not see your other typing.
- Face ID or Touch ID authorizes the fill before anything is inserted.
- Passkeys go further and never produce a typed secret at all.
That is why a password manager can do something your keyboard cannot. The system hands one credential to one extension for one field, rather than exposing a stream of keystrokes to software that stays loaded across every app.
Set autofill up properly once and the restriction stops registering as friction. Enable your manager under Settings > General > Autofill, add passkeys where a service supports them, and the logins that used to interrupt your keyboard become a glance at the camera.
How to evaluate an AI keyboard given all this
The field restriction handles credentials. Everything else you type is still worth a decision, and these are the questions that produce useful answers.
- Which features run on the device and which call a server?
- What exactly is sent when a server feature runs: the sentence, the whole field, or more?
- How long is that text kept, and is it used to train models?
- What still works with Full Access off or with no network?
- Can cloud features be turned off while typing keeps working?
Auri Keyboard needs Full Access for its network features, states that it cannot access password or credit card fields, and offers local speech to text alongside cloud voice typing, which is the default on iPhone. Those are the switches to look at before you write anything sensitive on a phone.
For text you would rather keep off any server, a Mac is the better place. Auri Voice keeps recognition and text cleanup on device by default and inserts into any app through a shortcut, and it works independently of the keyboard.
FAQ
Is my keyboard broken when it disappears at login?
No. Apple’s keyboard appears because the field is marked as secure text entry, and iOS enforces that for every third-party keyboard. Your keyboard returns as soon as you move to a normal field.
Can I turn the restriction off?
No, and that is the point. There is no setting, entitlement, or permission that lets a third-party keyboard into a secure field. Anything advertising otherwise is describing something else, like autofill from a password manager.
What does Full Access actually allow?
Full Access gives the keyboard extension network access, which server-side features need for grammar, rewrite, translation, and cloud voice typing. It does not grant access to secure fields. What matters is what the vendor sends over that network and how long they keep it.
Could a keyboard log everything else I type?
A keyboard extension receives the text of the fields it serves, which is why Full Access deserves scrutiny. Judge a vendor on whether processing is local, what leaves the device, retention, and whether cloud features can be turned off.
Does the restriction cover credit card fields?
In many apps and browser autofill contexts, yes, because those fields are marked in ways that trigger the fallback. Coverage depends on how each app declares its fields, so treat it as strong protection rather than a guarantee for every field in every app.