When direct login remains enabled, the application keeps a second authentication path that can bypass the identity provider. That breaks the central enforcement model for access policy and creates a gap between intended governance and actual behavior. It also increases the chance that password resets, weaker credential policies, or brute force attempts can succeed.
What the second login path does to Salesforce access control
When SSO is deployed, the point is to make the identity provider the authoritative gate for interactive access. If direct login still works, Salesforce now has two live entry paths with different policy rules, which means the organisation can no longer assume that the login experience reflects the intended control design. That matters most when access policy, MFA, conditional access, or central audit expectations depend on a single control plane.
The practical break is not just architectural neatness. A second path creates a policy gap: one path may be hardened and monitored, while the fallback path can remain governed by older password rules or separate exception handling. In that state, the application may still be reachable even when the central SSO design is doing everything correctly.
- It weakens assurance that access decisions are consistent across users and sessions.
- It complicates enforcement of passwordless or step-up authentication strategies.
- It creates a hidden exception path that is easy to forget during audits and change reviews.
In a broader identity governance sense, this is a control consistency problem. The rule is only real if the legacy path is removed or tightly constrained, not merely because SSO exists.
For related identity governance patterns, see NHIMG’s Ultimate Guide to NHIs, which covers lifecycle, visibility, and access control discipline across identity types.
Where the risk becomes operationally material
Direct login left enabled usually becomes visible only after something goes wrong, such as a password reset process being weaker than the SSO policy, a user account bypassing federated controls, or an attacker testing the non-federated path because it is easier to brute force or phish. The risk is not hypothetical: two authentication routes mean two sets of failure modes, two sets of logs, and two chances for misconfiguration.
That split also makes incident response less clean. If security teams investigate only the IdP trail, they can miss activity that came through native Salesforce authentication. Over time, this can distort access reviews, mask dormant accounts, and undermine confidence in the organisation’s access model.
If you want a concrete example of how Salesforce access chains fail when token or federation assumptions break down, compare that with Salesloft OAuth token breach and Klue OAuth Supply Chain Breach, both of which show how delegated access paths can become the real point of compromise.
One useful stat from NHIMG’s Ultimate Guide to NHIs is that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. The same logic applies here: zero trust depends on removing uncontrolled alternate paths, not just adding a stronger primary path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | SSO and direct-login paths determine how access is established and enforced. |
| PR.AC-1 — Identity and Access Management Policy and Procedures | Keeping direct login enabled creates an access-policy exception that must be governed. | |
| DE.AE-03 — Anomalies and Events | Dual login paths complicate detection of unexpected authentication activity and bypass attempts. | |
| Recommendation — Restrict authentication paths so access policy is enforced through the intended identity control plane. Document and enforce a single approved authentication path, including exception handling. Monitor for native-login activity that indicates policy bypass or configuration drift. | ||
| CIS Controls v8 | 6.3 — Require MFA for all access to enterprise assets | Direct login can bypass centralized MFA or step-up controls applied through SSO. |
| 6.4 — Restrict administrative privileges | Fallback logins often become privileged exceptions if they are not tightly constrained. | |
| 5.3 — Disable Dormant Accounts | Legacy login paths increase the chance that stale accounts remain usable outside SSO governance. | |
| Recommendation — Enforce MFA on every remaining login path or remove the legacy path entirely. Limit break-glass and admin direct-login access to the smallest possible set of accounts. Remove or disable any account that can still authenticate outside the approved SSO flow. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Assurance weakens when an application accepts a secondary path with different proofing or recovery rules. |
| AAL — Authentication Assurance Level | Two live login paths can produce different authentication strength for the same application. | |
| Recommendation — Align account recovery and authentication assurance so alternate login paths cannot reduce trust. Set the application to the highest required assurance and retire weaker native authentication. | ||
Practitioner Guidance
What to verify: Confirm whether direct login is truly disabled for all production profiles, including service, admin, and break-glass scenarios. If any account can still authenticate outside SSO, treat it as an active policy exception, not a harmless backup.
Decision rule: If the business insists on retaining direct login for emergencies, scope it to tightly controlled break-glass accounts with compensating logging, stronger controls, and explicit review. If not, remove the path entirely so the SSO policy is enforced by design rather than by convention.
What good looks like: There is one intended interactive authentication path, the IdP owns the user journey, and any exception path is rare, documented, and measurable. If teams cannot prove which accounts still support direct login, the control is not mature enough to trust.
Practitioner takeaway: The real failure is not “SSO plus direct login”, it is “policy says one thing while the platform still allows another.” Eliminate the second path or govern it as a formal exception with full blast-radius awareness.
Related resources from NHI Mgmt Group
- What breaks when account recovery still relies on security questions after passwordless login is deployed?
- Who is accountable when a stale password login path is still available after SSO adoption?
- Who is accountable when alternate login methods are left enabled after stronger authentication is deployed?
- Who is accountable when ghost login routes are left enabled after SSO rollout?
