Security & Trust Center
Reference for how Intempt authenticates users, enforces access control, and records an audit trail: authentication methods, MFA, SSO/SCIM, encryption at rest, and log retention by plan tier.
Overview
Intempt runs its own identity provider. There's no third-party auth vendor in the request path: login, session management, single sign-on, and permission checks are all handled by Intempt's auth service, and every action of consequence is written to an append-only audit trail. This page is a reference for the controls behind both. It covers what they are, how they're stored, and how long records are kept. For the screens that manage these settings day to day, see Organizations & projects and Access management.
Authentication methods
Intempt has no password field anywhere in the product. Every login uses one of these methods:
| Method | How it works |
|---|---|
| Email OTP / magic link | Enter an email, receive a one-time code or magic link. No password is ever set or stored. |
| Social OAuth | Sign in with Google, Microsoft, or Apple. Intempt brokers the OAuth flow directly. |
| Passkeys (WebAuthn) | Passwordless sign-in via a platform authenticator or security key. |
| SSO (SAML 2.0 / OIDC) | Enterprise identity provider login, IdP-initiated or SP-initiated, with just-in-time member provisioning. |
📘 Good to know
Sessions record which method was used to sign in. Reauthentication for sensitive actions must match that same method, so a passkey login can't be reauthenticated with an email code.
Multi-factor authentication
MFA is configured per organization from the Security tab in Org Settings:
| Setting | Values |
|---|---|
| Policy | Off, required for non-SSO members, or required for everyone |
| Grace period | 0, 7, 14, or 30 days before enforcement begins for existing members |
| Allowed factors | Email code, passkey; either can be turned off independently |
| Maximum session length | How long a member stays signed in before reauthenticating |
Members who sign in through SSO inherit verification from their identity provider, so the MFA policy doesn't prompt them a second time. Turning off a factor doesn't unenroll members already using it.
SSO and directory sync
| Capability | Detail |
|---|---|
| SSO protocols | SAML 2.0 and OIDC, one configuration per organization |
| Provisioning | Just-in-time (JIT) member creation on first SSO login, or SCIM 2.0 for directory-driven provisioning and deprovisioning |
| Group mapping | SCIM identity provider groups map to Intempt roles and teams |
| Domain verification | A DNS TXT record verifies ownership before a domain can be used for SSO enforcement |
SCIM tokens are shown once at generation and stored as a SHA-256 hash. Intempt can't retrieve the original token value after that point.
Roles and permissions
Access is controlled by two independent role systems: organization roles (billing, members, org settings) and project roles (data and features inside one project). Every permission check runs against these roles, cached for up to 60 seconds and invalidated immediately on any role or membership change.
See Access management for the full role tables and custom role builder.
API keys
API keys are scoped to public, private, or admin levels. The secret is Vault-encrypted at rest and looked up by prefix; validating an incoming key decrypts the stored value for a constant-time comparison. Revealing or regenerating a key is written to the audit log.
See API Keys for key types and setup.
Audit logging
Every service on the platform writes to a single, append-only event log. There are no update or delete endpoints for audit events, so once written, a record can't be edited.
Each event captures:
| Field | Description |
|---|---|
| Actor | Who performed the action: a user, an API key, an automated system process, or an external integration |
| Action | A dot-namespaced action key, for example auth.login.success or authz.role.create |
| Target | The resource affected, if any |
| Outcome | success, failure, or denied |
| Severity | info, notice, warning, or critical |
| IP and user agent | Captured when available |
| Diff | Before/after state for changes that modify a record |
The Audit log tab in Org Settings has two views: Audit log (org-level events, covering SSO, RBAC, billing, members, API keys, and project lifecycle) and Login history (sign-in attempts across every method). Both filter by time range, actor, target, action, outcome, or severity, and export to CSV. Project-level events show up in that project's own audit log instead.
Retention by plan
| Plan tier | Retention |
|---|---|
| Free | 7 days |
| Pro | 90 days |
| Organization | 365 days |
| Enterprise | 730 days |
Retention is set automatically by your organization's plan and updates when you change plans.
Data protection at rest
| Data | How it's protected |
|---|---|
| TOTP secrets | AES-GCM encrypted at rest |
| Passkey credentials | Stored as raw public key material (COSE format) |
| API keys | Vault Transit encrypted at rest, looked up by prefix |
| SCIM tokens | SHA-256 hashed at rest, shown once at generation |
| Session tokens (JWTs) | RSA-signed, validated by every platform service against a published key set |
| CSV exports | Download links are signed and scoped to the requesting user's organization; export files expire 24 hours after generation |
Rate limiting is enforced at the API gateway, ahead of every service, rather than independently by each service.
Use cases
- Enforcing MFA ahead of a compliance deadline. Turn on the org-wide MFA policy with a grace period, then check enrollment status in Org Settings to follow up with anyone still pending.
- Connecting an enterprise identity provider. Configure SAML or OIDC once per organization, verify the domain, and let JIT provisioning create member accounts as people sign in.
- Automating provisioning from a directory. Set up SCIM instead of JIT so member creation, role assignment, and deactivation are driven entirely by your identity provider.
- Restricting authentication methods. Turn off email-code sign-in and require passkeys only, for organizations that want to eliminate phishable factors.
- Investigating a compromised account. Filter the audit log by actor to see every action that account took, then cross-check Login history for the sign-ins around that time.
- Proving how long you can look back. Check your plan's retention row above before promising a customer or auditor a lookback window the org's tier doesn't support.
- Rotating a leaked API key. Revoke it from the API keys tab. The action is written to the audit log automatically, and the old key stops authenticating immediately.
- Exporting evidence for a security review. Filter the audit log to the relevant time range and actor, then export to CSV; the download link expires in 24 hours.
Where to go next
- Organizations & projects for where the Security and Audit log tabs live alongside Team, Roles, Domains, and API keys.
- Access management for the full organization and project role/permission tables.
- API Keys for key types and rotation.
- Custom Domains for domain verification used by SSO enforcement.
User roles & permissions
Every org role, project role, permission switch, and entity access level in Intempt, and how they combine into preset and custom roles.
Quick Start Guide (0 to First Value)
Sign up, create your organization, and complete the core setup steps that get real customer data flowing through Intempt.