If you ran a security review of every WRNexus customer that turned on SSO in the last quarter, you’d find that about 1 in 4 forgot to enforce MFA on the bypass accounts they kept for break-glass access. This is not a SAML problem. It’s a configuration problem, and it’s the same one every product hits.
This is the playbook we walk our customers through during onboarding.
Step 1: Inventory the bypass accounts
When you turn on SSO, your IdP becomes the front door — but every identity product also keeps a small number of local accounts that can sign in without it. These are usually:
- The original workspace owner, created before SSO was set up.
- A “break-glass” account used when the IdP is offline.
- Service accounts used by CI / scripts.
The first job is to list them. In WRNexus:
curl -s "https://api.wrnexus.com/api/workspaces/$WORKSPACE_ID/members" \
-H "Authorization: Bearer $WRN_TOKEN" \
| jq '.data[] | select(.sso_required == false) | {email, role, last_login}'
Anyone on that list can sign in with email + password. If they don’t have MFA, that’s your weakest link.
Step 2: Enforce MFA on those accounts
We let admins require MFA at three scopes:
- Per user — the simplest, but you have to remember to do it for every new bypass account.
- Per role — for example, “every owner must have MFA.”
- Workspace-wide — every active session must have a verified MFA factor.
For the typical org, the right answer is workspace-wide with a 24-hour grace period. New users get a window to enroll before they’re locked out, and you don’t accidentally lock out a teammate who’s mid-meeting.
PATCH /api/workspaces/{id}/security
{
"mfa_required": "all_members",
"mfa_grace_period_hours": 24
}
Step 3: Decide the factor mix
WRNexus supports passkeys, TOTP, and one-time recovery codes. We recommend, in order:
- Passkeys first — phishing-resistant, single-tap, work everywhere modern browsers do.
- TOTP as a fallback — every authenticator app supports it, no phone number required.
- Recovery codes for lockouts — ten one-time codes, generated at enrollment, kept somewhere offline.
We don’t offer SMS as a factor. The reasoning is in our passkeys post; the short version is that SMS adds risk for almost no benefit at the scale most teams care about.
Step 4: Design the recovery flow
The most common security incident from an MFA rollout is not “an attacker got past MFA.” It’s “a real user lost their phone and support helped them recover without verifying their identity.” Decide in advance:
- Who can reset MFA for whom? (Owners only, in our defaults.)
- What proof do they need? (We require a video call + matching company email for enterprise.)
- Is the action logged loudly? (Yes —
mfa.reset_by_adminlands in the audit log and pages the workspace’s security contact.)
Step 5: Test the break-glass
Once a quarter, simulate “the IdP is down for 4 hours.” Walk through:
- Can the break-glass account sign in?
- Does it have MFA enforced? (Yes, please.)
- Does the audit log record the bypass session distinctly from a
normal session? (
session.bypass_idpis the event to look for.) - Is the credential rotated after the drill? (Always.)
If any of these fail, you’ve found a latent finding before the incident does.
A small word on user experience
There’s a tempting design where you only show the MFA challenge “sometimes” — for example, on a new device or a sensitive action. We support that as a fine-tuning, but we set the default to every sign-in for two reasons:
- Users learn the rhythm. They expect the challenge, they have their authenticator ready, friction is constant and low.
- The product is harder to social-engineer when “you don’t normally need MFA for this” is never a true statement.
Tighten it down over time once you have the metrics to back the call.
Wrap-up
SSO without enforced MFA is most of the cost and a fraction of the benefit. The five steps above take about an hour for a typical workspace and make the difference between “we have MFA” and “we are demonstrably more secure than we were last month.”