In product-led growth, the controls a buyer needs in order to trust you are conversion features. Move them behind the enterprise tier and you are charging admission to be trusted — then wondering why the buyers who take security seriously are the ones you cannot close.
I run a lot of vendor security reviews. It is one of the least glamorous parts of the job and one of the most revealing, because a product's pricing page tells you what a company actually believes about security long before its trust center does. And the same moment keeps repeating. I get to the part of the review where I need single sign-on, audit log export, provisioning, and per-user roles — the controls my program cannot operate without — and I find them sitting behind a tier upgrade that can multiply the bill several times over. Not because the software costs more to run. Because I asked to be safe.
There is a name for this. The community calls it the SSO tax, and a widely cited public list has spent years cataloguing the surcharge: the delta between a vendor's normal plan and the plan where single sign-on finally turns on. Some of the multiples on that list are absurd. The tax is not an accident of pricing. It is a deliberate go-to-market move — security-conscious buyers are, on average, larger and less price-sensitive, so the logic goes, put the controls they insist on in the tier they can afford and let the demand for safety do the upselling.
I want to argue that this move, whatever it does for one quarter's expansion revenue, is a strategic error — and a sharper one in fintech than almost anywhere else. In a product-led motion, baseline security controls are not enterprise features. They are conversion and retention features, and paywalling them sabotages the exact trust the product exists to earn.
Baseline controls are how the buyer says yes, not how you upsell them
Product-led growth inverts the old enterprise sales order. A user adopts the tool bottom-up, likes it, and pulls it into the organization on their own. Usage arrives before the contract does. Somewhere in that arc, a security review happens — and that review is the trust boundary of the funnel, the last real gate before adoption becomes a signed, expandable account. The reviewer is not a skeptic you have to overcome. They are a champion's colleague, evaluating a tool that already has traction inside the building.
Now look at what you have gated. The controls that reviewer needs — SSO, enforced multi-factor, per-user roles, visibility into who did what — are the exact ones behind the tier wall. So the funnel converts everyone right up until it reaches the people whose job is to take security seriously, and then it stalls. You have built a machine that filters out your most credible buyers at the last gate, and it does so precisely because they are doing their jobs well. The champion, who was ready to advocate, now has to walk into procurement to unlock the thing that should have shipped by default. You have manufactured friction at the single worst moment in the funnel: the moment the deal was about to become real.
The healthy version is boring. The security review finds the controls already present, checks the boxes, and gets out of the way. That is what a conversion feature does — it removes the reason to say no. Gate it, and you have taken the one part of the evaluation that could have accelerated the deal and turned it into the part that kills it.
Audit logs are the buyer's evidence, and you are selling them a blind spot
When the gated control is the audit log, the harm goes past friction. A customer who cannot export — or in the worst cases cannot even see — the record of activity in their own tenant cannot detect a problem, cannot investigate one, and cannot attest to what happened. You have not withheld a convenience. You have sold them a blind spot and called it the standard plan.
The security community made this argument loudly after a run of widely reported SaaS breaches where lower-tier customers discovered, in the middle of an incident, that they had no logs to reconstruct their own exposure. As I understand it, CISA's Secure by Design pledge — which several hundred vendors signed starting in 2024 — includes a commitment to provide customers with audit logs at no additional charge, on exactly this reasoning. Take the pledge as evidence of the logic, not as a compliance box: a customer who cannot see their own activity is a customer who cannot protect themselves, and a vendor who charges for that visibility is monetizing their inability to.
In fintech the point gets sharper still. My customers are regulated financial institutions — more than 1,500 of them — and their examiners expect them to obtain audit and monitoring evidence from their vendors under FFIEC-style third-party oversight and GLBA vendor-management expectations. If I gate those logs behind an enterprise tier, I have not just inconvenienced a buyer. I have engineered my own customer into an exam finding. In a regulated market, the SSO tax is a compliance tax you levy on the people who trusted you, and it comes due on their timeline, not yours.
The tax manufactures the insecurity it pretends to monetize
Here is the part that should bother the people who set the pricing. Gating SSO does not convert security-conscious buyers upward nearly as often as the model assumes. Most of the accounts on the lower tier do not pay the tax — they route around it. They share a single admin login. They keep local passwords in a spreadsheet. They skip provisioning entirely and add and remove people by hand. The surcharge does not upsell them into safety; it teaches them to run unsafely on the tier they can afford.
And identity is the front door of everything. SSO is not only how people sign in — it is how you deprovision cleanly when someone leaves. Charge for SSO and you are also charging for offboarding, which means the customers who declined to pay are the ones accumulating orphaned accounts and stale access long after people have moved on. That is the exact human and non-human identity sprawl I spend my career chasing down. So the tax does not sell security as a premium. It sells insecurity as the default and prices the remedy out of reach — then leaves the vendor holding a base of customers who are provably worse at controlling access than they would have been if the safe path had simply been on.
Retention is where the tax actually costs you
Conversion is the visible cost. Retention is the quiet one, and it is larger. The day you force a security-conscious administrator onto the enterprise tier for no reason other than to switch on SSO, you have taught them exactly one thing about you: that trust is a line item you will nickel-and-dime. That lesson does not stay in the account. It shows up in the renewal conversation, in the reference call a peer asks them to take, in the channel where practitioners compare notes on what to buy and what to avoid.
Security-conscious buyers are the most networked buyers you have. They talk to each other constantly, they remember specifics, and the SSO tax is precisely the kind of specific that travels — a clean, quotable story about a vendor who charged extra for the right to be safe. You did not merely extract a one-time surcharge. You converted your most credible potential advocates into your most precise critics, and you did it to close a gap on a spreadsheet that the next round of competitive pressure was going to close anyway.
How I'd draw the line — protect the customer, or operate the org at scale
I am not the person who owns a product's pricing sheet, and I am not going to pretend the enterprise tier should be free. Some features genuinely cost more to build and to serve, and charging for those is not a tax — it is a business. So the useful question is not "is this a security feature," because almost everything can be dressed up as one. The question I actually apply, sitting on the buyer side of these reviews and having to certify the result to an examiner, is narrower: does this control protect a single customer, or does it operate a large customer's organization at scale? Protect belongs in the baseline. Operate-at-scale is fair to tier.
- Belongs in the baseline — it protects the customer. SSO and enforced multi-factor. Per-user accounts and roles, so nobody has to share a login. The customer's own audit log for their own tenant, exportable. Encryption in transit and at rest. A documented way to export and delete their data. These are the controls a single buyer needs to operate safely and to survive their own security review. Charging for them is charging for the right to be trusted.
- Fair to tier — it operates the org at scale. Automated directory sync and provisioning across thousands of seats. Custom data residency or dedicated tenancy. Long-horizon log retention and streaming into the customer's own monitoring stack. Custom contractual and data-processing terms. Dedicated support and hard SLAs. These cost you real engineering and real operating expense, and they scale with the size and complexity of the buyer — which is what a tier is supposed to price.
- The test, in one line. If the control is the difference between a customer being able to detect, respond to, or attest to what happens in their own account, it is baseline. If it is the difference between serving a hundred users and a hundred thousand, it is a tier. Safety is not a volume discount you withhold until the buyer spends enough.
This is the same principle we built into AgentOS. The governed path is the default one — scoped identity, single sign-on, and a complete audit trail come standard, never as an upgrade — because a control you have to opt into, or pay extra for, is a control most people quietly route around. Make the safe road the easy road and the frictionless one, and you do not have to tax anyone into safety. They are already there, because it was never in their way.
Price the scale, not the trust
Put the controls a buyer needs in order to trust you in the tier they already have. Ship SSO, per-user roles, and the customer's own audit log by default, and reserve the enterprise price for the features that genuinely cost you to build and serve at scale. Stop teaching your most security-conscious customers that safety is an upsell, because they are the ones who talk and the ones you cannot afford to lose. If a control is the reason a buyer can say yes, it belongs in the funnel, not behind it.
So I will put the question I would rather argue about in the open than discover in a renewal: where does the line between baseline and enterprise actually sit for you — and has anyone measured what the SSO tax cost you in the deals that quietly stalled at the security review, or in the advocates it turned into critics? Tell me in the comments.
