Ask HN: Why isn't there a backlash around charging for security features?
There is a very common (dark?) pattern I see employed by practically everyone in the industry, instead of charging for differentiating features, we seem to accept that it's ok to charge for security features as premium features in the pretense that these are "Enterprise Features". I am not here to name and shame but you know how it works. Role Based Access Control, SSO integration, API access to audit logs, MFA are presented as "premium enterprise features", why isn't there a bigger backlash? Why is this practice not pushed back by everyone? The startup I'm building, we are committing to provide SSO/SAML/OIDC, audit logs, advanced RBAC etc for free for everyone, we want people to pay for actual differentiating features. Am I missing something here?
69 comments
[ 3.6 ms ] story [ 172 ms ] threadFor example, your healthcare software incorrectly exposes Patient Health Information (PHI) due to a bug in your RBAC. You don't just ship a patch that fixes this, you are liable for the PHI exposure up to $150k per PHI exposure...
How do you prevent this? You charge more for these features and use that money to purchase liability insurance.
"Needs SSO integration" is one of the cleanest market seg signals available to a SAAS startup. Customers that really want SSO integration are overwhelmingly large enough to stop obsessing about SAAS seat costs. What's better, this extremely desirable cohort of customer prospects is increasingly mandated, as a cohort, to seek SSO integration.
A frequent cynical (and, justified) question asked about new services appearing on Hacker News is "where do they make their money?". You know, "if you're not the customer, you're the product"? Well: this is one very straightforward way companies manage to have generous free or cheap tiers.
We're not going to charge extra for SSO integration; we're SAAS customers ourselves, and the sso.tax is, obviously, super annoying. And you can take this idea way too far --- as you would be if you charged extra for 2FA. But "dark pattern" doesn't mean "everything we find super annoying in business". I absolutely understand why SAAS companies tax SSO.
You don't mention all advantages to the SAAS company to have their customers using SSO, though: improved customer stickiness, happier end users, and no more liability for stored password hashes. Charging for SSO is false economy.
Login with Google etc. achieves most of those advantages, while still leaving SSO against an organisation's SAML provider etc for enterprise.
At least we agree on the baseline of not charging for 2FA.
The fact is, it's very difficult to fight "shadow IT". SaaS companies penalizing early adopters for access to acceptable security only incentivizes employees, at large and small companies, to bypass IT vendor management and security policies. And once you've had to make an exception for "the CROs favorite SaaS tool", it's going to be fair game and an uphill battle to taken seriously.
As an industry, as a society, we need to make some of these security features easier to implement, easier to adopt, and not a penalty.
As I noted in a sibling comment, I also think that running a protection racket is lazy product management and marketing.
Frankly, if you are telling me that I have to pay extra for protection, that tells me that you don't take security seriously, since you are basically operating an insecure environment as your default practice.
It sounds like you're just not happy that SSO gets used for market seg. I'm not "happy" about it either. That doesn't make it a dark pattern or an indicator that companies "don't take security seriously".
It's not just that my feelings are hurt, it's that I personally view this as a societal issue. Our tremendous reliance on this internet thing, and our lax day-to-day security practices and expectations, puts us at serious risk--individually and as a society.
You regularly post about the overcomplexity of security protocols and their poor implementation. I'm sure you're more than just "unhappy" about those things.
SSO shouldn't be hard to implement relative to, say, MFA--especially since so many use SMS. Auditing should be incredibly straightforward to implement, especially if you are using tools like Rails or Django.
But we aren't having a discussion amongst the general population. We're having a discussion amongst people who plan, design, and build these systems and who, as professionals and practitioners, society looks to for input on policy choices.
The fact that SSO--and let's be honest, it'd be nice if it weren't always SAML, just like it'd be nice if Google/et.al. didn't force us all to use JWT--is so broadly taxed should be viewed the same way we used to view storing passwords in plain text or not supporting 2FA.
Individuals and companies will do what makes sense for their bottom line in the short-term, even if it is lazy or even self-defeating in the long-term.
But if it is bad for society, then it's a societal issue and requires society to intervene.
They're very easy to implement - it just costs money. If you've got enough employees that you need SSO, it's time to move off the free tier.
As an industry, as a society, we need to stop expecting developers to deliver services to huge multinationals for $0
Besides, SSO is a major convenience. Assuming that SSO = large company is a flawed perspective, although, I understand the reasoning you're conveying. I believe, however, that only very small companies (less than four people) can easily avoid SSO, because it is complicated to deal with on/off-boarding employees, SSO helps.
And I agree with OP in most regards, for most services, advanced security controls should be available. I think it is far more likely that most companies segregating their security features are not secure by design, so the functionality they're offering is poorly implemented, and by restricting access they limit the amount of support they need to provide to those features.
Again: it's obviously an inconvenience, or the sso.tax wouldn't be super annoying. I would of course prefer it if SSO were free everywhere.
This is another comment that makes insinuations about the competence of companies that tax SSO. But you can just look at the sso.tax site and see several companies with world-class security teams, so that argument doesn't work so well.
Is there a link between the market for security engineering talent and the leverage that the security engineers have within their organizations? Are you seeing anecdotes play out in the industry that inspire hope that the balance of power in business decisions is shifting toward the engineers?
A literally equivalent way to look at the SSO tax is "the no SSO rebate". As a security engineer, I'm not prepared to launch a moral crusade over SMBs who don't adopt SSO on all their random SAAS apps; meanwhile, we're SSO on everything, and it costs us extra money, and that's life in the National Foosball League.
If it's actually true that we have crossed the point where it is no longer prudent for companies to segment their customers this way, then there are a whole lot of companies making unsound business decisions, and the problem will solve itself.
HITRUST is the standardized audit for companies that care about HIPAA/HITECH, but your argument certainly holds there as well (everything you can say about SOC2 is just multiplied by an order of magnitude or two for HITRUST).
Let's take SSO for example. In the early days of Okta/Ping/OneLogin - Lets call it 2015. SAML was a big cost add-on to almost every service. At the time most services (with a few exceptions like Zendesk and Salesforce) charged you a decent proserve fee for setting it up, because it was a manual setup process for them. It was hard/time consuming/etc.
For the time, that makes total sense. But since then SAML libraries and usage have matured. You can write less than 100 line python/flask application that supports SAML. So while SAML was, at one point, actually expensive (by person hours, both engineering and PS) to implement ... it no longer is. Companies are just continuing to charge for it in most cases... because they can get away with it.
The real problem with SSO in general, at least currently, is that it's not viewed as a necessity for all businesses (even though it is). A company a decade ago could sign up for the cheap Slack edition and be happy with that through 100+ employees. Now a company of 5 or 10 may already have SSO and therefor need to goto a Slack edition that is twice as expensive - simply for that one feature.
Remember when bulk hosts segmented on HTTPS? Want to host dog.example, cat.example, and sheep.example? That'll be $10 per year. Oh you want SSL for them? That'll be $50 per month per domain. Sure, you get better performance and whatever else, but there is no option to go without those and just pay $10 per year for the basic service but with HTTPS.
They had very similar excuses to what you've offered, it's a clear market signal, it actually does cost us money to do this (but nowhere near what they were charging usually, these might be "$100 SSL certificates" but if the bulk host wasn't getting a good deal directly they were buying from a "discount" reseller for less than sticker price anyway), we can subsidise our cheap offering knowing serious customers will buy the expensive one and so on.
If there are people out there who have less security because that cost less money when in reality it was just a feature toggle that's a bad thing.
Security is different the same way safety systems are different. You don't really want the investigators of a child's death to conclude that the $500 extra "Premium" version of your product had safety interlocks that would have prevented the death, shame the "Family Economy" version lacked those. And likewise, when investigators conclude the successful attack on Customer X was because they had your "Basic" package lacking the optional security features for "Premium" customers, do you think other customers buy Premium or do they leave for a product which doesn't have your terrible press?
The really nice pies I sometimes buy have a nicer pastry, and a richer gravy, but in common with the cheaper pies I also sometimes buy they don't have shards of metal or glass, expired or diseased ingredients, and so on. The Premium product is nicer but the cheap product is up to a minimum standard for safe food, and I feel like way too many software products aren't reaching a minimum standard for secure software.
SSO is the one feature a SaaS company can use to force people that can afford it up to higher tiers when their usage remains low but the the value to the customer is high enough to justify the tier increase because of a mandated SSO requirement etc.
In your model, the enterprise version is a marginal cost. Customers get 3/4 of the product for free, and decide whether they want they want to pay for the other quarter. A lot of people won't, or they'll write a batch script to replicate the single feature they want, or etc.
In the "restricted security features" model, customers either get 0 features because security won't let them deploy it, or they get all the features.
It also encourages startups to use the product since it's free... for now. A 3 person startup doesn't really need SSO or RBAC. They eventually will, as they grow, and they'll already be locked in.
I also don't agree it's a dark pattern. Implementing and storing audit logs takes up time and space, so it makes sense to charge more for them. Having your engineers spend time on meta-features like SSO rather than the next product roadmap feature has an opportunity cost so you should get some cash out of it to balance things.
I'm just thinking of a standard B2B SaaS context. If you're in the security field selling to security professionals then maybe these features are table stakes?
MFA should be the default. Because one day, Bob in sales is gonna click that link and enter his password that 850 other sites use.
Not everyone is using AWS cognito or auth0, and thus has to add on SSO to an existing authentication method.
Even if you are using Cognito or Auth0, its still annoying to implement in their systems, and THEY charge you additional for it as well.
Add on to that its a clear segment of customers, it really makes sense to charge more for it.
Many companies take an open core approach but license some features (maybe security related, management, scalability, etc.) with proprietary licenses and charge for them.
Part of this is because traditional open source licenses tend to assume all time and resources are donated freely. It’s hard to sustain one or more people in terms of money, and some run the risk of another company reusing your source in their product.
I think some viable alternate approaches to earn money through open source would go a long way towards avoiding open core approaches. But until that happens companies will do what they need to in order to keep revenue flowing.
2. I HAVE seen a dark pattern, particularly in “Freemium” software, where security primitives like encryption and access controls are upsells. If you expect me to store my data in your SaaS platform then I believe you owe it to me to provide baseline security controls. Put another way, it’s not freemium, it’s “not-fit-for-purpose trialware” if basic security controls aren’t provided.
Respected infosec Podcaster Patrick Gray had a show recently about this topic exactly:
https://risky.biz/soapbox56/
There are other ways to do segmentation, but they require actually understanding your customer and what they need in order to develop a value proposition.
People will complain about how hard it is to implement. And that's a thing. We as an industry are to blame for that. Tools like Rails, Django, etc. should be setup to support SSO/SAML/OIDC/RBAC/Audit Logs/MFA by default--rather than the default always being 'start with a user table and shit password management'-- so that the cost of those implementations goes down, and so that the "best practices", such that they are, are implemented from the very beginning.
Not at least supporting MFA and audit logs, at this point, should be considered an ethical lapse.
Here's a list of things you could charge extra for:
There are so many other things you can charge an enterprise extra for. Safety, security, and peace-of-mind in using your service shouldn't ever be a question.#1 - From a builders perspective, you've got to figure out what features (security or otherwise) that cost you extra and charge accordingly. In the old days SAML was one of those features was legitimately expensive to implement. Now keep in mind that not everything that costs you extra people will necessarily want to pay for.
#2 - From the sales perspective, what are features that people are willing to pay more for. SSO is something that is more and more frequently a business requirement. You want slack? Require SSO? Well you're paying for Business+ at $12.50/mo/user rather than Pro at $6.67/mo/user... even if you care about nothing else that comes in the Business+ plan.
As a Security/IT person, I absolutely hate that features I consider to be "required" (like SSO and APIs) are extra costs when we're the customers. The best I (and others like us can do) is convince our businesses those items should be part of the default feature set and not charged extra for.
https://xkcd.com/1053/
At some point in the future you will be faced with a dilemma. You will have a customer who can't get these free features to work with their existing systems. On one hand you won't want to give away the time of a senior engineer necessary to fix what is their problem. On the other hand, you won't want a potential large customer to walk away and tell people they don't use your product because "it doesn't work."
Charging customers for features is really charging them to support getting those features to work for them. It means you can afford to support customers and make them happy rather than having to say "The feature is there. Good luck!"
Admittedly, it's easier to segment plans based on such top level features you listed (not required by everyone but required mostly by Enterprise customer) than having matrixes of features that make usability of the software a nightmare just because you're not on a specific plan. Developing and ploying software with feature flags that change the workflow can be a nightmare. Not to mention segmented documentation that's impossible for your customers to follow / use.
That said, I know you're coming from an idealistic point of view, BUT be careful providing some features that require high touch to freeloaders - assuming you'll have a free tier. Question to ask yourself is - can a multimillion or even billion company use our free tier comfortably - if the answer is yes - then you'll struggle making money.