Customer IT Access Delays in Onboarding: SSO, Security Review
Customer IT access (security review, SSO, SCIM, API credentials, network allowlisting) stalls onboarding because it depends on teams outside your project. Ask for every access item at kickoff, name a customer owner and due date for each, put them on the plan as dependencies, and escalate on a fixed clock. Rocketlane estimates about 60% of onboarding delays come from late customer responses.
Customer IT access is the part of onboarding that stalls most often and that the customer controls least visibly. SSO configuration, SCIM provisioning, API credentials, firewall allowlisting, and security review all sit in someone else's queue, usually the customer's IT or security team. The fix is to ask for every access item at kickoff, name an owner on the customer side for each, and track each one on a dated list that is reviewed weekly.
This guide covers what customer IT will ask of you, what they will ask you to do, where the days disappear, and a workable sequence for getting access without a go-live slip. It is written for implementation managers and CS leaders who have watched a project sit at "waiting on IT" for three weeks.
Why does customer IT access slow down onboarding so often?
Access work depends on people who are not on the project team, who did not attend the sales calls, and who have their own backlog. A project manager who owns the plan does not own the identity provider, the firewall, or the security review queue.
The delay pattern is consistent. Rocketlane reports that approximately 60% of project delays during onboarding stem from late customer responses. That is a vendor's own estimate rather than an independent study, but it matches what most implementers report: the work you control gets done, and the work that needs the customer waits.
IT access is the hardest version of that problem for three reasons:
- The requester is not the owner. Your champion asked for the product, but an IT admin or security analyst you have never met has to approve and configure it.
- Requests arrive late. Many teams discover the SSO or allowlisting requirement in week three, after the kickoff plan was already signed off.
- Each step is serial. Security review comes before access, access before integration, integration before testing. A one-week slip in the first step moves every step behind it.
For the general pattern of customer-side lag, see our guide to tracking customer deliverables during onboarding.
What access items should you collect before kickoff?
Collect the access list as part of kickoff preparation, not after it. Most items can be named in a single call with the customer's IT contact, and naming them early is what makes the timeline believable.
| Access item | Who usually owns it on the customer side | What you need from them |
|---|---|---|
| Security review | Security or GRC team | Questionnaire format, required evidence, reviewer name, target decision date |
| SSO (SAML or OIDC) | IT or identity admin | Identity provider, protocol, who can create the app, test users |
| SCIM provisioning | IT or identity admin | Whether it is required, which groups map to which roles |
| API keys and service accounts | System owner (CRM, ERP, data warehouse admin) | Account with the right scope, named owner, rotation rules |
| Network access | IT or network team | IP allowlist, firewall change window, VPN or private link needs |
| Test or sandbox environment | System owner | Sandbox availability, refresh cadence, sample data rules |
The integration side of this list is covered in more depth in integration requirements for SaaS onboarding. The kickoff conversation itself belongs on your kickoff meeting agenda.
How long does a customer security review take?
A security review can take anywhere from days to two months, and the spread depends mostly on whether your answers are ready before the customer asks. The questionnaire format also matters. Public guidance on common formats lists the SIG Lite at roughly 130 questions, the full SIG Core at roughly 850, and the CAIQ v4.1 at 283.
The time cost on the vendor side is large. Wolfia, a vendor in this space, says manual completion is commonly 12 to 18 person-hours per questionnaire, which it attributes to its own customers' experience. Whistic reports that Gremlin's team took 45 to 60 days on average to complete one security review before it moved to a shared security profile, and just under four days afterward. These are vendor case-study numbers, so treat them as ranges rather than benchmarks.
Two other figures from the same Whistic article, citing Gartner and Whistic customer data, are useful for expectation-setting:
- 65% of technology buyers say addressing security concerns caused delays in buying decisions, and only 29% of those buyers involved the security team in the process.
- Each follow-up question can add 4 to 10 days to the cycle, according to the same article, though it does not attribute that number clearly.
The practical lesson is that a second round of questions costs more than the first. Keep a current set of answers, the evidence documents, and a named contact who can respond within a day.
Why does SSO setup take longer than the plan says?
SSO setup takes longer than planned because it requires a coordinated exchange between your team and the customer's IT admin, and every customer runs a different identity provider with its own quirks. The technical steps are short. The waiting between them is not.
WorkOS estimates that onboarding one enterprise customer's SSO can take 10 to 20 hours, with engineering and customer success both involved, and that coordination through email chains can run for several weeks. The exchange includes an SSO URL, audience URI, metadata URL, and public certificates. The same source notes that Okta covers about 40% of identity provider requests, so the rest of your customers will bring Entra ID, Google Workspace, or something more unusual.
Auth0's SafetyCulture case study shows the cost of treating each setup as bespoke: before self-service, roughly 30% of engineering customer support tickets were tied to SSO setup, and tickets fell 60% four months after launching self-service. That is a vendor-promoted case study, but the direction is credible. If your engineers are doing SSO setups by hand, the delay is built into your process.
A published enterprise SSO playbook from Deepak Gupta lays out a 60-day sequence: 5 days for discovery and identity provider confirmation, 10 for self-service connection setup, 10 for attribute mapping, 15 for SCIM if required, and 20 for a pilot and cutover. It names the most common cause of a stalled SSO onboarding as building configuration before confirming the identity provider, attributes, and procurement requirements. That is a planning model, not a measured benchmark, but the order of operations holds up.
When does the customer also need SCIM provisioning?
The customer needs SCIM when they want users created, updated, and removed automatically from their directory. The same playbook puts the threshold at roughly 1,000 seats, though some security teams require it at much smaller sizes because of audit rules.
The reason security teams care is manual identity work. Cerby's 2025 Identity Automation Gap Report, a survey of more than 500 US IT and security leaders, found that 59% handle provisioning, offboarding, or both by hand and that 58% say former employees kept access to systems after leaving. A customer whose own process is that fragile will often ask your product to close the gap.
SCIM also fails in ways that need the customer's admin. WorkOS notes that most identity providers do not support creating rate limits, that Okta and Entra ID handle deactivation differently, and that sync problems often need manual work with the customer's IT admin, who is rarely aware of push failures on their side. Ask early whether SCIM is a go-live requirement or a later phase.
How do you keep access requests from stalling the project?
Treat each access item as a dated deliverable with a named customer owner, a due date, and a fallback. The goal is for a stalled request to become visible within two business days, not at the next status call.
- Surface the list at the sales handoff. If the buyer mentioned SSO, a security review, or a data warehouse connection during the deal, it should land in the handoff note. See the sales-to-onboarding handoff checklist.
- Meet the IT contact in week one. A 20-minute call with the actual admin replaces a month of messages passed through the champion.
- Send a single written request per item. State what you need, why, the exact format, and the date it blocks. One request per item avoids partial replies.
- Put access items on the project plan as dependencies. Showing the downstream tasks they block makes the cost of delay visible to the customer's sponsor.
- Define a fallback. If SCIM slips, can you launch on SSO with manual user creation and add SCIM in a second phase? Agree this before it is needed.
- Escalate on a clock. Use a fixed rule, such as a nudge at two days, a sponsor message at five, and a re-baselined date at ten. Our escalation process guide covers the wording.
Rocketlane describes how some teams formalize this: Contentful reaches out twice, then sends a third message warning that the project will pause without a reply by a set date. A pause rule makes the dependency real for the customer without turning the conversation into a dispute.
Where do access requests get lost, and how can you catch them?
Access requests get lost in the places where the conversation happens: a Slack thread, a call, a forwarded email. The requirement is mentioned, someone says they will look into it, and nothing is written into a tracker. Two weeks later the go-live date is at risk and nobody remembers who owed what.
Two habits fix most of it. First, record every access commitment from calls as an action item with an owner and date. Second, review open access items at the start of every weekly status meeting, oldest first. Stipulate can help here by extracting requirements, stakeholders, and risks from call transcripts and suggesting action items from customer Slack conversations, so the IT ask that came up mid-call is on the list without anyone retyping it. A shared spreadsheet works too if someone owns it.
Log the blockers in your RAID log as dependencies, not just as tasks. A dependency on an external team is a risk until it is closed. If the security team has a different channel from the project team, make sure the customer's IT contact is also in your shared Slack channel, as covered in our guide to Slack Connect and customer IT review.
What should you do when the customer's IT team goes silent?
Go around the silence without going over anyone's head too early. First confirm the request actually reached the right person, then offer a call instead of another email, then involve the customer's executive sponsor with a specific ask and the cost of delay.
Use the same discipline as any stalled engagement. Verify the silence is real, switch channels, and put a time on the calendar. Our playbook for a customer that goes dark covers the first 48 hours. Then re-baseline the date and say plainly what moved: the access item, the blocked tasks, and the new go-live. If the delay is large, a slipping go-live conversation is better held early than late.
Next steps
- List every access item (security review, SSO, SCIM, API credentials, network, sandbox) on your kickoff checklist template.
- Add a customer IT contact field next to the champion and sponsor on every project.
- Keep a current security questionnaire answer set and evidence pack so the first response goes out within a day.
- Decide your SCIM and SSO fallback positions in advance, and document them in your SOW.
- Review open access items first at every weekly status meeting, and escalate on a fixed clock.