Single sign-on

What to write when they ask if you support single sign-on

The row asks whether customers can sign in with their company login, which identity providers that covers, and which plan it starts on. Write SAML only when sign-in uses SAML. Write OIDC only when sign-in uses OIDC. They are not the same. If you do not have it yet, say not yet.

This is a practical note for a security review, not legal advice.

Updated October 9, 2026

What the row is asking

Reviewers ask if the customer's users can sign in with their own company login. They ask which identity providers, which protocol, and which plan that starts on. Those are separate sentences.

This is a different row from MFA for the people on your team who can open production. That row is who can still reach the data. This row is how the customer's own users sign in.

Onplana, on a page dated October 7, 2026, asks "Is SSO supported, and through which protocols?" The page says a good answer names "SAML 2.0 or OIDC, and the plan it starts on." Onplana writes vendor-review questions. This is their list, not a founder asking for help. SAML and OIDC are not interchangeable. Write the protocol you actually support, and the plan it starts on.

Cybersecify, on a page that says Updated October 3, 2026, separates end-user sign-in from MFA for admin accounts. The sample for end users says "SSO via SAML or OIDC." Ashok Kamat wrote the page for Cybersecify, a penetration-testing firm. Those cells are samples the firm wrote, not a protocol from a named customer. Write one protocol, the one that is true.

A post on r/SaaS, May 6, 2026, is written as the person selling. Their first enterprise customer asked "do you support SSO + SCIM?" They did not have it. A comment on May 8, 2026 says "SSO is the first ask." That post is earlier than the usual window for this note. It is included because the same row is on the October 7 page.

A comment on r/SaaS, June 23, 2026, names "SSO/SAML" as one of the few rows a long questionnaire turns on. The commenter does not name a company. Nothing in these sources says a deal stalled on single sign-on.

SCIM is the word on the form for removing an account from the customer's directory when someone leaves. Write it only when you actually remove those accounts. Company login is not that removal.

What reviewers accept

If company login is on for a plan, name that plan. Do not write every plan when only one has it.

If it is on for some identity providers, name those providers, and the date you checked.

Write SAML only when sign-in uses SAML. Write OIDC only when sign-in uses OIDC. Write both only when both work. They are not interchangeable.

If you do not have it, say not yet. Do not tick Yes.

Write SCIM only when you remove accounts from the customer's directory. If people can sign in and you do not remove the account when they leave, do not write SCIM.

An honest gap is a complete answer. The answer that fails is a Yes you cannot stand behind when they ask which protocol, which providers, and which plan.

Answers you can paste

Use the line that is true. Replace the brackets. Delete anything that is not true. Keep one protocol unless both work.

Yes, on this plan
Customers on the [plan name] plan can sign in with their company login. The protocol is [SAML 2.0 / OIDC]. Keep only the protocol you support. SAML and OIDC are not the same. Other plans cannot.

Yes, for these identity providers
Customers can sign in through [identity provider names]. The protocol is [SAML 2.0 / OIDC]. Keep only the protocol you support. We checked this on [date].

Not yet
Customers cannot sign in with their company login yet. We will not write that we support single sign-on.

SAML, when that is the protocol
Sign-in uses SAML 2.0. We do not support OIDC. We will not write both.

OIDC, when that is the protocol
Sign-in uses OIDC. We do not support SAML. We will not write both.

Both protocols, when both work
Sign-in uses SAML 2.0 and OIDC. We write both only because both work.

We remove accounts from their directory
When someone leaves the customer's company, we remove that person's account from their directory. That removal is SCIM. We checked this on [date].

We do not remove accounts from their directory
We do not remove accounts from the customer's directory. Company login is a separate sentence. We will not write SCIM.

What not to write

Do not write SAML or OIDC as if either one will do. Write the protocol that is true.

Do not write SCIM because the form asks for it. Write it only when you remove accounts from the customer's directory.

Do not write that every plan has company login when only one plan does.

Do not answer the MFA row here. MFA for the people who can open production is a different row.

Do not put the identity company on the vendor list until you type that row.

Do not invent a protocol, a plan name, or a deal that stalled.

Where this answer lives

Keep these sentences in the questionnaire answer you control.

The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.

You can list the identity company as a vendor row once you type it. If the editor already knows that company, a suggestion can offer a location or a public agreement link, and only after you use it.

There is no field for single sign-on, a protocol, a plan name, or a SCIM answer. The page does not fill this row.

MFA for the people on your team who can open production, and who those people are, is in the access review guide.

The identity company belongs on the vendor list only after you type that row. Why reviewers ask for the list is in the vendor list guide.

How to answer the rest of a vendor security questionnaire is in the security questionnaire guide.

Where that identity company processes data, once you have typed the row, is in the processing location guide.

Optional next step: a living page

The sentences above are enough for the row in front of you.

If you want one link for the companies that handle customer data, Trust Prep is a page you edit when a company changes. The page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it. You can add the identity company once you type that row.

The page has no field for single sign-on, a protocol, a plan name, or a SCIM answer. Those sentences stay in the answer you keep.

Create your trust page