Require Two-Factor Authentication and Set Sign-In Expiry

Last updated November 10, 2026

A team Owner or Admin can turn on two sign-in rules for the team in Settings > Organization > Security, in the Details section:

  • Require two-factor authentication for password sign-in: every account on your verified email domain that has a password must use an authenticator app.
  • Sign-in expires after: each member’s sign-in stops working 30 or 90 days after it was made.

Both are off by default. Each change is recorded in the audit log.

Require two-factor authentication for password sign-in

Prerequisites

  • The Owner or Admin role.
  • A verified email domain. Until the domain is verified, the setting has no effect and the row says so. See Set Up SSO for Compound for domain verification.

Who it applies to

  • Every account with an email address on your verified domain that has a password, including accounts that are not members of your team.
  • The rule applies to a sign-in to such an account with its password, with Google or with Microsoft. Each of them asks for a code.
  • A subdomain is a different domain. Verifying acme.com does not cover eu.acme.com.
  • Accounts that have no password, such as an account that only signs in with Google or Microsoft, are not affected.
  • Sign-ins through your team’s own SAML or OIDC identity provider are not affected, even when the account still has a password. Set the two-factor policy for those sign-ins in your identity provider.

What your users see

An admin turns the setting on

In Settings > Organization > Security, turn on Require two-factor authentication for password sign-in.

A user signs in to an account that has a password

Compound opens a page that asks the user to set up an authenticator app (Google Authenticator, Authy, 1Password and similar apps work).

The user signs in again

After setup, the user signs in again and enters a 6-digit code from the app. Every later sign-in to the account asks for a code, except a sign-in through your team’s own identity provider.

Note

A session that was signed in before you turned the setting on keeps working until that user signs out. The rule applies from their next sign-in.

The rule covers the web app, the Excel add-in, the Compound CLI and connected MCP clients. The authenticator app is set up in the web app.

Sign-in expires after

Choose Never (the default), 30 days or 90 days.

  • The limit applies to every member of your team, for every sign-in method, including single sign-on.
  • The time counts from when the member signed in on the web, not from their last activity. A member who uses Compound every day still signs in again when the limit is reached.
  • A CLI session and a connected MCP client count from the web sign-in that authorized them, so they end at the same time.
  • Organization API keys are not sign-ins and do not expire under this setting.

What your users see

  • Web app: a page titled “Your session has expired” with a Sign in again button.
  • Excel add-in: the same message. The user signs out of the add-in and signs in again.
  • Compound CLI: the next command fails and asks the user to run compound login.
  • MCP clients: the client asks the user to connect to Compound again.
Important

When you set or lower the limit, sign-ins that are already older than it end within about 30 seconds. Members who are working at that moment are asked to sign in again.

Dedicated deployments

On a dedicated deployment that signs users in through your own identity provider, these two rows do not appear. Set two-factor requirements and session lifetimes in your identity provider.

What to read next