Why SSO Alone Won’t Pass a Vendor Security Review

Last updated: September 2026

Having single sign-on (SSO) answers one question in a vendor security review, and a reviewer will usually ask four or five more about the same login before they sign off. They want to know whether SSO can be enforced so nobody bypasses it with a password, whether people lose access when they leave the customer’s company, how long sessions last and how they are ended, whether identity changes are logged in a way the customer can see, and how the identity system itself is secured. If you added SSO for a recent deal and treated that as the end of the identity work, those follow-up questions are where the next review will slow down.

This post is for the CTO, VP of Engineering or IT director at a SaaS company that shipped SSO because an enterprise prospect asked for it, and has now received another security questionnaire. It explains why SSO on its own rarely closes the identity part of a review, what reviewers look for around it, and what to have ready before the next deal reaches this stage. If you want the individual questionnaire questions and model answers, our post on what vendor security questionnaires ask about login covers those in detail, so this one stays on the gap between “we have SSO” and “we passed”.

Why doesn’t SSO answer the whole vendor security review?

SSO is on every enterprise buyer’s list, and in August 2024 the US Cybersecurity and Infrastructure Security Agency (CISA) and the FBI put it in writing. Their “Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem” asks, in its authentication section, whether a vendor supports standards-based SSO “at no additional cost” and whether multi-factor authentication is on by default. A later section asks about security logs, which the guide says SaaS providers should retain and make available to customers for at least six months at no additional charge.

That combination is a good summary of how reviewers think. SSO tells them the customer’s own identity provider (Okta, Microsoft Entra ID, Google Workspace and so on) is in the loop at sign-in. It does not tell them what happens before and after sign-in: whether a user can skip SSO entirely, how long the resulting session lives, what happens to that user’s account when they leave, and who at your company can change any of it.

What “enterprise-ready” gets confused with

A lot of teams use “enterprise-ready” to mean “supports SAML or OIDC login”. A security reviewer uses it to mean that the customer’s security team can control access to your product the same way they control access to everything else. That second meaning includes SSO, but it also includes provisioning, deprovisioning, session policy and evidence. A product can support SSO perfectly and still fail that test because a contractor who left three months ago can still sign in with a password they set before SSO was switched on.

In the reviews we have seen, the questionnaire itself rarely fails on SSO. It fails on the follow-up questions a reviewer writes in the comments column after reading your “Yes”, such as “Can SSO be enforced for all users in our tenant?” or “How are accounts removed when a user is disabled in our IdP?”.

What does a vendor security review actually ask beyond SSO?

Many reviews use a standard question set such as the Shared Assessments SIG, the Cloud Security Alliance CAIQ, or an in-house list modelled on them, and each of those has an identity and access management section that goes well past the login screen. The areas below are the ones that come up around SSO, grouped the way a reviewer usually thinks about them.

Session and access controls, not just login

SSO decides who gets in, and session controls decide how long they stay in and what they can reach once inside. Reviewers ask about idle timeouts, maximum session length, re-authentication for sensitive actions, and whether an administrator can end a user’s sessions immediately. They also ask whether roles inside your product are granular enough that a customer can give a finance user read-only access without making them an admin.

Deprovisioning is the question that most often catches teams out. SSO checks the customer’s identity provider at sign-in, but a user who already has a valid session, or who created an API token last month, may keep access after they are disabled upstream. SCIM (System for Cross-domain Identity Management) narrows that gap by letting the customer’s identity provider create, update and disable accounts in your product automatically. You still need short token lifetimes, or a check of account status on each request, so that a disabled account stops working straight away rather than when its current session ends, which is why reviewers read the sessions and deprovisioning answers together. Our explainer on what SCIM is and why it matters covers how it works alongside SSO.

Who can see and change identity data, and how that’s logged

Reviewers ask for two kinds of log: sign-in events for the customer’s users, and administrative events such as who added an identity provider connection or changed a role. Our questionnaire guide covers the audit log and staff access questions in detail, so the one point to add here is the CISA guide’s six-month retention figure, which is a useful benchmark to measure yourself against even when a particular buyer does not quote it.

How the identity provider itself is secured

This is the part of the review that SSO makes more important rather than less. Once a customer connects their identity provider to yours, your login service becomes part of their access path, so reviewers ask where it runs, who operates it, how quickly security patches are applied, and whether it is covered by an audit report. If you use a third party for authentication, that provider is a subprocessor, and the reviewer will usually want its SOC 2 report or equivalent as well as yours.

Teams that run their own identity server, for example a self-hosted Keycloak cluster, need a clear answer on patching. Keycloak ships security fixes regularly, including point releases on older minor lines, as our Keycloak 26.7.4 patch checklist shows, so “we upgrade when we get to it” is not an answer a reviewer will accept.

