July 16, 2026

Locked Out After Salesforce MFA Enforcement: Recovery Paths, Temporary Codes, and the Break-Glass Account You Should Have Built

Locked out after Salesforce MFA enforcement? The recovery paths, temporary codes, Support realities, and how to build a break-glass admin account for your org.

TL;DR

The phishing-resistant tier for admins and privileged users went live on 1 July 2026 and was never paused. The all-employee tier hit sandboxes from 6 July and has been rolling across production instances since 20 July, staggered over roughly 15 days, so some orgs are being enforced this week.
The main recovery tool is the temporary verification code: issued from the user's detail page, valid 1 to 24 hours, usable multiple times until expiry, and issuable by anyone with the Manage Multi-Factor Authentication in User Interface permission, not just full admins.
A temporary code only answers multi-factor authentication (MFA) challenges. It does not clear device activation challenges from unrecognized browsers, which surprises people mid-recovery.
The genuinely bad case is the org's only admin losing their only phishing-resistant method. There is no self-service path; it is a Salesforce Support case with identity verification and no published turnaround.
Nobody is permanently locked out just for never enrolling. Unenrolled users are forced through registration at login. The hard wall is a privileged user whose registered device is gone.

What You'll Learn

Every recovery path that exists post-enforcement, who can execute it, and what each one cannot do
How to set up delegated MFA recovery so lockouts are a help desk ticket instead of an admin escalation
What actually happens in the last-admin scenario, and the two Support-granted extensions Salesforce documented in July 2026
A Salesforce-specific break-glass account design that survives mandatory MFA, single sign-on (SSO) outages, and the anonymous VPN containment rules
The SSO and integration-account traps still generating lockout tickets three weeks into enforcement

The Problem

The planning phase is over. The admin tier of Salesforce's 2026 MFA enforcement reached production on 1 July, and despite the well-publicized pause of the all-employee tier, that admin tier never stopped. The all-employee tier resumed with revised dates (sandboxes from 6 July, production from 20 July, staggered over about 15 days), which means as you read this, orgs are crossing the enforcement line daily, some without a warning shot. The background on what was paused and what was not is in Salesforce MFA Enforcement Update: What Was Paused, What Still Applies, and the Revised 2026 Dates.

So the question has changed shape. It is no longer "how do we prepare" but "the CFO's security key is in a laptop bag in another country, payroll runs today, and the person who set all this up is on leave." Or, worse: "our only admin cannot log in." The recovery mechanics are documented, but they are scattered across half a dozen help articles, some paths look like they should work and do not, and one scenario has no good answer at all unless you prepared for it in advance.

Common Questions This Article Answers:

How do I get a locked-out user or admin back into Salesforce right now?
What happens if the only admin in the org is the one locked out?
What should a Salesforce break-glass account look like under mandatory MFA?

Quick Answer

If someone is locked out because their verification method is lost or unavailable, the fix is a temporary verification code: any user holding the Manage Multi-Factor Authentication in User Interface permission opens the locked-out user's record in Setup, clicks Generate next to Temporary Verification Code, and sets an expiry between 1 and 24 hours. The user logs in with username and password, enters the code at the MFA prompt, then disconnects the lost method and registers a replacement. The code works multiple times until it expires, but only for MFA challenges; it will not satisfy a device activation challenge from an unrecognized browser. Privileged users must re-register a phishing-resistant method (passkey, security key, or built-in authenticator), not an authenticator app. If the locked-out person is the org's only admin, there is no self-service recovery: it is a Salesforce Support case with identity verification and no published service level agreement, which is precisely why you pre-build a break-glass account with its own hardware key, excluded from SSO, and monitored for any use.

The recovery toolbox, in the order you should reach for it

Temporary verification codes are the workhorse. From Setup, open the user's record and generate the code from the Temporary Verification Code field, choosing an expiry from 1 to 24 hours. Three properties matter operationally. The code is multi-use until expiry, so a fumbled first attempt does not burn it. The user gets an email notification whenever a code is generated for them, which is an anti-abuse feature worth leaving alone. And either the user or an admin can expire it early once the recovery is done, which you should make a standard step.

