The SSO tax, and everything after it

Which enterprise SaaS features do buyers actually screen for?

Enterprise buyers screen for four things before they form an opinion about your product: single sign-on backed by directory provisioning, role-based access control that can be scoped, an audit log they can export, and a tenant isolation model you can describe in one page. Those are the enterprise SaaS features that decide whether a deal reaches procurement. The rest of the SaaS application features list is negotiable, and most of it gets negotiated.

The screening is now formalised. Sixty-eight percent of enterprise RFPs require MFA or SSO inside the base plan rather than a paid security tier, and 43 percent of RFPs expect RBAC and encryption by default.¹ Sixty-one percent of enterprise buyers cannot purchase without information security sign-off, against 26 percent of SMB buyers.¹ That gap is the whole story of moving upmarket. The person who loves your product is no longer the person who can approve it.

It helps to sort the work into three tiers rather than one undifferentiated backlog. The baseline tier is what gets you into the evaluation. The expected tier is what gets you through security review without a manual exception. The advanced tier is what wins regulated and multi-department deals.

Why SSO is a tax rather than a feature

Single sign-on lets people authenticate into your product with their employer’s identity provider credentials instead of a password you store. Building SSO for SaaS is not one integration. It is SAML 2.0, then OIDC, then SCIM, then the accumulated quirks of every identity provider your buyers actually run: Okta, Entra ID, Google Workspace, Ping. Each one contributes edge cases you only meet in production.

The long tail is where the budget goes. Certificate rotation that nobody schedules until it expires on a Friday. IdP-initiated flows that your session handling did not anticipate. Attribute mapping when a customer’s directory calls the field department and yours calls it team. Just-in-time provisioning that creates a duplicate account because the email casing differs. Domain claiming, so one customer cannot capture another’s users. Break-glass admin access for the day the identity provider itself is down. None of these appear in the RFP. All of them appear in your support queue.

Scale explains the impatience. Okta client organisations average 101 SSO-connected applications, the first time that figure has passed 100.² Enterprises above 10,000 employees run in the region of 660 SaaS applications in total.³ You are not being evaluated as an interesting new integration. You are joining a queue, and the identity team’s tolerance for bespoke behaviour is close to zero.

SSO and MFA are different controls

SSO establishes who the user is and which directory vouches for them. MFA establishes how strongly that claim was proved. Once SSO is in place, most enterprises delegate MFA policy to their own identity provider, which is exactly why they refuse to pay extra for SSO. Putting it behind a premium tier reads to a security team as charging for the lock on the front door.

Do you need SCIM?

SCIM is the provisioning protocol that creates, updates and disables accounts automatically from the customer’s directory. SSO alone handles the joiner and the mover reasonably well. It handles the leaver badly, because a disabled directory account can still leave an active seat and an orphaned API token in your system. If your buyers are above roughly a thousand seats, or if they sit in a regulated sector, SCIM stops being optional. Below that, a well documented user deactivation API often satisfies the review.

On build against buy, the honest question is not the price per connection. It is who owns the long tail. An identity platform absorbs the per-provider edge cases and the protocol maintenance; building in house means your team carries them for as long as the product lives. Teams that underestimate this usually do so because they costed the first integration and not the twentieth.

What does the admin surface have to do?

The admin console is where a rollout either spreads or stalls. Role-based access control grants permissions by assigned role, such as admin, editor or viewer, rather than by configuring each user individually. That model is now the floor, not the ceiling. Flat admin and member roles break the moment a second department joins, because the finance lead needs full control of their own workspace and no visibility into legal’s.

What enterprise buyers increasingly expect is a permission model with at least one scope dimension: per workspace, per project, per business unit. Call it resource-scoped RBAC or attribute-based access control; the buyer’s test is the same. Can they delegate administration downwards without handing out global admin, and can they see who holds elevated access today?

Four other pieces of the admin surface come up repeatedly in evaluations, and each one removes a support ticket that would otherwise recur forever. Domain claiming and verification, so the customer owns every account on their email domain. Seat and licence visibility, so procurement can see what they are paying for. Self-service session controls, covering session length, idle timeout and IP allowlists. A clean offboarding path that transfers ownership of a departing user’s content rather than orphaning it.

What should an audit log actually capture?