Where does the gap between adding SSO and passing review come from?

The gap usually comes from how SSO was added. A deal needed it, an engineer connected a SAML or OIDC library to the login page for that one customer, and the project closed when the customer’s users could sign in. The work to enforce it, remove users automatically, log changes and document the whole thing was never in scope, because nobody asked for it in that first deal.

That approach is reasonable for a first enterprise customer, and it tends to break on the second or third, for three reasons that show up repeatedly in reviews.

• SSO was built per customer rather than per tenant policy. Each new customer needs engineering time, and there is no switch to enforce SSO or disable passwords for a tenant.
• Provisioning is manual. Accounts are created on first sign-in and never removed, so a reviewer who asks about leavers gets a vague answer.
• Evidence is missing. The controls may exist, but there is no audit log a customer can see and no report from an auditor that covers them.

We wrote about the related risk of tying SSO too closely to one identity provider in how enterprise SSO survives identity provider changes, which is a related risk worth understanding before a large customer changes identity provider.

How do you get ahead of the next security questionnaire?

Start by answering the table above for your product as it runs today, in writing, before any prospect asks. Doing that tells you whether you have a documentation gap, which is fast to fix, or a product gap, which needs planning and should be on the roadmap before a deal depends on it.

What to have ready before the next deal reaches this stage

• A one-page identity summary. How SSO works, whether it can be enforced, how accounts are provisioned and removed, session defaults, and where logs live. Reviewers read this before the questionnaire and it answers half of it.
• An enforcement switch. The ability to require SSO and disable local passwords for a customer’s tenant, without a code change.
• A deprovisioning answer. SCIM if you can offer it, or at least short sessions plus a documented process for removing access when a customer tells you someone has left.
• Customer-visible audit logs. Sign-in and admin events the customer can export, with a stated retention period.
• Your audit report and your providers’ reports. A SOC 2 Type 2 report or an ISO 27001 certificate for your own company, plus the reports of any identity or hosting provider in the login path. Our post on SOC 2 Type 1 versus Type 2 covers which one to get first.
• Contract terms that match. Uptime commitments, incident notification and data handling for the identity service, covered in our guide to identity service procurement and SLA requirements.

For our own part, Skycloak runs managed Keycloak for teams that want the logging, provisioning and session controls above without operating the identity server themselves. Our audit logs, SCIM and session management pages describe what is included, and our trust page and security page explain how we share our own SOC 2 Type 2 report, under NDA, with the reviewers who ask for it.

If you are summarising all of this for a leadership team rather than filling in the spreadsheet yourself, the vendor risk brief your CTO needs to see is the one-page version.

Frequently asked questions

What is a vendor security review?

A vendor security review is the whole process a buyer runs before signing: the questionnaire, the request for audit reports such as SOC 2, and the follow-up questions and calls with the buyer’s security team. The questionnaire is only the first step, and most of the SSO follow-up questions described above arrive after it.

Is SSO required to pass a security review?

For most enterprise buyers, yes, and the 2024 CISA and FBI Secure by Demand Guide lists standards-based SSO at no extra cost as one of the first questions a customer should ask. SSO is necessary but not sufficient: reviewers also ask about enforcement, deprovisioning, sessions, logging and the security of the identity system.

What is the difference between SSO and SCIM?

SSO handles sign-in: the customer’s identity provider confirms who the user is each time they log in. SCIM handles the account lifecycle: it lets the identity provider create, update and remove user accounts in your product automatically. Reviewers ask about SCIM because SSO alone does not remove an account when someone leaves.

How long should SaaS audit logs be kept for customers?

The CISA and FBI Secure by Demand Guide, published in August 2024, says SaaS providers should retain security logs and make them available to customers for at least six months at no additional charge. Individual buyers may ask for longer, so state your retention period in your identity summary.

Does using a third-party identity provider help with procurement?

It can, if the provider has its own audit report and you can explain how it is configured. The reviewer will treat it as a subprocessor and ask for its SOC 2 report or equivalent, so choose one whose evidence you can share, and document which controls you operate and which the provider operates.

Sources

• CISA and FBI, “Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem”, 6 August 2024, https://www.cisa.gov/sites/default/files/2024-08/SecureByDemandGuide_080624_508c.pdf
• Cloud Security Alliance, “Cloud Controls Matrix and CAIQ”, https://cloudsecurityalliance.org/research/cloud-controls-matrix
• Skycloak, “Skycloak Is SOC 2 Type 2 Certified: What We Audited and Why It Matters”, https://skycloak.io/blog/skycloak-is-now-soc-2-type-1-certified/