The recovery sequence for a lost method is: temp code to get in, then disconnect the lost method from the user's Advanced User Details, then register the replacement immediately. Do all three in one sitting. A user who gets in on a temp code and wanders off still has a dead verifier registered and a live code floating around.

Know what the code cannot do. Salesforce's documentation is blunt: the temporary code is for MFA only and is not valid for identity verification when logging in from an unrecognized browser or app. That device activation challenge goes to email. Picture the real lockout: user's phone is stolen, so their authenticator is gone, and they are borrowing a new laptop, so the browser is unrecognized. The temp code answers the MFA prompt, and then the device activation challenge lands in an inbox they may also be locked out of. Corporate email recovery might need to happen before Salesforce recovery. Sequence matters.

One nuance to flag honestly: for privileged users under the phishing-resistant requirement, the practitioner writeups from July describe the same temp-code recovery flow working as the bridge back in, but I have not found a Salesforce document that states explicitly that a temporary code satisfies the phishing-resistant tier rather than only the standard one. Test this in a sandbox with a privileged test user before your runbook depends on it.

Delegate recovery before you need it

The permission that unlocks all of this is Manage Multi-Factor Authentication in User Interface, and it does not require System Administrator. A help desk lead with this permission can generate temporary codes, disconnect lost verification methods (Salesforce Authenticator, security keys, built-in authenticators, one-time password apps), and expire codes.

This is the single highest-leverage move in this post. If only your admins can issue temp codes, every lockout is an admin interruption, and the lockout of an admin becomes circular. Put the permission in a small permission set, assign it to two or three trusted help desk people across time zones, and write the five-line runbook: verify identity by a channel you trust, generate the code with a short expiry, walk the user through disconnect and re-register, expire the code. Salesforce's own guidance, published on the Salesforce Admins blog as MFA enforcement approached, frames break-glass as exactly this kind of people-process: a documented identity verification ritual (a video call with a designated security person, for instance) that authorizes a code generation.

The identity verification step is not ceremony. A phone call to the help desk claiming to be a locked-out executive is a classic social engineering move, and mandatory MFA makes the help desk the softest remaining target. Verify on a known channel, not the inbound one.

The last-admin scenario, and the two extensions Salesforce added

Now the case that keeps solo admins up at night. Every path above assumes someone else with the right permission can still log in. If the org's only admin loses their only phishing-resistant method, there is nobody to generate the code, and Salesforce's answer is unambiguous: contact Salesforce Customer Support.

Be clear-eyed about what that means. There is no published turnaround for lockout recovery cases, and I will not invent one. Support's own access model works against speed here: Salesforce staff can only log into an org through access an admin has granted, and in a full lockout there is no admin left to grant it, so you are into identity verification processes whose specifics are not publicly documented. The May 2026 wave of solo admins frozen by the anonymous VPN containment rules gave a preview: recovery ran through phone cases, and the community chatter was not about hours.

Salesforce did quietly document two relief valves in its July 2026 post-enforcement article (knowledge article 005388907), and they are worth knowing even though both require Support and both lower your security posture. A Phishing-Resistant MFA Extension temporarily downgrades privileged users to standard MFA. An MFA For All Employees Extension lets the org disable the org-wide MFA requirement, making password-only login possible again. Combining both is, in Salesforce's own framing, the lowest security posture available, and neither has a published approval timeline. These are pressure-release valves for orgs in genuine operational trouble, not planning tools.

The real answer to the last-admin scenario is to never be in it, which is what the next section is for.

Building a break-glass account that survives mandatory MFA

A break-glass account is an emergency access account that works when everything else does not. Under mandatory MFA, the old pattern (a shared password in a vault) is dead, because there is no MFA-free login left to attach it to. Here is the design that works now, assembled from Salesforce's recovery documentation and standard emergency-access practice.

The account. A dedicated, named account (break.glass@yourdomain, not a reused human account), with System Administrator or a purpose-built privileged permission set. It costs a license. That is the price of not being on the phone to Support while production is down.

The verifier. A physical FIDO2 security key, registered to this account and stored in a safe or lockbox with documented custody. Register a second key kept in a different location if the org is large enough to justify it. Salesforce's own recovery guidance says every admin should hold at least two registered methods; for the break-glass account, both methods should be hardware you control, not apps on someone's phone. Phishing-resistant method requirements are covered in depth in Salesforce MFA Enforcement 2026: The Admin's Complete Guide.

