A balanced approach to premium security features
Not all SSO taxes are created equal. There's middle ground to be found.
Security people often frown upon the practice of charging extra for security features in B2B software. The most infamous example is the “SSO tax” where companies either explicitly charge extra for SSO, or they bundle it into the more expensive bespoke enterprise plans.
The objection is typically focused on guilting or shaming companies into providing a certain set of features to all of their customers. This ethical frame isn’t an effective tool for persuasion.
B2B software businesses have an interesting problem. It is often difficult to quantify the value they provide to a given customer.
Some customers get more value from their software than others. This means that they’d be willing to pay more, and the business selling that software would like to charge them more as a result. Fair enough.
Usage-based pricing is one way to solve this, but not every product has a measurable usage metric that directly correlates with value and willingness-to-pay.
Seat-based pricing is a classic solution. The problem is that the number of people logging into the product doesn’t always correlate to value either. Software used exclusively by the CFO might provide a lot more value to a public company than a Series B startup.
You could ask companies how much money they make, and then adjust your price based on the answer. This would be a pretty efficient solution to customer segmentation, but is typically received poorly.
The premise is that companies make money, and the more money they make the more value they get from improvements. Your tool improves them, so they should pay accordingly. This strikes me as true and reasonable.
It also subjectively feels unfair. Possibly because the same formula applied to consumer products wouldn’t support the same conclusion. Elon Musk doesn’t get more value buying chips at the supermarket than me. On the other hand, SpaceX would get more value from most B2B software than my small consulting business.
Software businesses get creative to find metrics that correlate with value provided, and feel subjectively fair to buyers. When done right, it convincingly mimics usage-based pricing even though the metric doesn’t directly measure usage per se.
In the security world, static analysis tools often charge based on some version of “number of people who contributed to any of your git repositories last month.” This feels like usage-based pricing, because git commits tend to get analyzed by static analysis tools and more contributors probably correlates to more commits.
Instead of charging by number of commits, they insert a layer of abstraction. They don’t want to charge a business with one engineer more because that engineer is committing twice as much, and causing them to run twice as many scans. They want to charge more for companies that make more money.
The number of contributors is a proxy for how much money the company makes. It’s a good proxy too, at least for the kinds of companies that buy static analysis tools1. Clever!
What happens if you don’t have a clever proxy that feels fair and correlates to how much money your customer makes?
Alternatively, what happens if you do have a metric like number of users, but it’s only one dimension of the value you provide. Some customers with 100 users actually make more money than other customers with 100 users.
You’ll probably turn to Good, Better, Best pricing. You segment your customers based on how much money they’re willing to pay you, and identify which features are important to each group, and less important to the groups with less buying power.
This is not a very elegant solution. Even so, it can solve the dual problem of correlating to value provided and feeling subjectively fair; the bigger company is paying more, but they have a longer feature list.
The cost of providing that longer feature list to everyone is usually negligible, but it would remove the feeling of fairness that enables you to close the bigger deals. The art is in finding features that smaller customers don’t really care about, so that you can make the bigger customers feel good without degrading your product for everyone else.
There are at least two ways this can go wrong:
The most valuable features for customers of any size are intentionally paywalled, meaning everyone but the enterprise customers has an artificially degraded product experience (and knows it).
The company is wrong about what smaller customers care about and unintentionally withholds important features, resulting in the same negative outcome for most of their customers.
These failure modes are at the core of the SSO tax debate. Software companies often believe that only enterprise customers care about security features like SSO. Security people at smaller companies believe SSO is important and don’t like important features being artificially withheld2.
These companies aren’t intentionally withholding important security measures from smaller companies. They aren’t saying things like “passwords are only hashed if you’re on the Best plan, don’t forget to upgrade to the salted hash add-on.” There’s a discrepancy between their model of the world and that of the security people.
This isn’t an ethical issue, it’s a matter of recalibrating our models. We can find some security features that are valuable to customers of any size, and some that really only provide value to certain groups.
Keep in mind, the goal here is to make the companies paying more feel like they’re getting a fair shake. The goal is not to generate revenue directly from these features.
Here I’ll provide a bunch of specific examples, and my personal perspective on how they fit into this conversation.
Sign-in With Google
Everyone finds this valuable. It’s amazing for security as well. Google is highly configurable, and even if it’s slightly inconvenient to have some tools on a different provider like Okta and some using Google, it’s a reasonable level of holistic security.
Sign in with Slack, GitHub, etc.
These tools have SSO and similar taxes themselves, so they aren’t as secure as the ability to sign-in with Google. If supported, they should be optional alongside Google.
SAML SSO
Many companies put this behind the Best plan but the customers in Better want it too. It’s reasonable not to include it in the Good tier though.
Configure available login methods
Any time you support multiple login methods, you should give administrators the ability to enable or disable them. Otherwise it negates the benefits of having secure options, because the bad options are still available to attackers. This isn’t a good candidate for gating behind higher tiers.
SCIM Provisioning
Fewer companies in Better want this than SAML SSO. You can probably get away with gating it in the Best tier, and privately granting any Better company’s request for this feature to be turned on. Nothing wrong with providing it to both tiers explicitly though.
Single Logout
This is a feature that isn’t as commonly implemented. Any tier with SAML SSO should include this as well if you do build it. Make sure to list it as a separate, adjacent feature to capitalize on your work.
Audit Trail
Companies in the Better and Best tiers may care about this during purchasing. Companies in the Good tier will care about this if something unusual happens to their account.
You could leave this off of the Good tier, but still record all of the events. You probably want to do this anyway so that someone upgrading can see historical data as well. If a customer suspects an issue and writes in, support should have the ability to enable the feature for a month.
A stronger way to segment within this feature is to increase the retention period for each successive tier. One week for Good, two months for Better, three years for Best. Those numbers are arbitrary, but you get the idea.
Audit Trail Export to SIEM
This is a great candidate for Best-only customers. Customers below Best have a SIEM, but they’re far less likely to be in a position to use the data from all of their SaaS apps. This is just lower on their priority list than other SIEM tasks.
IP Allowlisting
If you offer the ability for customers to set an IP allowlist, it’s possible to gate this behind Better or Best, but it’s another one you should flex on if a company requests it. It does risk generating some negative feelings though, so the safe move would be to offer it to everyone.
Role Based Access Control (RBAC)
Your application should have some concept of roles in all tiers. This depends on the specifics of how people typically use your application. Generally though, not everyone should be able to do everything.
You can allow enterprise customers in the Best tier to build their own roles with customizable permissions.
Passwordless (WebAuthn)
WebAuthn provides phishing-resistant multi-factor authentication. It also lets customers login without passwords (or magic links).
This is just a far better login experience in addition to being much more secure. This should be the standard for all products, everywhere.
Okay, with all of those examples, what do our tiers look like?
Good
Sign-in With Google, Slack, GitHub
Configure available login methods
Audit trail with 7 days of history
IP allowlisting
Passwordless WebAuthn
RBAC with built-in roles
Better
Everything in Good
SAML SSO (Single Sign On)
SAML SLO (Single Logout)
Audit trail with 60 days of history
Best
Everything in Better
SCIM Provisioning
Audit trail with 3 years of history
Export audit trail to SIEM
Customizable RBAC
Reasonable!
If you listen to feedback from customers and adjust over time, you’ll maintain a segmentation that roughly approximates your customers' mental models.
There will always be edge cases. Some small companies care a lot more about security than companies an order of magnitude larger. Since these features are being withheld arbitrarily, it’s understandable that they may be frustrated with you.
You can bundle advanced security features together as a separate line item in your sales process and make them available to anyone who wants it for an additional fee. Then you can offer it as included for the higher tiers.
For example:
Advanced Access Security
SAML SSO (Single Sign On)
SAML SLO (Single Logout)
Audit trail with 60 days of history
SCIM Provisioning3
Now, the Better and Best plans can have a big line item that says Advanced Access Security is included.
The shelf price of this package should be high enough that Better and Best companies feel like they’re getting a fair deal by having it included. It doesn’t have to be high in practice for the Good companies though.
You can aggressively discount the Advanced Access Security product for smaller companies that care a lot about security, while maintaining a sense of fairness among all of your customers. You could even have a note on your pricing page saying small businesses are eligible for large discounts on the package.
The risk is that some customers will see all of this math as advanced tomfoolery and be wary of your pricing model. You can’t please everyone.
I wonder if an increase in AI generated commits will break the assumptions of this model.
I’ve said “security people” a couple of times now. In the context of this essay it can mean someone who is responsible for security full-time, or security-minded people in general.
In this example I’ve included SCIM provisioning in the package, but I didn’t include it in the Better plan earlier. Ultimately where you choose to include it depends on what makes the holistic pricing model feel subjectively fair to your particular customers and prospects.