Designing a Safer SSO Setup Without Locking Users Out

B3Networks Admin Portal

UX designer

2026

Redesigning authentication settings for B3Networks: preventing an SSO lockout risk and reorganizing the page around what admins actually need to do.

Overview

Security Center is where organization administrators manage password policies, session timeouts, Single Sign-On, and passkeys.

Because these settings apply to the whole organization, a configuration mistake can affect every user at once.

While reviewing the proposed Microsoft SSO flow, I found a potential lockout path. Administrators could disable password login before SSO was fully configured, leaving the organization without a working way to sign in.

My goal was to prevent that state from happening and make the relationships between authentication settings easier to understand.

Focus: Authentication settings, SSO setup, password coexistence, and information architecture

Current State: SSO Works Independently

In the existing Security Hub, Microsoft SSO, password policies, and session settings work independently.

Password login always remains available. There is no option to make SSO the only login method, so enabling SSO does not affect how password login works.

The existing page also presents these settings as separate policy categories. While this matches the system structure, it does not clearly show how the different authentication methods relate to one another.

The Request: Connect Password Login to SSO

The new requirement was to let administrators disable password login once Microsoft SSO was enabled.

This would allow organizations to require all users to sign in through Microsoft instead of maintaining a separate password login method.

The initial proposal introduced a toggle called: Allow password login alongside SSO

The toggle was placed under the Password Policies tab and appeared as soon as Microsoft SSO was turned on. Warning copy explained that turning it off would make SSO the only available login method.

UX ref from PM:

The UX Risks in the Initial Proposal

While reviewing the complete setup flow, I found three main issues.

SSO enabled did not mean SSO ready

After turning on Microsoft SSO, the administrator still needed to complete and verify the configuration.

The password toggle appeared before this setup was finished.

The warning explained the risk but did not prevent it

The administrator could still disable password login before SSO was working.

The design depended on the administrator reading and understanding the warning at the right moment.

The toggle was separated from the setting it depended on

The password toggle lived under Password Policies, while the Microsoft SSO setup happened in another tab.

To understand the full effect of the setting, the administrator had to move between two different sections.

Together, these issues created a possible lockout path:

The administrator enables Microsoft SSO.
The password login toggle appears immediately.
They assume SSO is already active.
They disable password login.
The Microsoft SSO setup is still incomplete.
Neither login method works.

The issue was not obvious when looking at each screen separately. It only appeared when I followed the sequence an administrator could realistically take.

UX Recommendation

Instead of adding more warning copy, I proposed changing both the interaction logic and the page structure.

1. Make the unsafe action unavailable

The Allow password login alongside SSO option would only appear after Microsoft SSO had been successfully configured and verified.

Until then, password login would remain available by default.

The revised flow became:

Enable Microsoft SSO → Complete and verify setup → Choose whether password login remains available

This created three clear states:

SSO state	Password login	Password coexistence option
Not enabled	Available by default	Not shown
Setup in progress	Still available	Not shown
Configured and verified	Available	Shown

This shifted responsibility from the administrator to the product. Admins no longer had to judge whether SSO was ready. The system only presented the option when it was safe to use.

2. Centralize related policies on one page

The initial proposal separated Single Sign-On, Password Policies, and Session Policies into different tabs. This made the page feel fragmented, even though several settings were closely related.

I replaced the sub-tabs with one Security Policies page containing four collapsible sections:

Single Sign-On
Sign-in with passkey
Password Policies
Session Policies

This structure gives administrators a complete overview of all security settings while allowing them to focus on one section at a time.

When a section is expanded, its settings are contained within a clear visual boundary. Other sections remain collapsed, reducing distraction and making a settings-heavy page easier to read.

Compared with the tab-based layout, the new structure provides three key benefits:

Better focus and scanability

Each policy has its own collapsible section. Administrators can focus on one set of settings at a time while still seeing the names and status of the other policies.

Less context switching and clearer dependencies

Related settings stay on the same page. Single Sign-On appears before Password Policies, and the password coexistence option is placed directly inside the SSO section once setup is verified.

Progressive and scalable structure

Detailed settings only appear when a section is expanded, keeping the page compact without hiding available features. Future providers such as Google or SAML can also be added within the Single Sign-On section without changing the overall structure.

Outcome

The potential lockout path was identified and removed before development.

The revised design keeps password login available throughout SSO setup and only reveals the option to disable it after SSO has been successfully verified. It also places dependent settings in the same context, making the relationship between SSO and password login easier to understand.
The new collapsible structure replaces a fragmented tab-based layout with a page that is easier to scan, easier to navigate, and flexible enough to support future authentication methods.

There was no production incident data because the risk was caught during the design stage. The main outcome was preventive: an unsafe configuration became unreachable through the interface.