B2B Authentication Requirements: The Buyer's Checklist

Key takeaways

• A capability name is answered yes by every vendor and predicts nothing. Write requirements as assertions with an acceptance test attached.
• The deepest lock-in is not pricing. It is a vendor user object you are required to adopt as your own, and it does not look like lock-in on day one.
• Deprovisioning should arrive as an event you act on, never as a deletion the vendor performs on your user record.
• Domain gating is the line that stops your largest customer from silently getting a second, empty workspace the day they enable SSO.
• Ask whether the audit log is populated by the platform or emitted by your application. Both are defensible; finding out during a compliance review is not.
• Estimates given against a feature list are always weeks. Ask for the estimate against the acceptance tests instead.

Why capability lists fail

Every requirement below is written in that form. Each has a stable ID, a priority, and a test you run rather than a question you ask. The IDs are used by the RFP builder, which turns a selection of them into a vendor-ready document, and the tests line up with the CIAM proof of concept script.

Two conventions:

• MUST means walk away if unmet. SHOULD means negotiate, or plan to build the gap yourself and price that work into the comparison.
• The acceptance test is deliberately an action you perform. "Does your platform support X" invites a yes. "We will send both PATCH shapes and confirm each deactivates the user" does not.

Authentication and federation

This is the layer everyone evaluates and the layer that differentiates least, because SAML and OIDC support is table stakes. The requirements worth writing down are the ones about what happens around the assertion rather than the assertion itself: how it is validated, what it carries, and whether you can turn the whole thing off without breaking what it created.

ID	Requirement	Priority
AUTH-01	Enterprise users sign in with SAML 2.0 or OIDC against their own IdP	MUST
AUTH-02	Assertions cryptographically verified (signature, issuer, audience, recipient, expiry) before identity resolution	MUST
AUTH-03	The assertion carries the organization or connection identifier	MUST
AUTH-04	Identifier-first SSO detection routes an enterprise email to its connection	SHOULD
AUTH-05	MFA policy enforceable per organization, not only globally	SHOULD
AUTH-06	Per-tenant, per-environment enablement with a non-destructive kill switch	SHOULD
AUTH-07	Coexists with your incumbent auth provider, no forced migration	SHOULD

AUTH-02 is the one to actually test. Submit a tampered signature, a wrong audience, an expired assertion, and a replay of a previously valid one. All four must be rejected, and each rejection must land in a log you can query. Validation performed after identity resolution is the same bug as no validation, arranged differently.

AUTH-03 exists because tenancy inferred from an email domain breaks. It breaks on shared consumer domains, on contractors, on an acquisition where two organizations legitimately share acme.com, and on any customer with more than one IdP. The connection identifier is the only thing in the flow that reliably says which workspace this person belongs to.

AUTH-06 is about being able to start. A kill switch that deletes provisioned users when you flip it is worse than no kill switch, because nobody will ever dare use it. Test it in staging with a live tenant: users, workspaces, memberships, and roles must all survive.

AUTH-07 is the requirement most teams forget to write down. Enterprise SSO is nearly always added to a product that already has a live self-serve user base on an incumbent provider. A platform that requires migrating everyone before the first enterprise customer goes live has turned a two-week integration into a two-quarter programme, and that cost never appears in the pricing comparison.

Identity model and account linking

This section contains the most consequential requirement in the document and the one least likely to be in your first draft. It is about ownership: whose user record is authoritative, whose identifier is canonical, and what rules decide that two identities are the same person. Get it wrong and nothing breaks immediately, which is precisely why it is dangerous.

ID	Requirement	Priority
IDM-01	Users resolve to an identity native to your own user space, not a vendor-owned object you must adopt	MUST
IDM-02	Your own generated identifier stays canonical; nothing requires it to equal the vendor subject	MUST
IDM-03	Per connection, the platform reports email verification status and domain-ownership status	MUST
IDM-04	Account-linking rules are deterministic, documented, and never silently merge on email match	SHOULD

IDM-01 is the deepest lock-in vector in the category. If the vendor's user object is your user object, your data model is rented. Every feature you ship afterwards deepens the dependency, and your migration cost grows monotonically with your product. The test is simple: confirm you can hold your own user row, keyed by your own identifier, with the vendor's subject stored as one more foreign key on it. If the integration guide tells you to key application tables on the vendor's ID, you have found the answer.

IDM-02 is the same argument at the identifier level. Identifiers propagate into URLs, API responses, the warehouse, and your customers' own integrations. Once they are there, the vendor's subject is not a vendor detail, it is your public contract. The schema-side treatment is in identity data modeling.

