The sign-in policy, and not locking yourself out
Requiring SSO turns off passwords, so the platform makes you prove it works first.
Last updated September 22, 2026
Requiring single sign-on turns off password sign-in and password reset together. If the connection looks healthy but does not actually work, nobody gets in, including the owner. This is the most common way an organization strands itself, so the platform will not let you do it casually.
What raising the policy requires
Three things must be true before you can require SSO: an enabled connection exists, it passes a live validation check, and at least one person has completed a real sign-in through it recently. Testing is not enough on its own, because a test exercises a different path than a person signing in does.
What is protected
While the policy depends on it, the last enabled connection cannot be disabled or deleted. Relaxing the policy is never blocked, because relaxing it is how an administrator recovers.
If you are stranded anyway
Your Pytheus contact can clear a stranded organization's policy. It requires a written reason, it touches only the policy, and it is recorded in your own audit trail as well as ours, so you can see exactly what was done and why.
Next: Rotating credentials.