SSO1 SSO Not Enforced

What this means

SiteShadow flagged cases where SSO is configured but not actually *required* (for example: users can still log in with passwords, local accounts remain active, or certain flows bypass SSO).

Why it matters

• Policy bypass: a "must use SSO" org can still be compromised via password reuse/phishing.
• Offboarding gaps: if local credentials still work, disabling SSO access doesn't fully remove access.
• Weaker protections: SSO often brings MFA, conditional access, and device policies, bypasses remove those.

Safer examples

1) Require SSO for certain domains/orgs

• Enforce SSO for all users in an org (or for specific email domains).
• Disable password login once SSO is enforced.

2) Block local-password fallback after SSO enablement

If SSO is enabled for an org, do not allow "forgot password" to reintroduce local auth.

3) Enforce strong auth on sensitive flows

Admin dashboards, billing, role changes, and API key creation should require the strongest auth path.

How SiteShadow detects it (high level)

• Looks for auth flows where multiple login methods exist and SSO enforcement conditions are missing or inconsistent.
• Flags "fallback" routes that re-enable password auth in SSO-enforced contexts.

References

• OWASP Top 10: https://owasp.org/Top10/

---

← Back to Vulnerability Library