The identity-federation layer: how SSO, SCIM, and just-in-time provisioning are becoming table stakes for expert-network and transcript vendors

The procurement bar for research vendors at hedge funds and asset managers has shifted. Five years ago, a buy-side analyst could sign up for an expert network or a transcript tool with a corporate email and a credit card, and infosec would learn about it on the next audit. That path is closing. Workforce identity has consolidated onto a short list of providers, and the controls those providers enforce (single sign-on, automated user provisioning, automated deprovisioning) are becoming the first filter in any vendor review. The research-vendor category is bifurcating as a result: platforms listed in the major identity provider galleries are passing security review by default, and platforms still relying on vendor-managed usernames are getting bounced before a procurement call is scheduled.

The IdP consolidation that changed the buyer

The underlying shift is not about expert networks or transcripts at all. It is about what happened to workforce identity on the buy-side between roughly 2018 and 2024. Hedge funds and asset managers that previously ran Active Directory on-premises moved payroll, email, collaboration, and the HR system of record into cloud suites, and the identity layer followed. Okta, Microsoft Entra ID (formerly Azure AD), and Ping now sit between the HR system and every SaaS tool an analyst touches. The IdP, not the vendor, decides who has access to what, and when access ends.

The consequence for research vendors is structural. Once an IdP is the system of record for workforce access, the infosec team's job becomes enforcing that every SaaS vendor respects it. A tool that issues its own usernames and passwords is, from the infosec team's point of view, a parallel directory that has to be reconciled by hand. Hand-reconciled directories are where audit findings come from. The path of least resistance is to require that every new vendor federate with the IdP from day one, and to treat vendors that cannot as exceptions that need a written justification.

The research-vendor category sat outside this discipline for a long time, partly because analysts drove procurement and partly because the vendors themselves were small enough to operate below the infosec radar. That is no longer true. AlphaSense, Bloomberg terminals, and (post-acquisition) Tegus are listed in the major IdP galleries. Several smaller expert networks and newer transcript platforms are not. The gap is becoming visible to the buyer at the RFP stage.

What SSO and SCIM actually require of a vendor

Two distinct protocols sit under the shorthand of federation, and conflating them is one of the common vendor failures. SAML or OIDC single sign-on handles authentication: when an analyst clicks a link to the research tool, the tool redirects to the IdP, the IdP confirms the user is who they claim to be, and the tool trusts that assertion. SSO alone solves the login experience and removes one password from the analyst's life. It does not, on its own, solve provisioning or deprovisioning.

That is what SCIM 2.0 does. The SCIM core schema in RFC 7643 and the protocol in RFC 7644 define how user and group records flow from the IdP into a SaaS application: create, update, deactivate, delete. A vendor that implements SCIM correctly accepts user records pushed from Okta or Entra when a new analyst is hired, updates them when the analyst changes teams, and deactivates them within minutes when the analyst leaves. A vendor that implements only SSO still requires manual user management, which means a departing analyst can keep accessing the tool until someone remembers to log in to the vendor's admin console and remove the account.

The operational distinction matters because the audit framework does not care about the login experience. It cares about whether access ends when employment ends.

The pieces that have to work

• Authentication: SAML 2.0 or OIDC, with the vendor accepting assertions from the customer's IdP rather than issuing its own credentials.
• Just-in-time user creation: when a user authenticates for the first time via SSO, the vendor creates the account record automatically, usually from attributes in the SAML assertion. No manual onboarding ticket.
• SCIM provisioning: the IdP pushes user and group changes to the vendor's SCIM endpoint. Role assignments can be driven by IdP group membership rather than a vendor-side admin console.
• SCIM deprovisioning: when the user is deactivated in the IdP, the vendor deactivates (not just unlists) the account, and sessions are terminated.
• Admin role mapping: a buy-side firm's identity team needs to be able to grant vendor-admin rights to specific IdP groups, so that leaving the firm removes admin access too.

Missing any of these forces the customer's infosec team to design a compensating control, which is a polite phrase for extra work the customer has to do because the vendor did not.

The audit mechanics: why this becomes non-negotiable

