Security and SSO

Settings → Security shows your workspace’s security settings to everyone; only admins change them.

Single sign-on

Satyakod supports SAML single sign-on with your identity provider (Okta, Microsoft Entra ID, Google Workspace and others). To set it up, write to support with your identity provider’s details; we connect it and it shows here. Then:

• people whose email is on your domain sign in with Continue with SSO;
• Require SSO for all members stops password sign-ins, except for one break-glass admin.

Requiring SSO is part of the Enterprise plan. On other plans the switch shows as locked (see Plans and features). If your plan changes, SSO that is already set up keeps working for sign-in, and you can always turn Require SSO for all members off.

SCIM provisioning

With SCIM, your identity provider adds and removes people for you: new people join as viewers, and someone deactivated in the directory loses access at once. Their role can then be changed in Team and roles. Ask support to switch it on. SCIM provisioning is part of the Enterprise plan. If your plan changes, your identity provider can still remove people (deactivations and deletions apply), but it can’t add anyone new.

Two-step verification

Require two-factor authentication is on by default: everyone must add a method the next time they sign in. The page shows how many members are enrolled. Methods are in Your account.

Password policy

Enterprise plans can set a policy: how many past passwords can’t be reused, and how many failed attempts lock an account and for how long. Ask support to set yours. Someone in several workspaces gets the strictest combination.

Signing keys

Each workspace has its own key that signs your serials. Auto-rotate replaces it every 6, 12 (default) or 24 months, or only when you choose; Rotate now… does it at once. Old keys keep verifying codes already printed; new batches use the new key. The table shows where each key is kept.

Key protection

Key protection chooses where the key that signs new batches is kept:

• Standard (included): the key is a random secret, encrypted at rest in Satyakod’s database and only decrypted inside our servers to sign and check codes.
• AWS KMS (add-on): a dedicated key for your workspace in AWS Key Management Service. The key never leaves KMS, not even to Satyakod: our servers ask KMS to use it, once per batch. It is created in the AWS region shown on the page, for example ap-south-1 (Mumbai).

AWS KMS is a paid add-on, billed per key on your contract. Add it from Billing: Add AWS KMS on this page opens Billing → Manage subscription with “Dedicated AWS KMS key” in your order, priced for the rest of your term (see Add-ons). Admin and Billing roles can buy it; other roles see the price and ask a billing admin. Once you’ve confirmed the order, an admin clicks Switch to AWS KMS…. Where the add-on is priced by your account team instead, the page shows Request AWS KMS. What switching does:

• a new key is created for you and becomes the active key; new batches are signed with it;
• your current key moves to verify only, so every code already printed keeps verifying;
• later rotations, automatic or Rotate now…, create the new key in AWS KMS too, and each rotation adds a key to the add-on;
• switching back to Standard starts a new Standard key; your AWS KMS keys are kept so codes signed with them keep verifying.

Keys are never deleted, because codes signed with a deleted key could no longer be checked. Each switch is recorded in the audit log.

Data region

Your workspace’s data stays in the region chosen at setup (India, EU or US). Moving it needs a request to support.

Audit log

The audit log records who did what and from where: invitations and role changes, security changes, key rotations, signed and revoked batches, downloads of print files, evidence and verification keys, and exports. Entries are kept for 7 years, then deleted. Everyone can view it here, on every plan. On Enterprise, admins also see Export CSV (the last 90 days), or export longer periods from Reports.