Sign-in security & SSO · Included with Core — every plan

How people get in, and what stops everyone else

Passkeys and a second factor, single sign-on through your own identity provider, users pushed in over SCIM, rules for where sign-ins may come from, and an audit log you can forward to your own tools. None of it is an add-on.

Sign-in & Access

Proving identity, and who can reach the instance

On every plan

How people prove it’s them

Passkey

WebAuthn / device biometrics

Authenticator app

Time-based one-time codes

Recovery code

One-time backup codes

Email magic link

Passwordless sign-in link

Sensitive actions ask you to re-authenticate before they run.

Who can reach your instance

Office range 203.0.113.0/24
Allow
Country allowlist: IL, US, DE
Allow
Everything else
Deny

Enforcement Mode

Country List ModeAllowlist
Block requests where geo can’t be determined
Dry Run — log blocks without rejecting
Preview rules in dry-run — see what they’d block before you enforce them.
Sign-in Security

Passkeys, step-up,
and a locked front door.

People sign in with a passkey, an authenticator app, a one-time recovery code, or a passwordless email link. A device you approve can skip the second factor for a while — and you can revoke any device, or every device at once, the moment something looks wrong. Sensitive actions ask them to re-authenticate first, repeated wrong passwords lock the account, and abusive traffic is rate-limited at the gateway. You can also fence the instance to specific IP ranges or countries — and try any rule in dry-run before you turn it on. Every sign-in and access decision is written to an append-only log. And the front door is yours: your logo, company name, and brand colour carry across the login screen and the whole console — set them on the in-app Branding page any time after sign-in, no redeploy.

Sign-in
Passkeys + MFA
Sensitive ops
Step-up re-auth
Perimeter
IP & geo rules
Single sign-on & provisioning

Your identity provider stays in charge.

If you already run an identity provider, Zonitix signs people in through it and takes its users and groups from it.

Single sign-on

Sign in to Zonitix through your own identity provider, over OIDC or SAML 2.0. One identity provider per instance.

Just-in-time accounts

Optionally create a Zonitix account the first time someone signs in through your identity provider. It is off until you switch it on.

Inbound SCIM 2.0

Let your identity provider push users and groups into Zonitix. Each connection has its own token, which you can revoke.

A second factor, by policy

Require a second factor for everyone or for chosen groups, with passkeys, an authenticator app and one-time recovery codes to choose from.
Defence & evidence

Keep attackers out, and keep the record.

Automatic blocking

Block an address that keeps failing to sign in. It is opt-in, and it starts in dry-run: it shows what it would block before it blocks anything. Blocks expire on their own.

Send the audit log to your SIEM

Forward audit events to Splunk, Datadog, a syslog server or an HTTPS webhook. Every destination is encrypted in transit; there is no plaintext option.

API tokens

Personal tokens for scripts and integrations, limited to the scopes you pick. Creating one asks you to re-authenticate, and an administrator can see and revoke every token.

Your data, exportable

An administrator can export the company’s data from the instance as a single archive, whenever they choose.

The audit trail itself, and how it is made tamper-evident, is described on the Compliance page.

See it live

See it running on a live instance.

A 30-minute walkthrough on a live Zonitix instance — no slides, no commitment.

In the walkthrough

  • Passkeys and a second factor

    How your people sign in.

  • Single sign-on

    Through the identity provider you already run.

  • Users pushed in over SCIM

    Users and groups come from your provider.

  • Sign-in rules and the audit log

    Where sign-ins may come from, and a log you can forward to your own tools.