Despite years of public shaming by security professionals, some SaaS vendors only offer Single Sign-On (SSO) in high-end "enterprise" product tiers. By withholding this capability from smaller organizations, they put customers' security at risk. Moreover, they base a pricing strategy on a weak signal and miss an opportunity to lower their own security risk.

Charging for SSO is an understandable but misguided idea.

SaaS pricing strategies strive to account for the value the product offers. The greater the value, the greater the customer's willingness to pay for the product. That's why SaaS products are often licensed based on the number of features, users, devices, or transactions. Such metrics estimate the value and inform the price. These are reasonable and standard practices.

Some SaaS view the need for SSO as a proxy for the customers' derived value and their ability to pay. This is misguided.

SSO--typically powered by the SAML standard--is not a feature that increases the product's value, except for the handful of vendors that sell single sign-on solutions. In all other cases, SaaS customers derive value by using the product's capabilities to get work done better, easier, or faster. The product support for SSO is not such a capability.

Nowadays, SSO--along with the companion user provisioning SCIM protocol--is a baseline requirement even for smaller organizations. They need SSO to integrate the product into their IT and security practices. The need for this functionality signals neither budget availability, nor the value derived from the product. It's a poor basis for market segmentation and pricing strategies.

Withholding SSO increases risks for customers and SaaS vendors.

Too many SaaS vendors enable SSO only for customers who purchase the vendor's highest tier "enterprise" bundle. Smaller organizations that don't need the features of that bundle cannot justify paying for it. As a result, they miss out on SSO and are burdened with higher risk.

Without SSO, a person who needs to use the product has to follow manual steps to set up an account with the proper license, level of access, and account password settings. The organization:

• Cannot ensure that its standard onboarding and offboarding practices are followed.
• Cannot enforce the security measures supplied through its SSO provider, such as two-factor authentication, password complexity, and access anomaly detection.
• Cannot mitigate account abuse or takeover attacks.

By withholding SSO support, the SaaS vendor increases their own risk, too. When the customer doesn't have SSO, the vendor has to rely on the quality of its own code for user authentication. And it has to maintain the customer's user details and access tokens. This broadens the provider's attack surface. In contrast, if the customer uses their own identity provider through SSO integration, the SaaS vendor's responsibility for these security-sensitive areas is significantly diminished.

Encouraging customers' use of SSO is good for SaaS vendors.

By making SSO available to all their customers, SaaS providers business benefits that include:

• Minimize user identity data they have to store, process, and safeguard.
• Make their product more desirable than the competitors that withhold SSO from smaller customers.
• Offer advanced authentication features through SSO providers without having to implement them themselves.
• Improve the accuracy of their pricing model by eliminating an antiquated market segmentation signal.
• Receive positive publicity by explaining how they're helping improve customers' security.

SSO is no longer useful for market segmentation. Making it available exclusively in an "enterprise" bundle offers no benefit to the SaaS vendor and increases the vendor's security risk. This practice is also a disservice to non-enterprise customers because it prevents them from integrating the product with their security and IT practices. Withholding SSO is bad for business and security of both parties.