A B2B SaaS with 900 tenants makes SAML single sign-on mandatory for every enterprise-plan tenant after a security review, and local passwords are deleted. Six weeks later an identity provider outage locks about 40 tenants out for three hours and support has no way to help. What did the mandate buy, what did it pay, and what should have existed first?

What it bought

Real security, and it should not be understated. Offboarding moves from a per-application password that may live for weeks after someone leaves to a single revocation at the tenant's identity provider that takes effect in minutes. Session policy, multi-factor requirements and device rules are inherited rather than reimplemented. One row of the security questionnaire stops costing a week of sales engineering per deal.

What it paid

Your login path now depends on 900 identity providers you neither run nor monitor, and availability composes. A tenant whose provider manages 99.9% contributes about 8.8 hours a year of lockout that your status page cannot explain and your on-call cannot fix. Deleting local passwords removed the one recovery path under your own control, which converted a dependency failure into a total loss of access for that tenant.

The second payment is subtler: a mandate applied uniformly ignores that 900 tenants are not one population. A 40-person customer on the enterprise plan may have no identity provider at all, so the requirement either blocks their signup or pushes them to a worse plan.

Which side wins, and what should have existed first

Enforce SSO per tenant as a tenant-level setting, default on for enterprise, and ship two mechanisms before the enforcement flag:

1. A break-glass path you control. A small number of named emergency accounts per tenant, hardware-key protected, disabled by default, whose use pages your on-call and emails every tenant admin within a minute. Auditors accept a logged and alerted break-glass path far more readily than they accept an architecture with no recovery.
2. Session survival. Validate the assertion at login and refresh on the order of every 12 hours rather than on every request, so a three-hour provider outage affects new logins only. Most of the 40 tenants would never have noticed.

When the bill arrives

At the first provider outage, which is when the missing recovery path is discovered, and at the first audit of the break-glass accounts, which is when you find out whether the alerting was real. Both are cheap to prepare for and expensive to improvise.

What would flip this

For a tenant in a sector whose rules forbid vendor-held credentials entirely, the break-glass account is itself the violation. Replace it with a documented two-person recovery that runs through the tenant's own provider administrator, with an agreed contact and a rehearsed procedure, and accept a longer recovery time knowingly. The general rule holds either way: never remove the last recovery path without replacing it with another one you have tested.

Common weak answers

• "Require SSO but keep local passwords as a fallback for everyone." That is the mandate with its benefit removed, because the weakest path is the one attackers use.
• "Make SSO optional and let tenants decide." Defaults decide, not policies. Optional means the enterprise tenants who most need it will not have it.
• "Add a status page notice." It does not restore access, and the outage is not yours to report.