How Many Customer SSO Setups Can Your Team Support?

The number of customer SSO setups your team can support depends on how many hours each customer takes from first request to a working login, and on how many hours they keep taking afterwards when something changes, which is the real cost of enterprise SSO onboarding. A team that does one or two setups by hand will usually cope, but by the time you reach a dozen customers the same manual process tends to compete with product work for the same few people. This article gives you a simple way to estimate the per-customer effort yourself, shows where that effort grows, and compares three ways of handling it, so you can decide before you agree to the next SSO commitment. We do not quote industry averages here, because setup effort varies too much between products and customers for a borrowed number to be useful.

What does a customer SSO setup involve on your side?

A customer SSO setup is the work between a customer saying “we use Okta” and their employees signing in to your product with their company accounts. The steps are the same for most customers, but each one has a person waiting on another person, and that waiting is where most of the elapsed time goes.

In practice the sequence looks like this:

1. The customer’s IT admin asks for your connection details, such as your callback URL and entity ID, and you send them.
2. The admin creates an application in their identity provider (IdP, the system such as Okta or Microsoft Entra ID that holds their employees’ accounts) and sends back either a SAML metadata file, or an OpenID Connect issuer URL together with a client ID and client secret.
3. You add that configuration to your login system and map the attributes your product needs, such as email address and group membership.
4. You and the admin run a test login, and usually fix at least one mismatch in attribute names or certificate details (our SAML decoder shows what the IdP actually sent).
5. You decide how users get created (on first login or by provisioning) and which email domains route to this customer.
6. You turn it on for real users and wait for the first support questions.

The protocols behind these steps are documented in the SAML 2.0 metadata specification from OASIS and the OpenID Connect Discovery specification, and we will not repeat them here. What matters for planning is that the technical work in step 3 is often the shortest part, while steps 1, 2 and 4 depend on someone at the customer who has other priorities.

Why is the customer’s admin the slow part?

Your engineers control the speed of step 3, but the customer’s IT admin controls steps 1, 2 and 4, and that admin is usually handling many other requests, may need a change ticket approved, and may not have configured your kind of integration before. A reply that takes two days instead of two hours is normal, and a test login that fails on a certificate or attribute mismatch adds another round trip.

This means elapsed time and effort are different numbers. A setup may need three hours of your team’s attention but stretch across three weeks, and the sales team will want a date for the customer. For planning your team’s capacity, track the hours your own people spend, and track elapsed days separately for the conversation with sales.

How does the effort grow from one customer to fifty?

Effort grows in three ways: the one-time setup for each new customer, the follow-up each customer needs after launch, and the changes customers make later. Most teams plan for the first and underestimate the other two, because those only show up once several customers are live.

Setup effort is the most visible part, and it tends to be roughly constant per customer unless you automate it. If your first setup took a day of engineering time because you were also building the feature, the tenth will probably be faster, but it will not drop to zero while a person still copies values between systems.

Follow-up effort is the steady trickle that comes after launch: an employee who cannot sign in, a customer who asks which attributes you receive, a security questionnaire asking how you handle SSO. Each one is small, but they arrive from every customer and they land on whoever knows the setup best.

Change effort is the part teams forget. Customers rotate the signing certificate in their IdP, rename a group, add a second email domain after an acquisition, or move from one IdP to another. A customer changing IdP is effectively a new setup, with the same back-and-forth with their admin, and you often learn about it only when logins start failing.

How can you estimate the effort per customer?

You can estimate it with a small table that you fill in from your own last few setups, rather than from anyone else’s averages. Pull up the tickets, chat threads and calendar invites from the one or two SSO setups you have already done, and write down these numbers:

Then the yearly effort for a given number of customers is:

Hours per year = (new customers per year x (A + B)) + (total live customers x 4 x C) + (total live customers x D x E)

Fill in A and B from real history, and make C, D and E honest guesses that you revisit after a quarter of data. If you expect ten new customers this year and have fifteen live, divide the result by about 40 to turn it into weeks of one person’s time, and compare that figure with your roadmap. Count customers you onboard during the year in the live total too, or prorate them if most arrive late in the year. The method is deliberately plain, because the value is in making the hidden follow-up and change work visible, not in the precision of the answer.

Who on your team owns customer SSO?

Customer SSO usually has no clear owner, so it falls to the engineer who built the first integration, and support tickets about it get routed to that person. That works for two customers and becomes a risk at ten, because the knowledge sits in one head and the work competes with that person’s other commitments.

There are two distinct costs to separate. Engineering time goes to setup, debugging and changes to the login configuration. Support time goes to answering the customer’s admin and their employees. If both land on engineers, then senior engineers spend their time on repeatable configuration, and your support team cannot resolve a “my login redirects to the wrong place” ticket without escalating.

Single-person knowledge is the more serious issue. If one engineer holds the details of which customer uses which attributes, which certificates expire when, and which exceptions were agreed in the sales process, then that person’s vacation or departure makes every SSO customer a risk. A shared runbook is the minimum, and the better fix is to make the configuration something the system records, so nobody has to remember it. Our article on how long it takes to become enterprise-ready on login covers the wider set of requirements that tend to arrive along with SSO.

What are your options for enterprise SSO onboarding at scale?

You have three realistic options: handle each customer by hand, let customer admins configure their own connection through a self-service flow, or hand the connection work to a managed identity provider. They differ mainly in who does the repetitive steps and who holds the configuration afterwards.

Option 1: By hand, per customer