The reason this stops being a wish-list item and becomes a gate is the shape of the audit cycle. Buy-side firms carry SOC 2 Type II attestations and increasingly ISO 27001 certification because their own clients (pension funds, sovereign wealth funds, endowments) require them. The AICPA's Trust Services Criteria include common criteria CC6.1 through CC6.3, which cover logical and physical access controls: implementing access, managing credentials, and removing access when it is no longer needed.

The auditor's test for CC6.3 is specific. They pull a sample of terminated employees and verify that access to in-scope systems was removed within the firm's stated SLA, typically 24 hours. If the firm cannot produce evidence of deprovisioning for a research vendor that holds sensitive content, call transcripts, model inputs, deal-pipeline data, the finding lands on the firm's report, not the vendor's. Firms that have been through this exercise once rarely allow another vendor through procurement without SCIM.

The second-order effect is that the research-vendor evaluation now runs through the infosec team before it reaches the research head. A platform without SSO and SCIM support can be the best tool in the category and still never get a trial, because the ticket to grant access does not get approved. We read this as the single most under-appreciated procurement shift in the research-vendor space over the past three years. The buyer's workflow has changed, and the vendors that noticed early are already in the IdP galleries.

The gallery as distribution channel

The Okta Integration Network and the Microsoft Entra gallery function as more than directories of pre-built connectors. For a buy-side infosec team, they are an implicit shortlist. A vendor listed in the gallery has gone through the integration-partner review process, published a connector that follows the IdP's conventions, and signaled that it treats identity as a product requirement rather than a professional-services deliverable. The practical effect is that an infosec engineer evaluating two research vendors can enable the gallery-listed one in an afternoon and will spend two weeks on a custom SAML integration with the other.

AlphaSense is in both galleries. Bloomberg terminals are federated through BSSO and listed accordingly. Tegus's catalog entries migrated under the AlphaSense umbrella after the acquisition. Several of the newer transcript platforms and the long tail of boutique expert networks are not listed, which does not necessarily reflect the quality of the underlying service: it reflects a decision about where engineering time has been spent. For a vendor targeting the buy-side, the gallery listing is now closer in function to a Bloomberg terminal integration a decade ago. Not having it is not fatal, but it is a tax on every new deal.

The asymmetry here is worth sitting with. A gallery-listed vendor gets evaluated on its product. A non-listed vendor gets evaluated on its security posture first, and the product review only begins if the security review passes. The two conversations happen in different parts of the buyer's organization and on different timelines.

Why agent runtimes make this harder

The federation story would be straightforward if the only consumers of research-vendor APIs were human analysts in a browser. They are not, increasingly. Buy-side firms are building internal agent runtimes (sometimes on top of frameworks like LangGraph or custom orchestrators, sometimes using the Model Context Protocol as the server interface) that call expert-network and transcript APIs on behalf of an analyst. An agent that pulls transcripts, summarizes them, extracts quotes, and files them into a research management system is doing work the analyst used to do by hand, and the vendor's access logs now show the agent, not the analyst.

This breaks the clean model where one SSO session equals one human user. The questions the infosec team starts asking are different: which human authorized this agent, what is the scope of the token the agent is carrying, and when the human leaves the firm, does the agent's token stop working. OAuth 2.0 token exchange and audience-restricted tokens are the mechanisms that answer these questions correctly. A short-lived token issued to the agent, scoped to a specific API, bound to a specific user identity, and refreshable only while that user is active in the IdP, is the pattern that lets the audit continue to hold.

The MCP specification Anthropic published pushes server implementations toward OAuth 2.1 flows precisely because the agent-calling-service pattern needs standardized authentication. Our read is that vendors who treated SSO and SCIM as the finish line are about to discover that the finish line moved. The next question from a buy-side infosec team is not whether an analyst's SSO session works. It is whether the agent runtime the analyst's firm is building can obtain, scope, and revoke tokens against the vendor's API in a way that respects the IdP's view of who still works there.

A worked example

Consider an analyst at a long-short equity fund who uses a research platform through SSO, and whose team has built an agent that pre-processes new transcripts into briefing notes overnight. The analyst leaves the firm on a Friday. The IdP deactivates the account at 5pm. SSO sessions terminate. SCIM pushes a deactivation to the vendor, and the analyst's browser-based access ends.

