Single sign-on against their provider
Users arrive already authenticated by their own company. No extra password, no extra thing for their IT team to support.
Identity
The question that decides enterprise deals.
Before security asks about encryption, IT asks whether your product works with their identity provider. Getting this wrong stalls a deal further than almost anything else.
An enterprise customer does not want to manage another set of passwords for your product, and their security team does not want an account to keep working after someone has left. That is what single sign-on and SCIM provisioning are actually for: access that starts and stops in one place, theirs. This is the most common hard blocker in enterprise procurement, and it is far cheaper to build in than to retrofit once a customer is waiting on it.
Off until you need it. Turning it on is a toggle — not a project, not a rebuild. See how capability arrives as you grow.
Providers
What we connect to
Available means built and running in production today. On request means we will build it for your application — it is not pre-built, and we will not imply otherwise.
Available
- Google WorkspaceSign in with Google
- Microsoft accountsSign in with Microsoft
- Multi-factor authenticationTOTP and passkeys, enforceable per role
On request
- Okta
- Microsoft Entra IDFormerly Azure AD
- Generic SAML 2.0Works with any compliant identity provider
- OpenID Connect
- SCIM 2.0 provisioningAutomatic account creation and, critically, deprovisioning
- SplunkAudit log streaming
- DatadogAudit log streaming
- Microsoft SentinelAudit log streaming to their SIEM
What you get
The part that is not just an API key
Provisioning and deprovisioning via SCIM
Accounts are created when someone joins and disabled when they leave — automatically, from the customer's directory. This is the half people forget, and it is the half security cares about.
Roles mapped from their directory groups
Group membership on their side becomes permissions on yours, so access is managed where the customer already manages it.
MFA and passkeys, enforceable per role
Administrators can be held to a higher standard than ordinary users, rather than everyone being held to the lowest.
Audit log streaming to their SIEM
Sign-ins, permission changes, exports and admin actions pushed into Splunk, Datadog or Sentinel, so your application appears in the customer's own security monitoring.
Session control
Timeouts, rotation on privilege change, and central revocation — so access ends when the customer says it ends.
For example
What this looks like in practice
The first enterprise pilot
Their IT team asks for SAML on the kick-off call. Being able to say yes without a three-month project is frequently the difference between a pilot and a polite no.
A regulated buyer
Their auditor wants evidence that access is removed on termination. SCIM deprovisioning plus an audit trail is the evidence.
A security team that monitors everything
They will not accept a system whose logs they cannot see. Streaming your audit events into their SIEM closes that objection.