An audit log should record who did what, to which object, when, from where, and what the value was before and after the change. A table in your admin UI is not an audit log. Security teams treat it as one only when it is immutable, retained for a defined period, and exportable through an API they can point their own tooling at. In practice, a log export endpoint gets asked about before your product roadmap does.

The events that matter are narrower than the full firehose. Authentication attempts, including failures and MFA challenges. Permission and role changes. Every administrative action. Data export and bulk download. API key and token lifecycle. Integration, webhook and connected-app changes. Tenant configuration changes. Deletions, with the actor recorded. If a security reviewer can reconstruct a specific incident from your log without asking your support team for help, the log is doing its job.

Two details separate a usable log from a compliance prop. Retention should be stated as a number in your documentation, not decided per customer on a call. And export should stream, so a customer with a SIEM can ingest events continuously rather than downloading a CSV every month and calling it monitoring.

Multi-tenant architecture is a sales asset

Multi-tenant architecture means one application instance and one infrastructure footprint serving many customer organisations, with each tenant’s data kept isolated. The isolation can be logical, through a tenant key enforced at every query, or physical, through a schema or a database per tenant. Larger accounts sometimes buy a dedicated deployment on top of that.

Buyers now raise this in security review rather than in a technical deep dive. The question is rarely which model is best in the abstract. It is which model you chose, where the isolation is enforced in code, and what test proves that a cross-tenant read cannot happen. Answering with an architecture diagram is a missed opportunity. Answer with the enforcement point, the automated test that guards it, and what happens when a customer asks for their data to be deleted.

Teams that write this up once, in plain language, stop rewriting it in every questionnaire. It becomes a page you send, and the review moves on.

Why do enterprise SaaS deals stall in security review?

Usually not because a feature is missing. They stall because the paperwork is not ready. Missing security documentation adds 26 percent to sales cycle length.¹ More than half of B2B buyers now raise security in the first sales conversation, up from 28 percent in 2023.¹ Security has moved from the end of the process to the start of it, and a sales team that cannot answer in the first call has already lost time.

By the time the questionnaire arrives, the product decision is mostly made. What is being tested is whether you can be bought.

The document set is short and knowable: a current SOC 2 Type II report available under NDA, a data processing agreement you will actually sign, a published subprocessor list with a change notification commitment, a completed standard questionnaire such as CAIQ or SIG Lite, a penetration test summary, and a named security contact who replies. None of that is engineering work. All of it is deal velocity.

Visible responsiveness compounds. Vendors whose security responsiveness is visible to buyers before the sale see about 20 percent higher win rates.¹ The mechanism is unglamorous. A trust page removes a week of email. A pre-filled questionnaire removes another. Neither requires a single new line of product code.

In what order should you build enterprise SaaS features?

Sequence by what unblocks a deal soonest per week of engineering, not by what is most interesting to build.

1. SAML SSO with per-domain enforcement and a documented break-glass path. This is the gate.
2. An audit log with an export API. Cheap to build early, expensive to retrofit once your event schema has drifted.
3. RBAC with one scope dimension. Adding scope later means migrating every existing customer’s permissions.
4. The paperwork. Trust page, DPA, subprocessor list, questionnaire responses. Weeks of work, not quarters.
5. SCIM. Once deprovisioning becomes a named requirement in your pipeline.
6. Advanced controls. Custom roles, log streaming, residency, customer-managed keys. Build these against a signed commitment, not a hypothesis.

To self-audit, take a real evaluation you lost and answer yes or no to eight questions. Can a customer enforce SSO across their whole domain without contacting support? Can they provision and deprovision from their directory? Can they export the audit log through an API? Can they scope a role to a single workspace? Can they see who holds admin access today? Can you send a current SOC 2 report the same day it is requested? Can you name your tenant isolation model and the test that enforces it? Can you produce a completed security questionnaire from a template rather than from scratch? Count the noes. Each one is a question you will answer manually in every deal for the rest of the year.

Most of this is sequencing judgement rather than novel engineering, which is why it belongs in the same conversation as roadmap and discovery. Our product development teams treat the enterprise readiness tier as a release train with its own definition of done, and the earlier stages of that thinking sit close to the design thinking process that shapes the admin experience itself. If you are weighing build against buy on identity, or deciding which of the eight questions above to fix first, our product development consulting practice runs that assessment as a fixed exercise. Tell us where the last deal stalled and we will tell you what we would build next.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.