Security, sessions, single sign-on and MFA

Sessions you can actually revoke

A browser sign-in issues a platform session, and the server keeps the record: a token is accepted only while its record is live, so the absolute lifetime, the idle timeout and revocation are decided server-side rather than trusted to the browser.

Security and sessions lists your active sessions, lets you sign out everywhere except the current session, and gives owners and admins an organization-wide view with per-member revocation for the case where someone leaves or a device is lost. Session creation and revocation are both written to the audit trail.

The authentication policy

The policy page sets the rules for the whole organization: require a second factor, require single sign-on, require a platform-managed session, the session lifetime, the idle timeout, and which sign-in methods are allowed.

Two design details matter in practice. Requiring multi-factor authentication asks for a grace window, so switching it on cannot lock the team out of writes in the same minute. And requiring single sign-on is refused if no active connection exists, because a setting that locks everyone out is a bug, not a policy. Refusals carry a machine-readable code - session not managed, single sign-on required, second factor required or enrolment required - and the console turns that into the right screen rather than a dead end.

Network allowlist

The policy can also restrict where your organization is reached from: list IP addresses or CIDR ranges (IPv4 or IPv6), and members and API keys can then only reach your organization's data from those networks. A copied API key used from anywhere else is refused, as is a signed-in member working from an unlisted network.

The page shows the address you are connecting from, and a list that would exclude it is refused, so you cannot lock yourself out by mistake. Narrowing the list is open to administrators; adding a range or clearing the list widens access and needs an owner.

Multi-factor authentication

Enrolment returns the secret and a QR code once, confirms with a live code, and issues recovery codes that are stored hashed and usable once each. A code from a previous step is rejected as a replay, and one step of clock drift is accepted.

Once an account has a confirmed factor, adding another, removing one or regenerating recovery codes all require a live code from a factor that already exists - a stolen session alone cannot re-enrol an account. Failed codes are throttled per account and each failure is audited, which is what makes a guessing attempt visible.

Single sign-on

A connection configures SAML 2.0 or OIDC for the organization, serves the claimed e-mail domains, and provisions users on first sign-in with the role mapped from their asserted groups. Importing identity-provider metadata reports the certificate fingerprint so you can confirm it out of band; the platform also publishes its own metadata for the provider.

Assertions are verified against the configured certificate only, and the part of the document that was signed is the part that is read, so a response that wraps a signed assertion inside an unsigned one fails. Recipient, audience, request correlation and validity window are all checked, and a sign-in is single-use.

One deliberate limitation: sign-in is service-provider initiated only. A response that arrives with no request of ours behind it is refused, which is exactly what makes replaying a captured assertion impossible. Test the connection's readiness check before you enforce it.

Revoking access for a person

1. Open Users and set the account's role to viewer, or remove the membership.
2. Open Security and sessions and revoke that person's sessions.
3. If provisioning comes from your identity provider, deprovision the account there - it deactivates the user, removes memberships and revokes the live sessions.
4. Check the audit log to confirm what happened and when.

Screen-by-screen reference

These pages were checked in the organization console on 8 October 2026 using an isolated sample organization. Controls can differ by role, plan, record state and configured providers. Each page below explains its purpose, a practical workflow, the visible controls and what to verify afterward.

Security and sessions (/settings/security)

The page combines this sign-in's method, MFA enrollment, personal and organization sessions, policy controls and security posture.

Review active sessions and MFA enrollment before changing organization sign-in policy. A stricter MFA, SSO, managed-session, or network requirement can affect current members, so check posture and provider readiness first. Save the policy with the appropriate authority, then verify a normal sign-in path and revoke sessions that should no longer remain active.

Relaxing a policy requires the owner; a stricter policy can immediately affect sign-in.

Controls and options

• Add an authenticator app, confirm a code and store recovery codes securely before relying on MFA.
• Revoke a session or Sign out of other sessions to end unwanted access.
• Set MFA, SSO, managed-session and network rules, session lifetime and idle timeout; Save policy applies allowed changes.
• Inspect Security posture for unmet requirements and organization sessions for active devices.

Single sign-on (/settings/sso)

SSO connects a claimed email domain to a SAML or OIDC identity provider and records linked identities and recent sign-ins.

Claim only domains the organization controls and configure SAML or OIDC values from the identity provider's verified settings. Test a complete sign-in and inspect recent requests before enabling enforcement or automatic member creation. A default role controls starting access, while plan seats and organization policy still limit who can join.

A connected IdP does not prove every user of a domain is authorized for this organization.

Controls and options

• Choose protocol, name, claimed domains and default role for just-in-time members.
• Enter the IdP endpoint, entity or client data and certificate as required, then Create connection.
• Provision members on first sign-in, require MFA or refuse alternative methods only after testing the connection.
• Use Configured connections and Recent sign-in requests to diagnose redirects and claims.

SCIM provisioning (/settings/provisioning)

SCIM lets an identity provider create, update and deactivate this organization's members using a scoped token.

Create a separate SCIM token for the identity-provider connector and copy it once into the provider's secure configuration. Use the displayed base URL and schemas to test user and group creation, update, and deactivation. Review Team after the first sync for seat limits, role assignment, and account status; rotate or revoke the token when the connector changes.

SCIM cannot change the organization's owner through this connection.

Controls and options

• Create a named SCIM token and copy it once into the identity provider.
• Use the displayed base URL and schema notes to configure user and group provisioning.
• Rotate or revoke tokens when the connector or operator changes.
• Check Team after a sync to confirm roles, seat use and account status.