IDM-03 and IDM-04 are an account-takeover control, not a data-quality nicety. Automatically linking an unverified asserted email to an existing account is a takeover primitive: an attacker who can make an IdP assert a victim's address walks into the victim's account. You cannot make a safe linking decision without knowing whether the platform is asserting a verified email, a verified domain, or neither, so get the field names and their exact semantics in writing.

Organization modelling and provisioning

B2B identity is organization modelling with authentication attached. These four requirements determine whether your first twenty enterprise customers onboard cleanly or generate an operational ticket each, and ORG-04 in particular is the difference between a smooth rollout and a confused customer.

ID	Requirement	Priority
ORG-01	Organizations and memberships are first-class; a user may belong to zero, one, or many	MUST
ORG-02	JIT provisioning: first SSO login from an unknown org creates a workspace, seeding that user as owner	SHOULD
ORG-03	An operator can attach an org to an existing contracted workspace	SHOULD
ORG-04	Domain gating excludes contracted domains from JIT and attaches instead	SHOULD

The three provisioning requirements only make sense together. ORG-02 handles the company you have never heard of, ORG-03 handles the company you already signed, and ORG-04 is the routing rule that decides which of the two paths runs. Ship ORG-02 without ORG-04 and your largest customer acquires a second, empty workspace on the day they turn on SSO, while a year of their real data sits in the workspace they have been using all along. The failure is silent on your side and extremely loud on theirs.

ORG-01 is the multi-membership requirement. One membership per user is the cheapest assumption to adopt and the most expensive to remove, and consultants, agencies, and acquisitions all produce a legitimately two-organization human.

Customer self-service onboarding

Connection setup is the single largest source of implementation support load in B2B identity, and almost none of it is work your team can do. The configuration lives inside your customer's identity provider, so anything that forces a round trip through you adds days to their rollout and a ticket to your queue.

ID	Requirement	Priority
ONB-01	Customers configure SSO and directory sync themselves through a hosted admin portal you link to	SHOULD
ONB-02	Customers can diagnose their own SSO login failures without contacting you	SHOULD
ONB-03	Certificate expiry is notified ahead of time, with self-serve rotation	SHOULD

Test ONB-02 by deliberately breaking things. Misconfigure an attribute mapping, then a certificate, and read the error exactly as the customer's admin sees it. An opaque failure code means every misconfiguration in your customer base becomes a ticket in your queue, escalated to a vendor you are relaying for.

For ONB-03, establish the notification lead time, the channel, and who actually receives it. "It is visible in the dashboard" means nobody receives it, and the first symptom of an expired signing certificate is an enterprise customer locked out on a Monday morning.

Directory sync and deprovisioning

This is the half of enterprise identity that fails silently, and it is where the requirements list earns its keep. Provisioning is convenient. Deprovisioning is the reason the protocol is mandatory above a certain contract value, and it is the thing a security questionnaire will ask you to evidence with a number.

ID	Requirement	Priority
SCIM-01	The vendor hosts and maintains the SCIM 2.0 endpoint; you consume events	MUST
SCIM-02	Deprovisioning arrives as an event you act on, not a deletion the vendor forces	MUST
SCIM-03	Soft signal (active false) and hard signal (deleted) surfaced distinctly	MUST
SCIM-04	Directory group membership changes map to application roles	SHOULD
SCIM-05	End-to-end deprovision latency documented, split vendor-side versus IdP push	SHOULD
SCIM-06	Operations are idempotent and replay-safe	MUST
SCIM-07	Per-connection bearer token, failing closed before any mutation, rotatable	MUST
SCIM-08	Deprovisioning the last owner of a workspace is visible to you	SHOULD
SCIM-09	Both Entra and Okta PATCH shapes for deactivation are handled	MUST

SCIM-02 is the requirement that protects your database. Your user row has foreign keys, content ownership, and audit history hanging off it. A deletion performed on it by a third party, triggered by an event in a system you do not control, is a data-integrity incident rather than a lifecycle feature. The event model lets you decide: suspend, reassign ownership, retain for audit, then delete on your own terms.

SCIM-03 is why the event model needs two signals. An offboarding and an erasure request mean different things and deserve different handling. Collapsing them into one event forces you to guess, and the guess is wrong in one direction or the other.

SCIM-05 goes straight into your own contracts. You will be asked to state a deprovisioning SLA. Part of that number is the vendor's processing, and part is the IdP's push behaviour, which neither of you controls. Get the split before you commit to a figure in writing, then measure it yourself, because the documented number is rarely the observed one.

