Security¶

Workspace admins and owners manage security settings at Settings → Security. Every feature on this page is off by default — nothing changes for your workspace until you turn it on.

Two-factor authentication¶

Require every member to set up a TOTP authenticator (Google Authenticator, 1Password, etc.) before they can access the workspace.

1. Go to Settings → Security.
2. Toggle Require two-factor authentication on.

Once enabled, a member without an authenticator configured is blocked on their next request with a prompt to set one up in their account settings. Access resumes immediately after enrollment — no re-login required.

If you belong to more than one workspace, two-factor authentication is enforced per workspace: you can be blocked from one workspace while still working normally in another that doesn't require it.

Single sign-on (SAML / OIDC)¶

Let members with a matching email domain sign in through your identity provider instead of a password.

1. Go to Settings → Security → Single sign-on.
2. Choose a protocol:
   • SAML — enter your identity provider's metadata URL. Stackify fetches and parses it automatically; no manual XML handling required.
   • OIDC — paste your identity provider's config as JSON (authorizationUrl, tokenUrl, clientId, clientSecret, defaultScope).
3. Enter a display name (shown on the "Sign in with…" button) and the email domain that should route to this identity provider (e.g. acme.com).
4. Click Save.

From then on, anyone entering an email address ending in that domain at the Stackify sign-in screen is redirected straight to your identity provider. Anyone with a different email domain is unaffected and continues to sign in with a password. Only one identity provider is supported per workspace in v1.

Removing an identity provider (Remove) immediately stops the domain routing; affected users fall back to normal password sign-in on their next login.

SCIM provisioning¶

Auto-provision and deprovision workspace members from your identity provider (Okta, Azure AD, etc.) using the SCIM 2.0 standard.

1. Go to Settings → Security → SCIM provisioning.
2. Enter a name for the token (e.g. "Okta SCIM") and click Generate token.
3. Copy the token immediately — it's shown once and can't be retrieved again.
4. Paste the token and your workspace's SCIM base URL into your identity provider's SCIM app configuration.

Once connected, your identity provider can create, update, and deactivate workspace members directly. Deactivating a user via SCIM (active: false) disables their Keycloak login and removes their workspace access in the same request — there's no propagation delay.

Revoke a token any time from the same page if it's no longer needed or may have been exposed.

Session policy¶

Control how long a member can stay signed in while idle, and how many devices they can be signed in on at once.

1. Go to Settings → Security → Session policy.
2. Set an idle timeout (in minutes) — a session that goes unused past this window is rejected and the member has to sign in again. Leave blank for no limit.
3. Set a max concurrent sessions cap — once a member has this many active sessions, signing in on a new device signs them out of the oldest one. Leave blank for no limit.
4. Click Save.

Both settings are workspace-specific — a member in two workspaces is only subject to the policy of whichever one they're currently working in.

IP allowlist¶

Restrict a workspace to specific networks by CIDR range.

1. Go to Settings → Security → IP allowlist.
2. Enter a CIDR range (e.g. 203.0.113.0/24 for a range, or a single IP like 203.0.113.5/32) and an optional description (e.g. "Office VPN").
3. Click Add.

As soon as the first entry is added, only requests from a matching IP are allowed — everything else is rejected. An empty allowlist (the default) means no restriction.

Data retention¶

Automatically delete records past a configured age.

1. Go to Settings → Security → Data retention.
2. Set a retention period in days.
3. Click Save.

Once set, a background sweep (checked hourly) permanently deletes records older than the retention window, across every card in the workspace. This is irreversible — deleted records cannot be recovered. Leave the field blank to keep data indefinitely (the default).

Field-level encryption¶

Encrypt individual fields with a key you control (bring your own key), so the value is unreadable in the database even to Stackify — only your key vault can unwrap the key needed to decrypt it.

1. Go to Settings → Security → Field-level encryption.
2. Select a card.
3. Click Enable next to the field you want to encrypt, and paste in your Azure Key Vault key reference (e.g. https://myvault.vault.azure.net/keys/mykey).

Turning encryption on for a field with existing data doesn't happen instantly — a background process re-encrypts existing rows while new values are protected immediately. The field shows Enabling… until that finishes, then flips to Encrypted.

What still works on an encrypted field: viewing and editing individual records, formulas that reference the field.

What doesn't: search, sort, filter, and column-sort pagination all silently return no matches on an encrypted field rather than erroring, since the stored value is ciphertext. Encrypted fields are also excluded from CSV/XLSX/Parquet exports and from AI-assisted card setup, and bulk import (CSV/XLSX upload) into a card with an encrypted field is rejected — add or edit those records one at a time instead.

Rotating a key (Rotate key) re-wraps your existing data with a new key reference without touching any record data, and is effectively instant.

Disabling encryption (Disable) runs the same kind of background sweep as enabling: existing ciphertext is decrypted back to plain values while new writes go back to plaintext immediately.

Access channels¶

Turn off an entire integration channel for the workspace, independent of revoking individual keys or apps. All four default to on.

1. Go to Settings → Security → Access channels.
2. Toggle a channel off.

Turning off API keys or OAuth service accounts rejects that authentication method workspace-wide on its next request — existing keys and apps aren't deleted, so re-enabling the channel restores access immediately without recreating anything. Turning off Exports blocks only export endpoints; every other part of the workspace keeps working normally. Turning off MCP server takes effect on the MCP server's next request for the workspace, since it runs as a separate process from the main app.