Keep it off SSO. The break-glass account must log in directly through your My Domain login page, not through your identity provider (IdP). Half the point is surviving an IdP outage or a misconfigured SSO assertion, both of which are live failure modes right now (more below). Exclude it from any SSO-required policies.

Watch the network path. Two traps. Login IP ranges on the profile are good hardening until the emergency happens at 2 a.m. from someone's home network, so if you use ranges on this profile, make sure the documented break-glass procedure includes a network that is inside them. And never let the recovery happen over a consumer VPN: Salesforce's anonymous VPN containment, live since late April 2026, freezes users and revokes OAuth tokens, which would turn your recovery tool into a second incident.

Monitor it loudly. Any login by this account should page someone. Its LoginHistory should be reviewed after every use, the password rotated, and key custody re-verified. If you are capturing the free EventLogFile login events, alerting on this one username is trivial; the setup is in Free Salesforce Event Monitoring: Build a Security Baseline from EventLogFile Without Shield. A break-glass account nobody watches is just a standing privileged backdoor.

Test it quarterly. Retrieve the key, log in, confirm the MFA challenge works, log out, document the test. Sealed-envelope credentials that have never been exercised fail at the worst moment, usually because a session setting changed months earlier.

The SSO trap still filling ticket queues

Three weeks in, the most persistent confusion is in SSO orgs, and it comes down to one fact: Salesforce trusts the claim string your IdP sends, not the authentication that actually happened.

When a user authenticates through SSO, the IdP describes what it did in a claim (the authentication method reference, or AMR). Salesforce evaluates that claim against the enforcement tier. A default Microsoft Entra ID setup doing password plus an Authenticator push sends values amounting to password plus generic multi-factor, which does not read as phishing-resistant, so your admins get treated as non-compliant no matter how strong the IdP-side factor felt. The failure mode is not just a block: users get pushed into registering Salesforce-native verifiers on top of SSO, producing double prompts and a confused help desk.

Related but distinct is the High Assurance session trap. Session security level is a separate concept from MFA compliance, and in default session settings, SSO logins map to a Standard level session. Policies that demand High Assurance, including the report export step-up that went live 1 July, will re-challenge SSO users mid-session even though they did MFA at the IdP. If your users complain about being re-prompted "even though we have SSO with MFA," that is the mechanism, and the gotchas around it are cataloged in Salesforce Report-Export Step-Up Enforcement: The Known Issues and Gotchas Nobody Warned You About.

If you run SSO, the fix lives on the IdP side: configure an authentication method that asserts phishing-resistant values (FIDO2 keys or equivalent), and confirm what your IdP actually sends by capturing a real assertion rather than trusting the vendor checkbox.

Integration accounts: exemption by behavior, not by checkbox

API-only, machine-to-machine logins (JWT bearer flows and similar) remain out of MFA scope. But the exemption is evaluated by actual login behavior. The moment a human opens a browser and logs into that integration account to debug something, it is an interactive login and fully in scope, and if that account carries the privileged permissions integration users tend to accumulate (Modify All Data was convenient at setup, five years ago), it lands in the phishing-resistant tier.

Two consequences. First, audit which integration accounts hold privileged permissions, because those permissions decide the tier; the granted-versus-used method in Salesforce Connected App Least Privilege: Granted vs Used applies just as well to integration users as to connected apps. Second, kill the habit of browser-debugging service accounts. Shared logins are structurally finished under this regime anyway: a passkey binds to a device, and you cannot register one passkey and hand it around a team.

The sandbox refresh footnote that becomes a headline

One more lockout generator, easy to forget until it happens: a sandbox refresh wipes registered MFA verifiers, and SAML SSO configuration comes back disabled. The first login to a fresh sandbox is username and password plus forced enrollment, before SSO is reconfigured. For a full sandbox refreshed by one admin, that admin is the only person who can get in, which recreates the solo-admin problem in miniature. Keep at least two admin users in every sandbox, and make post-refresh verifier enrollment the first step of the refresh runbook, not an afterthought.

Frequently Asked Questions

