If you're a Salesforce admin or another privileged user with phishing-resistant MFA enforced, and you can log in fine from a browser but the native Salesforce mobile app won't let you in — you're not imagining it, and it's not a simple "register another passkey" fix. Here's what's actually going on, based on what we found working a live case with Salesforce support.
We're not the first to notice the general pattern of "app breaks, browser doesn't." But the specific mechanisms below don't appear to be documented anywhere else yet, including in otherwise thorough community FAQ roundups on Salesforce MFA issues.
You may see advice suggesting the issue is a hard limit of one built-in authenticator (passkey/security key) per Salesforce account. This is not accurate. Salesforce has confirmed in writing, on our support case, that this is not a real platform limitation. Registering multiple passkeys or security keys on an account works fine in general — the actual cause is narrower than that.
Two distinct mechanisms are in play:
1. A "Login for Admin" option that's tied to login mode, not visibility. We initially assumed this option was just easy to miss. Salesforce support has since confirmed that's not quite right — it's working as designed, and it's specifically tied to which login input mode the app is using:
If you're a privileged user stuck at the verification wall, check your login mode first — this is the actual fix, not just a matter of looking harder.
2. A single-slot limit on Security Keys, specific to the mobile app. Within the native app's login flow specifically, the Security Key (U2F/WebAuthn) slot only supports one active entry at a time. This is different from the general claim above — it's not that you're limited to one authenticator on your account overall, it's that the mobile app's login flow itself only recognizes one Security Key entry. If you're relying on a physical security key and also want mobile app access, that single slot forces a choice unless you route around it another way (e.g., a different authenticator method for the app specifically).
If you manage a Salesforce org with phishing-resistant MFA enforced for admins or other privileged roles, and those users can't get into the mobile app:
UPDATE (September 4, 2026): We're correcting an earlier conclusion in this post.
We originally reported that the mobile app's Security Key (U2F/WebAuthn) slot forced a choice between a physical security key and working mobile app access — that you had to give up one for the other. Salesforce support tested this directly on their end and confirmed that's not accurate. You can keep your physical security key and still get into the mobile app.
The actual root cause was discoverability, not a hard platform limitation. There's a full "Login for Admin" flow in the mobile app that's easy to miss entirely:
1. Open the Salesforce mobile app
2. Tap the gear icon → "Choose Connection"
3. Tap "Production – Log in with username"
4. Tap the gear icon again → "Login for Admin" now appears (it will NOT show up the first time — you have to log in once first, then go back into the same menu)
5. Tap "Login for Admin" → Continue
6. Enter your username and password
7. Tap "Login for passkey"
8. Tap "Use Security Key"
9. Insert your YubiKey (or other physical security key), enter its PIN — you're in
Salesforce confirmed this sequence works the same way on both iOS and Android. Testing was done on devices without MDM configuration, so behavior on MDM-managed devices is currently unconfirmed.
We're also correcting our earlier claim that this was undocumented anywhere. Salesforce does have a release note referencing the "Login for Admin" option (release 262, rn_mobile_admin_login) — it just doesn't spell out this exact click sequence or the security key step, which is why it was so easy to miss in practice.
The original findings below (the two-step gear-icon discoverability issue) remain accurate and are what led us to this fuller answer — we're leaving them in place for context, with this correction addressing the one conclusion we got wrong.