The agent keeps running over the weekend. It is carrying a refresh token issued three months earlier, scoped to the research API, with no binding back to the analyst's IdP status. On Monday morning, the compliance team discovers that transcripts were pulled, summarized, and written into the firm's research system by an identity that no longer exists. The audit finding is unavoidable.

The fix is not exotic, but it has to be designed in: the agent's tokens are issued through an OAuth flow that re-checks the user's IdP status on every refresh, scopes are narrow enough that an orphaned agent cannot do significant damage, and the vendor exposes a revocation endpoint the firm's security team can call. Vendors that have thought through this flow will have a straightforward conversation with buy-side infosec. Vendors that have not will be told to come back when they have.

The counterargument: is this just enterprise SaaS catching up

It is reasonable to push back on the framing. Identity federation has been table stakes in general enterprise SaaS for years. CRM, HR tech, collaboration tools, and endpoint management all federate as a matter of course, and the research-vendor category is simply late to a party that started a decade ago. On that reading, there is no special story here: expert networks and transcript platforms are catching up to the same operational baseline every other SaaS category hit around 2018, and the only question is who gets there first.

We think that framing is partially right and misses the specific pressure point. The research-vendor category is late, which is why the shift feels sharp when it arrives, and the catch-up is being compressed into a shorter window than other SaaS categories had. The research-vendor sales motion has historically run through the analyst or the research head, not the infosec team, and the operational posture of many vendors still reflects that older motion. The vendors that are moving fastest on federation are the ones that have decided their next phase of growth depends on winning the enterprise security review rather than the analyst's trial.

The second reason the framing matters is the data sensitivity involved. A general SaaS tool that federates late is embarrassing. A research vendor that holds call transcripts, model inputs, and signals about a fund's active research agenda is a different risk category. The downside of a mis-managed credential at a research vendor is not inconvenience. It is a potential leakage path for information that the fund considers material to its edge. That is why infosec teams are now treating the research-vendor stack with the same seriousness they applied to CRM and HR tech five years ago, and why the gate is closing fast rather than slowly.

What this means for the vendor stack

The category-level implication, and we are deliberately not naming any single firm as a winner or loser here, is that the research-vendor stack a buy-side firm can actually deploy is becoming a function of what its IdP admin will approve. Three outcomes are plausible, and they are not mutually exclusive.

First, the IdP galleries become a de facto shortlist for new-vendor evaluations, and vendor investment in gallery listings accelerates. Vendors that treat gallery presence as a marketing item will fall behind vendors that treat it as a product requirement.

Second, the smaller expert networks and specialist transcript vendors that cannot afford a dedicated identity engineering investment either partner with a federation-as-a-service layer (WorkOS, Frontegg, and similar tooling exist precisely for this gap) or accept that their addressable market inside large buy-side firms contracts. The long tail does not disappear, but it moves toward smaller funds and family offices with lighter infosec postures.

Third, the agent-runtime layer forces a second round of federation investment on vendors that have barely finished the first. OAuth 2.1 flows, audience-restricted tokens, and revocation endpoints become the next hygiene bar, and the MCP specification becomes a reference point for how vendor APIs expose themselves to agent clients.

The uncomfortable implication is that research-vendor selection is drifting out of the research team's hands and into the identity team's. That is a quiet but durable change in who the buyer actually is, and it should shape how vendors staff their security and platform teams for the next cycle.

Questions a research analyst should put to a vendor

• Which IdPs do you federate with today, and are you listed in the Okta Integration Network and Microsoft Entra gallery under your current corporate name?
• Do you implement SCIM 2.0 for provisioning and deprovisioning, and what is the median latency between an IdP deactivation and session termination on your platform?
• When our agent runtime calls your API on behalf of a user, what OAuth flow do you support, and how are tokens scoped and revoked?
• What is your position on the MCP specification, and do you expose or plan to expose an MCP-compliant interface for agent clients?
• Can you provide the SOC 2 Type II report sections covering CC6.1 through CC6.3, and specifically the evidence of your access-removal controls?