Keep a Back Door
Module 5 of 6 in the chapter Single Sign-On: The Browser Is the Broker, chapter 4 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: When single sign-on breaks, how do the people who can fix it get in?
The day it breaks
Section titled “The day it breaks”Module 1 ended with the catch: one front door for everything means that door matters much more. Here’s what that looks like on a bad day.
The identity provider is down. Or its certificate expired last night and nobody uploaded the new one (module 4). Or someone changed a setting in the single sign-on configuration and saved it. Or the clocks on the two servers drifted apart. Every SAML message carries times, “not before” and “not after”, and if one side’s clock is wrong, the other side refuses messages that look too early or too late. Whatever the cause, Priya can’t sign in. Neither can anyone else who uses single sign-on. And if the admins sign in the same way, they can’t either.
If single sign-on breaks, you need somebody to go in and fix it, and the only way to fix it is to have what’s called a local login: a way into Salesforce that doesn’t go through the identity provider at all.
One of those I’ve seen myself: the clocks. One side issued its SAML message, and the other side wouldn’t accept it, because by its own clock the timestamps were wrong. Nothing was down. The messages were simply refused. So make sure the system clocks are aligned. Chapter 6 shows where those times live in the message.
Who must have a local login?
Section titled “Who must have a local login?”Here’s the question I ask every class. If single sign-on breaks, which accounts must still have a local password?
The admins. Make sure the admins have local passwords, not only single sign-on, and make sure they can get to a Salesforce login page that takes a password. You need to know these back doors are there before you lock the front door.
It helps to remember one thing from module 2. Even with single sign-on, Salesforce still has its own identity store. Every user still exists in Salesforce, with a username. What the identity provider takes over is the proof. So keeping a local login for a few admins isn’t a hack. It’s a decision about who can still prove who they are to Salesforce directly.
The switch, and who it leaves out
Section titled “The switch, and who it leaves out”By default, when you set up single sign-on, users can still log in with a Salesforce username and password too. Salesforce’s words: “By default, when you set up single sign-on, users can log in from the SSO provider or from Salesforce.”
Most companies want to stop that, so nobody can get around the identity provider’s MFA and its rules. The setting is Disable login with Salesforce credentials, in Single Sign-On Settings. But notice how Salesforce built it. It doesn’t apply to everyone. It applies only to users who have a permission called Is Single Sign-On Enabled, given through a permission set.
That’s your back door, and Salesforce says so itself: “We recommend that you don’t require SSO for Salesforce admins so that they can still access Salesforce to respond to SSO outages or other issues.” So give Is Single Sign-On Enabled to everyone who should use single sign-on, and keep it away from the admins who hold the back door.
Three more ways the door can close
Section titled “Three more ways the door can close”There are three other settings that can close the back door without anyone noticing. Check each one before the bad day, not on it.
The My Domain login policy. In My Domain settings, Prevent login from https://login.salesforce.com (opens in a new tab) makes everyone log in through your org’s own My Domain address. (In a sandbox, it’s test.salesforce.com.) That’s a sensible setting. But in 2024 I showed a class how to find a setting to block login.salesforce.com, and today this is where it lives: one setting for the whole org, in My Domain. It doesn’t take away the admins’ password. It moves them to the My Domain login page. So make sure every admin knows that address and has it saved.
The Login Form. My Domain also decides what the login page shows: the identity provider’s button, other login services, and the usual username-and-password form. If someone clears the Login Form checkbox, the password form disappears from the page. Salesforce’s own fix, for users who need it: add ?login to the end of the login address, and the form comes back. Write that down where the admins will find it.
Single sign-on as the only way in. If single sign-on is the only login method on the page, Salesforce sends everyone straight to the identity provider (module 3). That’s a smooth day for Priya. For admins, it’s one more reason to know ?login and the My Domain address. Salesforce’s own advice, for a side effect of this setup, is to add Username-Password as a second method, and it notes that adding it “does not require users to use it.”
The back door is still a door
Section titled “The back door is still a door”A back door that anyone can walk through isn’t a back door. It’s a hole in the wall. So protect it.
- Few people. Two or three admins, named, not every admin.
- Strong proof. Salesforce requires phishing-resistant MFA for admins, on direct logins too, and each of them needs a backup method in case they lose the first (chapter 2, module 2).
- Watched. These logins should be rare. Look for them in Login History (chapter 2, module 5), and ask about any you didn’t expect.
Test with a user, not an admin
Section titled “Test with a user, not an admin”When I set up single sign-on with a class, I keep the admins out of it. We create a normal test user in both orgs, Priya in this course, and test single sign-on with her. The admin keeps a direct login the whole time, so if the configuration is wrong, the admin can still get in and fix it.
Salesforce gives the same advice when it’s time to replace a single sign-on certificate. Before you start, have a “backup admin account with username/password authentication available.”
The checklist
Section titled “The checklist”Before the day you need it:
- Is Single Sign-On Enabled goes to the users who should use single sign-on, and to none of the admins who keep the back door.
- At least two admins can log in directly, with phishing-resistant MFA and a backup method.
- The My Domain login address is written down where those admins can find it, whatever the login policy is.
- The Login Form setting is known, and so is
?login. - It’s been tested. Someone has actually logged in the back way, recently, on purpose.
What’s next
Section titled “What’s next”You’ve seen the whole relationship now: one identity provider, a browser that carries everything, a certificate installed in advance, and a back door. But what exactly is the browser carrying? What’s inside a SAML response, where do “not before” and “not after” live, and what does Salesforce check before it lets Priya in? Module 6: what the browser carries.
What an architect decides here
Section titled “What an architect decides here”- Who keeps the back door: two or three named admins, without Is Single Sign-On Enabled.
- How it’s protected: phishing-resistant MFA with a backup, and watched in Login History.
- How people find it: the My Domain address and
?login, written down. - How it’s tested: on a schedule, before anyone needs it.
Explore
Section titled “Explore”- Require Users to Log In with Single Sign-On (SSO) (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Set the My Domain Login Policy (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Users with SAML SSO Cannot Log In at login.salesforce.com or Custom URL (Login Form Checkbox Deselected in My Domain) (opens in a new tab) (Salesforce Help, 2026-06-08; checked 2026-11-07)
- Users Redirected to www.salesforce.com After Logout When My Domain Is Configured with a Single SSO Authentication Service (opens in a new tab) (Salesforce Help, 2026-08-18; checked 2026-11-07)