On this page
What multi-tenant identity is
A tenant is one of your customers. Multi-tenant identity means all of them share one identity provider while none of them can see each other, which is the arrangement every B2B SaaS reaches sooner or later.
The alternative, one deployment per customer, is honest but expensive. Tenancy exists to give you the separation without the duplication.
One platform, a boundary per customer
Users, roles, and audit logs belong to a tenant. A customer administrator works inside their own tenant and cannot learn that another one exists.
Onboarding a customer is creating a tenant
You do not stand up new infrastructure to take on a new logo. The tenant is the unit of setup, and it is a console action.
How isolation works
Every request carries an authenticated account and tenant, and every query is scoped to them. A reference to an object in another tenant returns a not-found rather than a permission error, so the response never confirms that the object exists.
That distinction sounds pedantic until somebody uses the difference to enumerate your customer list.
Scoping is applied at the query, not the interface
The boundary is enforced where the data is read. Hiding a menu item is not isolation, and we do not count it as such.
Foreign identifiers return a not-found
A guessed identifier from another tenant produces the same response as an identifier that was never issued. There is no existence leak to probe.
Audit logs are per tenant
Each tenant's authentication and administrative events stay inside it, so you can hand a customer their own record without filtering another customer out of it.
What isolation buys you
The obvious benefit is that a mistake in one customer's configuration cannot reach another. The less obvious one is that you can answer a security questionnaire by describing a boundary instead of promising a process.
It also keeps the access model tidy. Roles mean whatever each customer decided they mean, with no global namespace to negotiate.
Roles are scoped per tenant
Two customers can both have an Administrator role that grants different things, and neither definition touches the other.
A misconfiguration stays local
A customer administrator who grants too much has done so inside their own tenant. The blast radius is one customer, by construction.
Custom domains per tenant
A tenant can sign its users in under its own domain, so those users stay on a hostname they recognize.
How it fits B2B SaaS
The sign-in your customers get is the passwordless one: a live face on a bound device, with no password and no shared code anywhere in the flow. In a B2B product that removes the shared-credential habit that spreads quietly through small teams.
Your customers connect the way they already connect, over OIDC or SAML, with SCIM behind it when they run a directory.
Each customer federates on their own terms
One customer can drive provisioning from their directory over SCIM while another manages users in the console. The tenant boundary makes that a per-customer choice.
No password to pass around a team
There is no credential that can be handed to a colleague, which is the quiet failure mode of small-team B2B accounts.
Start on the 30-day trial
No card is needed. Build your first two tenants and watch the boundary behave before you commit.
Frequently asked questions
What is multi-tenant authentication?
Multi-tenant authentication serves many customers from one identity provider. Each customer is a separate tenant. SenseCrypt isolates every tenant.
How does SenseCrypt isolate tenants?
SenseCrypt scopes each request to one tenant. Users, roles, and audit logs stay separate.
Does multi-tenancy work with RBAC?
Yes. Role-based access control applies within each tenant. Roles stay within their own tenant.
Related