Q: A user never registered any MFA method before enforcement hit. Are they locked out permanently?

A: No. Unenrolled users are interrupted at their next login and forced through registration on the spot. Since the 13 July post-enforcement changes, passkey registration is prompted by default for all users; privileged users see only phishing-resistant options, while standard users can choose another method such as Salesforce Authenticator or an authenticator app. The hard lockout case is different: it is a user whose registered device is lost and who has no second method, which is why the two-methods-per-user rule matters more than enrollment deadlines ever did.

Q: Can I still use the MFA waiver permission to exempt a user from UI logins?

A: No. The Waive Multi-Factor Authentication for Exempt Users permission stopped exempting interactive logins at enforcement. Post-enforcement, the only exemption-shaped mechanisms are the two Support-granted extensions documented in article 005388907 (a phishing-resistant downgrade for privileged users, and an org-wide MFA disable), both of which lower your posture and neither of which has a published approval timeline. Plan around recovery tooling and a break-glass account instead of exemptions.

Q: How fast will Salesforce Support recover a fully locked-out org?

A: Nobody can honestly tell you, because no turnaround is published, and the identity verification requirements for proving you own an org you cannot log into are not publicly documented either. The May and July community reports describe phone escalations, not quick fixes. Treat Support recovery as the disaster path whose cost you avoid by keeping two admins with two methods each, delegated recovery permissions at the help desk, and a tested break-glass account.

Q: Do temporary verification codes work for the phishing-resistant admin tier?

A: Practitioner reports from the July rollout describe the temp-code flow being used to recover locked-out privileged users, but Salesforce's documentation does not state outright that a temporary code satisfies the phishing-resistant challenge, as opposed to the standard MFA one. Verify it in a sandbox with a privileged test user before writing it into your runbook, and pair it with the rule that the recovered user registers a new phishing-resistant method in the same sitting.

Key Takeaways

Temporary verification codes are the recovery workhorse: 1 to 24 hours, multi-use, issuable by anyone with Manage Multi-Factor Authentication in User Interface, but they do not clear device activation challenges.
Delegate the recovery permission to the help desk now. It is the difference between lockouts being tickets and lockouts being escalations, and it breaks the circular dependency when an admin is the one locked out.
The last-admin lockout has no self-service fix. It is a Support case with no published turnaround, so keep two admins with two registered methods each, always.
Build and test a break-glass account: dedicated user, hardware key in documented custody, direct My Domain login outside SSO, no VPN, loud monitoring, quarterly tests.
SSO does not transfer trust automatically. Salesforce believes the AMR claim, not your IdP's marketing, and High Assurance session policies re-challenge SSO users regardless.

What's Next?

Recommended Reading:

Salesforce MFA Enforcement Update: What Was Paused, What Still Applies, and the Revised 2026 Dates
Salesforce MFA Enforcement 2026: The Admin's Complete Guide
Salesforce Report-Export Step-Up Enforcement: The Known Issues and Gotchas Nobody Warned You About
A Least-Privilege Access Model for the Salesforce Delivery Team for where the break-glass accounts fit in the wider access model
Free Salesforce Event Monitoring: Build a Security Baseline from EventLogFile Without Shield

Action Items:

Assign Manage Multi-Factor Authentication in User Interface to at least two non-admin help desk users and write the five-line recovery runbook, including identity verification on a known channel.
Audit every admin and privileged user for a second registered verification method, and sweep integration accounts for privileged permissions that put them in the phishing-resistant tier.
Stand up the break-glass account this week: hardware key, documented custody, direct login, alerting on any use, and a calendar entry for the first quarterly test.

Every recovery in this post leaves a trail in your login events, and so does every break-glass use, failed challenge, and Support-assisted entry. Keeping that record is what turns a chaotic lockout into a documented incident. Our open-source sf-audit plugin ships sf audit events pull (sf plugins install @cclabsnz/sf-audit), a read-only command that captures the free daily EventLogFile logs, including login activity, before the one-day retention window erases them. And if you would rather have your whole MFA posture, recovery process, and break-glass design reviewed than assembled from help articles, that is what CloudCounsel does day to day.

Resources & References

Written by the team at CloudCounsel — builders of Paywren and Mehfil.