How to answer
Do you support single sign-on (SAML or OIDC)?
A product question wearing a security costume, and the best example of a documented "no" being a better answer than a hedged yes.
Yes. We support SAML 2.0 single sign-on on our [plan] plans and above, with SCIM provisioning available. Setup documentation is at [url].
Square brackets are yours to fill in. FillTrust grades an answer like this answered “no” from your documents when your documents support it.
- Answered from
- Your product documentation, not your security documentation. This is a feature question sitting in a security questionnaire.
- Evidence to attach
- A link to your SSO setup documentation.
- Where it is asked
- CAIQ v4.0 · IAM-14SIG LiteVSA Core
This is a feature question that ended up on a security questionnaire, and it is the clearest example of why a documented "no" is a real answer rather than a gap.
If you support SAML, say so and say on which plan. Gating SSO behind an enterprise tier is entirely normal and nobody objects to it. But a bare "yes" from a customer who then discovers SSO is not on the plan they are buying produces exactly the conversation you were trying to avoid, at a worse moment. "Yes, on Business and Enterprise plans" costs three extra words and prevents it.
If you do not support it, say no plainly. Reviewers are not scoring you out of a hundred; they are building a risk picture. "No. SSO is not currently supported; access is protected by password plus mandatory MFA" tells them what they need and describes a perfectly defensible posture for a company at your stage. A hedged answer, "SSO can be discussed" or "on our roadmap", reads as a yes to procurement and becomes a commitment somebody has to deliver in eight weeks.
This matters more than it looks, because a flat no here does not usually kill a deal. What kills deals is a soft yes discovered to be a no during implementation.
Two adjacent things reviewers ask separately, so get them right:
SCIM is not SAML. SAML authenticates a person at login. SCIM provisions and, crucially, de-provisions accounts from the customer's directory. An enterprise buyer with a thousand staff cares about the second at least as much as the first, and supporting SAML says nothing about supporting SCIM.
Enforced SSO is not offered SSO. Larger customers want the ability to require SSO for their domain so that a user cannot fall back to a password. If you support SAML but any user can still log in with a password, say so. It is a different product capability and it is the one that will come up in implementation.
How this one goes wrong
Specific to this question, not general advice.
- Answering yes when SSO exists but sits behind a plan the customer is not buying. Say which plan, because they are about to find out anyway.
- Treating a no as a failure and hedging. A documented no is a finished answer; a vague yes is a support ticket in eight weeks.
- Claiming SCIM because you support SAML. They are different things and enterprise reviewers ask for provisioning separately.