SCIM-08 is the one nobody writes down until it happens. An IdP offboarding an administrator will cheerfully orphan a paying workspace. Nobody notices until someone needs to change a billing detail and there is no one left who can.

SCIM-09 is the conformance test that predicts support load. RFC 7644 permits both a pathed and an unpathed replace operation for deactivation, and the two major IdPs send different ones. A platform that handles one and rejects the other works for half your enterprise customers and fails for the rest. Details in SCIM provisioning.

Sessions, audit, privacy, and security

These four domains rarely block a deal and frequently create the incident you spend a quarter cleaning up. They are grouped here because they share a property: each is easy to claim, cheap to test, and expensive to discover late.

ID	Requirement	Priority
SESS-01	No requirement to adopt a second browser cookie or the vendor's session as yours	MUST
SESS-02	Configurable session lifetime, forced re-authentication, IdP-driven single logout	SHOULD
SESS-03	Revocation-to-effect latency measurable per user, device, and tenant	SHOULD
AUDIT-01	Event stream covering connection lifecycle and directory sync, forwardable to your audit store	MUST
AUDIT-02	SSO and sync failures observable and alertable, including a connection going quiet	MUST
AUDIT-03	Customer-facing audit export with a retention window stated in days for your tier	SHOULD
AUDIT-04	Vendor states whether the audit log is platform-populated or app-emitted	SHOULD
PRIV-01	Provider-agnostic enumeration of every subject linked to one user	MUST
PRIV-02	Vendor-side deletion callable from your workflow, confirming completion	MUST
PRIV-03	Residency or region controls stated, with sub-processor change notification	SHOULD
SEC-01	Current SOC 2 Type II report and a signable DPA	MUST
SEC-02	Encryption at rest and in transit, documented key management and password hashing	MUST
SEC-03	Bot, credential stuffing, brute force, and volumetric defenses, tunable per endpoint	MUST
SEC-04	Documented API rate limits, including per-tenant dimensions	MUST

AUDIT-02 is the test that teaches you the most. Revoke a working sync token without telling anyone and wait 48 hours. Usually nothing arrives, because a connection that is not being called generates no failing request to report. That is not necessarily a disqualification. It tells you which alarm you have to build yourself, and absence-of-events is the only detector that works.

AUDIT-04 separates two products that share a name. An audit log the platform populates is an audit trail. An audit log you populate by sending events is a storage product. Both are defensible purchases; discovering which one you bought after a compliance review has started is not.

PRIV-01 is a completeness problem. One human may be a password identity, two social subjects, and a federated identity. An erasure obligation covers all of them, and an API that only answers one provider at a time makes completeness impossible to demonstrate.

SEC-04 gets discovered in production otherwise, usually during your largest customer's onboarding, when their initial directory sync fires several thousand requests in a burst.

Portability, commercial terms, and the question to end on

Exit requirements are the ones with no leverage after signature, so they belong in the RFP rather than the renewal. Ask during evaluation, in writing, and test the answer rather than accepting it.

ID	Requirement	Priority
EXIT-01	Password hashes exportable, with algorithm, parameters, encoding, and a contract clause	MUST
EXIT-02	Users, organizations, memberships, roles, and configuration all exportable	SHOULD
EXIT-03	Passkey portability addressed: RP ID stability and credential record export	SHOULD
COMM-01	Pricing modelled against your three-year projection, including which requirements gate a tier	SHOULD
COMM-02	Solutions engineering alongside your engineers, through a shared channel	SHOULD
COMM-03	Realistic estimate of time to first enterprise customer live and engineer-days on your side	SHOULD

EXIT-01 deserves a real test rather than an assurance. Request an export during evaluation and import one hash into a sandbox somewhere else. Check that the contract clause covers credentials and not only "customer data", which frequently means profile data and excludes hashes. The mechanics are in password hash migration.

COMM-03 is the most revealing question in the document, and it should be the last one you ask. An estimate given against a feature list is always a few weeks. An estimate given against these acceptance tests, with the IDs referenced, is the honest number. The gap between the two answers tells you how well the vendor understands the work they are about to be part of.

Using this list

Do not send all of it. A padded requirements list produces a padded response, and every line you include is a line you have committed to testing. Select the ones that match your actual situation, mark the MUSTs honestly, and cut the rest.

The RFP builder does the selection and generates the document with acceptance tests attached, in Markdown you can edit. Then run the shortlist through the proof of concept script, which is the same tests arranged as a two-week schedule. The consumer-side equivalent of this document is B2C authentication requirements.