Security

Two-Factor Authentication (2FA / MFA)

Asenion supports time-based one-time password (TOTP) two-factor authentication for all user accounts, compatible with any authenticator app (e.g. Google Authenticator, Authy, 1Password).

User-level 2FA

Any user can enable 2FA on their account from Personal Settings → Security → Two-Factor Authentication. The setup flow:

  1. Asenion generates a TOTP secret and displays a QR code.
  2. The user scans the QR code with their authenticator app.
  3. The user enters the one-time code to verify and activate 2FA.

Once enabled, the user must enter a TOTP code at each login.

Organization-level 2FA enforcement

Org Admins can require all members of their organization to have 2FA enabled. When enforcement is active:

  • Users who have not yet configured 2FA are blocked from accessing the platform after login.
  • A setup modal appears automatically, guiding them through the 2FA configuration before they can proceed.
  • Enforcement applies on every login session — the check is always fresh to account for admins enabling enforcement mid-session.

To enable org-wide 2FA enforcement, go to Organization Settings → Security → Enforce Two-Factor Authentication.

Single Sign-On (SSO)

Asenion supports SSO with Okta (including Auth0 tenants) and Microsoft Entra ID, alongside Google OAuth. SSO is configured by Org Admins from Settings → Connections → Single Sign-On (SSO) — no support ticket is required.

Email domain discovery

SSO providers are surfaced at sign-in by email domain. Each organization registers one or more domains (for example acme.com, acme.co.uk). When someone enters an email address on the sign-in page:

  1. Asenion looks up the organization that owns the email domain.
  2. If that organization has a provider configured, the user is offered the SSO option instead of the password form.
  3. If no domain matches, the standard password flow is shown.

An SSO provider with no registered email domains is not reachable from the sign-in page, so domains must be saved before the provider becomes usable. The settings page warns when a provider is configured without them.

Okta configuration

Field Description
Okta Domain Your Okta organization domain, e.g. dev-12345.okta.com. Auth0 tenants (*.auth0.com) are also supported.
Client ID The Client ID of your Okta OIDC application.
Issuer URL The authorization server issuer, e.g. https://dev-12345.okta.com/oauth2/default. Auto-derived from the domain, and editable if you use a custom authorization server.

Create an OIDC application in Okta, add Asenion’s sign-in and callback URLs as allowed redirect URIs, and assign the users or groups who should have access. Then paste the domain and Client ID into Asenion and save.

Microsoft Entra ID configuration

Provide your Azure Tenant ID. Users in that tenant can then sign in with their Microsoft work account.

How an SSO login is processed

  1. The identity provider returns a signed ID token to the browser.
  2. Asenion verifies the token server-side against the provider’s published signing keys, checking signature, issuer, audience, and expiry.
  3. The organization is resolved from the token’s issuer domain. A token from an unregistered domain is rejected.
  4. The email address on the token is validated and normalized.
  5. If the user does not exist yet, an account is provisioned automatically (just-in-time) as a Member of the matched organization, with the email marked as verified.
  6. If the user already exists but belongs to a different organization, the login is refused.
  7. If the account has 2FA enabled, a TOTP code or recovery code is still required before the session is issued.

Invited users can also accept an organization invitation through SSO: the invitation email must match the identity provider account, and the invitation must still be pending and unexpired.

SSO and 2FA together

SSO does not bypass Asenion 2FA. Where org-wide 2FA enforcement is active, SSO users are prompted for their TOTP code after the identity provider check succeeds. Sign-in attempts are rate limited regardless of the provider used.

Role-Based Access Control (RBAC) and Permissions

Access to every action in Asenion is governed by named capabilities assigned to roles, with per-user overrides on top. The two-layer structure:

  1. Platform roles — what a user can do across the organization (Org Admin, Compliance Manager, etc.)
  2. Project roles — what a user can do within a specific AI system (Owner, Reviewer, Approver, etc.)

Each role carries a default set of capabilities. Org Admins can grant or revoke individual capabilities per member without changing their role. The full capability list (27 built-in capabilities across platform, org, project, assessment, report, and test scopes) is documented in Permissions.

System Admins can view and edit the role-capability matrix and reset roles to platform defaults.

Data access

  • Users only see AI systems they own or have been explicitly added to.
  • Org Admins can access any record within their organization.
  • No cross-organization data access is possible for non-System Admin accounts.
  • A user’s capabilities are refreshed automatically every 2 minutes — revoked access takes effect without requiring a logout.