Getting a SaaS product ready for enterprise login takes anywhere from a few weeks to several months, and longer if the buyer requires a SOC 2 Type 2 report you do not have yet. The spread comes from three things you can check today: whether you build the login layer or use one that already supports the standard protocols, how quickly the customer’s own IT team can do their half of the setup, and which security documents you already have. The engineering part is the one you control, and it can be short with the right layer underneath. The customer-side setup and the paperwork are the parts that run long, because they depend on other people’s calendars.
This post is about duration only, so a founder or engineering lead can answer “when can we say yes?” with a plan. It does not list every requirement a buyer might raise. For what to ship first and what blocks a signature, read what to ship when a prospect wants SSO and a SOC 2 report, and for the questions a buyer’s security team asks, see what security questionnaires ask about login.
What decides how long each workstream takes?
Think of enterprise login readiness as four workstreams that mostly run in parallel. Each has a different thing that sets its duration, which is why a single estimate for the whole project is unreliable.
| Workstream | What sets its duration | Who owns it |
|---|---|---|
| Sign-in through the customer’s identity system (SSO) | Build or buy, and how many identity systems you must support | Engineering lead |
| Automatic user creation and removal (SCIM) | Whether your login layer already supports it, and how your user model maps | Engineering lead |
| Security documents and questionnaire | What you already have written down, and any audit window | Security lead or founder |
| Customer-side setup | The customer administrator’s availability and change windows | Customer success lead |
A realistic plan is the critical path through these, not their sum. The question to ask each week is which item has the longest wait left, because that item decides the date.
How long does the engineering work take?
It depends mainly on whether you are writing protocol code. SSO means supporting SAML 2.0 or OpenID Connect against whatever identity system the customer runs, such as Okta or Microsoft Entra ID, with settings that differ for each customer and an admin screen so customers can configure it without a ticket. SCIM (System for Cross-domain Identity Management, defined in RFC 7643 and RFC 7644) adds endpoints that let a customer’s directory create and remove users in your product.
If your team writes this itself, the work includes the protocol flows, validation and security details, per-customer configuration and a way to keep it patched afterward. That is feasible for a team with identity experience, and it is a recurring commitment as well as a project. If you use a login layer that already supports SAML, OpenID Connect and SCIM, the engineering work shrinks to integration and configuration, and the first customer becomes a setup task. How to choose an SSO provider for B2B SaaS and what to check before you build or buy cover the choice.
Multi-factor authentication and audit logs belong here too. If sign-in goes through the customer’s identity system, their MFA policy applies as long as they enforce it for your application, and your own MFA covers users who still have a local password. Audit logs of sign-ins and administrative changes, reachable by export or API, are usually a small item if your login layer records them already.
The engineering part can be short, and the rest depends on you and your customer.
Why is the customer’s IT team often the slowest part?
SSO is configured on both sides, and nobody puts the other side in the project plan. The customer’s administrator has to create the application in their identity system, exchange metadata or credentials with you, assign users and test a sign-in. That administrator may be busy, in another time zone, or waiting for a change window that opens once a week or once a month. A technically finished integration can sit for weeks at this step, and from the sales team’s point of view it looks like engineering is late.
Four habits shorten the wait:
- Give customers a self-serve setup screen so they can paste in metadata and test without waiting for you.
- Write a short setup guide per identity system, covering Okta, Microsoft Entra ID and Google Workspace at least, with screenshots of the customer side.
- Offer a call with their administrator in the first week, not the last, so surprises appear early.
- Ask for the change window when you sign, and put it in the plan as a dependency with a name next to it.
If the next prospect uses a different identity system, the same habits apply.
How long do the security documents take?
The questionnaire is a writing task, and its duration depends on what you have already written. A team with policies, a network diagram and a recent penetration test summary can answer in days, and a team that has none will find that writing them is the long part. Start on day one, because it needs no engineering.
A SOC 2 report is different. A Type 2 report covers a period of time, so its date is set by the observation window and the auditor, and you cannot shorten it by working harder. Do not give a prospect a report date that you do not control. If you buy your identity layer from a provider that holds its own SOC 2 Type II report and ISO 27001 certification, you have something concrete to show for that part of the stack, and ours are described on the security and trust pages. If you are choosing a route, SOC 2 Type 1 or Type 2, which first is the next read.
What does the calendar look like in practice?
Plan in terms of dependencies and not durations, and update it weekly. A useful skeleton looks like this:
- Week one: decide build or buy, start the questionnaire, ask the prospect which identity system they use and who their administrator is.
- Engineering window: integrate SSO and, if needed, SCIM against a test setup that you control, and write the customer setup guide.
- Customer window: schedule the administrator call, wait for their change window, run the test sign-in.
- Documents in parallel: finish the questionnaire, collect the policies, and confirm the audit plan if the prospect requires a report.
Whichever item has the longest remaining wait sets your date, and once the login layer supports the standard protocols that item is usually on the customer’s side or in the documents. The SaaS page describes how we approach this for B2B products, and hosting and pricing describe the managed options.
What do you still own after you buy a managed identity service?
You still decide which customers get SSO and on which plan, you run the setup with each administrator, you answer the questionnaire in your own words, and you own the audit trail of your product. A managed service removes the operating burden of the identity system, such as patching, upgrades and availability, and it does not take over your responsibility for your customers’ access.
Frequently asked questions
How do we estimate the customer-side wait?
Ask the prospect for the name of their administrator and the date of their next change window when you sign, then count the days to that window as a fixed dependency. If they cannot name either, treat the wait as unknown and say so in your plan instead of filling it with a guess.
What if the customer’s change window is monthly?
Then the window, not your engineering, sets the date, so finish and test your side before it opens and offer a call with their administrator beforehand. Missing a monthly window costs a month, which makes a prepared setup guide and a test checklist worth the effort.
What if our first customer’s identity system is unusual?
Many enterprise customers run Okta, Microsoft Entra ID or Google Workspace, and all of them support SAML or OpenID Connect. An unusual system usually still speaks one of the two, so the question becomes how much per-customer configuration your setup screen allows, not whether you need new code.