You or your engineers do every step in the list above for each customer. This needs no new building and gives you full control, which is why it is the right starting point for one or two customers. The cost is that every new customer and every later change costs the same hours as before, and the knowledge stays with whoever does it.

Option 2: Self-service setup for customer admins

You build (or adopt) an admin screen where the customer’s IT admin pastes their metadata, picks their attributes and tests the connection without involving your team. This removes most of the waiting from your side, since the admin can work at their own pace. The cost is that you now own a product feature, including its error messages, its security review and its documentation, and you still support admins who get stuck. Self-service also does not remove the later changes, because the customer’s admin still has to make them and your team still supports them.

Option 3: Hand connection work to a managed identity provider

You use an identity provider that already models customers as first-class objects, so that adding a customer is a configuration record rather than custom code. Skycloak is managed Keycloak, and Keycloak’s Organizations feature (available on Skycloak) lets you link each customer’s identity provider to an organization and route users to it by email domain. As described in our guide to federated identity management for B2B SaaS on Skycloak Organizations, the identity provider for each customer is currently created at the realm level and then linked to its organization, and a dashboard that manages providers scoped to a single organization is not yet available. That means a person on your side still creates each connection today, and the benefit is a consistent, repeatable record per customer instead of bespoke code. In Keycloak terms, each customer becomes an identity provider with a descriptive alias such as acme-okta, linked to an organization that owns the acme.com domain, with the redirect-when-email-domain-matches option turned on. For OIDC connections, enabling the Use JWKS URL option lets Keycloak pick up the customer’s new signing keys after a rotation instead of failing until someone pastes in a new certificate. Our article on multitenancy with Keycloak Organizations goes deeper.

For provisioning, our guide to using SCIM 2.0 with Skycloak covers SCIM (a standard for automatically creating and removing user accounts from the customer’s IdP, defined in RFC 7644). If you are deciding between creating users on first login and provisioning them in advance, our comparison of JIT provisioning vs SCIM explains the difference.

Skycloak pricing is cluster-based, with no per-user or per-MAU fees, which matters for B2B SaaS because the number of employees at each customer is outside your control.

What should you decide before you sign the next SSO commitment?

Before agreeing to another SSO customer, fill in the estimate above with your own numbers and decide which of the three options you will use at your expected customer count. The point is to agree on the approach while the commitment is still a conversation, rather than discovering the cost after the contract is signed.

Three questions help make that decision concrete:

1. What is your hours-per-year figure at the customer count you expect in twelve months? If it is a small fraction of one person’s time, doing it by hand may be fine. If it is several weeks, you need a different approach.
2. Who owns it, and who covers when they are away? Name one owner and one backup, and write down the runbook.
3. What do you promise the customer about timing? Customers often ask for a go-live date, and since their admin controls part of the schedule, promise a process and a response time from your side instead of a date.

If you are evaluating a vendor for this work, ask questions about customer onboarding specifically, not only about protocol support:

• Who creates each customer’s connection, your team or the customer’s admin, and how long does that take in practice?
• What happens when a customer rotates a certificate or changes IdP, and will anyone be alerted before logins fail?
• Can the customer’s admin test the connection without your engineers on a call?
• Are IdP-initiated logins supported, since some customers’ admins will ask for them? Our article on IdP-initiated vs SP-initiated SSO explains why this comes up.
• How is pricing affected as customers and their employee counts grow?

Our guide on how to choose an SSO provider for B2B SaaS goes through the wider selection criteria, and the questions above are the onboarding-specific part to add to it.

Frequently asked questions

How long does a customer SSO setup take?

It depends on your tooling and on the customer’s admin, so we cannot give an honest single number. The hours your team spends and the elapsed days are separate measurements, and the elapsed time is usually longer because you wait on the customer. Measure both on your first two setups and use those as your baseline.

Do we need self-service SSO setup for customers?

Not for the first few customers. Self-service starts to pay off when waiting on your team becomes the slowest step, or when setup and change requests take a noticeable share of an engineer’s week. The estimate formula in this article shows when you reach that point with your own numbers.

What happens when a customer changes identity provider?

You treat it as a new setup. The customer’s admin creates a new application in the new IdP, sends you new metadata or endpoints, and you update the connection and test it. Existing users are linked to the old IdP, so in Keycloak the First Broker Login flow decides what happens on their first login through the new one: it can ask them to confirm the link, link silently on email when you trust both IdPs, or create a new account. Decide which before the cutover. Our article on enterprise SSO that survives IdP changes walks through it.

Who should own enterprise SSO onboarding, engineering or support?

Engineering should own the configuration and the runbook, and support should own the conversation with the customer’s admin and employees. Name a primary owner and a backup, so that knowledge does not sit with one person. As the process becomes repeatable, more of it can move to support.

Should we create users on first login or provision them with SCIM?

Creating users on first login is simpler and works for many customers. SCIM matters when customers need accounts created before first login or removed immediately when someone leaves. Our JIT provisioning vs SCIM comparison covers how to choose.

Conclusion

The way to answer how many customer SSO setups your team can support is to measure the hours of your last one or two setups, estimate the follow-up and change work per customer, and multiply by the customer count you expect. That gives you a number of weeks of effort that you can compare against your roadmap before you commit.

From there, choose the approach that fits that number: by hand while it is small, self-service when waiting on your team is the bottleneck, or a managed identity provider when you want each customer to be a repeatable record. Whatever you choose, name an owner and a backup, and ask any vendor how they handle customer onboarding and later changes, not only which protocols they support. The plans are on the pricing page.