New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Identity & Access
Access control, SSO, and conditional access for every workspace
Control who signs in and how — SSO, MFA, role-based access, and context-based conditional access — without exposing tenant data across workspaces.
Product illustration · sample data
Platform Security
18/18 evidence
RLS2FAAudit logsCompliance
9.3/10
DIY assurance score · verified May 2026
Tenant tables with RLS10
Privileged roles · 2FAEnforced
Immutable audit eventsLive
Security controls verified18/18
Product proof
Already live in the product
Backed by app modules
Running in production today: user management, access control, conditional access, SSO (SAML + OIDC), support access, and activity logs.
Protected app route: /user-management
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Conditional Access — allow / block / require-MFA by IP, geo, time and device trust
SSO via SAML 2.0 and OIDC (Google Workspace, Microsoft 365 / Entra ID, Okta)
Server-enforced TOTP multi-factor authentication for privileged roles
Role-based access with tenant-scoped users and support-access approval
Immutable audit and activity visibility on every action
Workflow
What teams can do here
Step 1
Connect an SSO provider
Step 2
Set conditional-access rules
Step 3
Assign roles
Step 4
Audit account activity
How it works
How it works
01
Connect single sign-on
Federate logins over SAML 2.0 or OIDC with Google Workspace, Microsoft 365 / Entra ID or Okta, so people sign in with your identity provider rather than a separate password.
02
Set conditional-access rules
Write policies that evaluate at login and return allow, block or require-MFA based on IP/CIDR, country, time-of-day and device trust. Policies run in priority order and match only when every condition is satisfied.
03
Enforce MFA for privileged roles
Turn on server-enforced TOTP multi-factor authentication so sensitive roles must present a second factor, checked on the server rather than trusted from the client.
04
Scope roles per tenant
Assign role-based access so users only see their own organization, and route support access through an approval step instead of standing admin rights.
05
Watch and cut sessions
Session management tracks active JWT sessions, times out idle ones, invalidates everything on a server restart, and lets an admin force-log-out a user.
Example
A worked example
Say a 120-person accounting firm decides its finance team may only reach the workspace from the office network, and always with MFA. An admin writes two conditional-access policies: a higher-priority rule blocking logins from outside the office CIDR range, and a rule requiring MFA for everyone else. A partner travelling abroad is blocked at login with a clear reason; back on the office VPN they get in, but only after the authenticator code. During a laptop-theft scare the admin force-logs-out the user's sessions from the session view in seconds, rather than waiting for tokens to age out.
FAQ
Frequently asked questions
Which single sign-on standards and providers work?
SAML 2.0 and OIDC, with Google Workspace, Microsoft 365 / Entra ID and Okta as the named providers. Users authenticate through your identity provider and land in their own tenant.
What can a conditional-access policy decide on?
IP or CIDR range, country (via GeoIP), time-of-day window and device trust. A policy matches only when all of its configured conditions hold, and the first matching policy in priority order returns allow, block or require-MFA.
What happens if the geo or policy lookup fails at login?
The engine is deliberately fail-open: individual condition checks swallow their own errors, an unknown country simply does not match a country rule, and if no policy matches the default decision is allow — so a lookup outage never locks everyone out.
Is multi-factor checked on the server?
Yes. TOTP verification is server-enforced for privileged roles rather than trusted from the browser, so a tampered client cannot skip the second factor.
Can I end a user's sessions immediately?
Sessions are tracked per user; an admin can force-log-out a user, idle sessions time out on their own, and a server restart invalidates outstanding sessions so nothing lingers after a deploy.
How is support access to a tenant controlled?
Support access runs through an approval workflow rather than standing rights, and every action is written to the activity and audit log for accountability.
SSO over SAML or OIDC, conditional-access rules on IP, country, time and device trust, server-enforced TOTP and kill-switch session control — identity guardrails that fail open, never lock you out.