Skip to content
AtlasDocs
Sign inGet started
Updated Aug 04, 2026

Account Policy

Per-app settings that drive account-mode behaviour. Every setting lives on the dashboard and applies to that application only - no global toggle.

Where it lives

Dashboard → Settings → Sign-in rules on each application. Each app has its own policy; a change doesn't propagate across apps.

The verification policy is the one new-app sellers get wrong most often. The rest are flags.

Verification policy

When to send an 8-digit email code before completing sign-in. When the policy triggers, sign-in returns NeedsVerification with the masked email, IP, and country populated (see Account Namespace).

Verification policy options
never
No verification code is ever sent. Default off. Use for low-risk distributions or paired with strong other signals.
first_login
One code the very first time an account signs in. Trusted afterwards - sign-in is frictionless.
every_n_logins
Re-verify every N successful sign-ins per device. N is 1 to 100; the dashboard recommends 3.
once_per_day
Re-verify at most once per H hours per device. H is 1 to 8760 (one year); the default is 24, one verify a day per device.
new_hwid
Verify only when signing in from a HWID not seen before for this account.
new_hwid_or_ip
Verify on a new HWID, or when a trusted device signs in from a new IP.
always
Re-verify every sign-in. Maximum friction; matches MFA semantics.

Other flags

  • Require email at registration - refuse account creation without an email. Default off.
  • Require key at registration - refuse account creation without a license key redeemed in the same request. Default off.
  • Renewal warning email - send accounts an email N days before their access expires. 0 = disabled, up to 365.

How a sign-in flows through it

  1. 1

    Client calls Account::Login(user, password)

    Returns a LoginResult. Status is one of seven values - see Authentication Paths.

  2. 2

    Server evaluates the policy for this app

    If the policy triggers verification, the SDK holds the challenge and status is NeedsVerification.

  3. 3

    Client surfaces the masked email + IP + country

    From r.masked_email, r.sign_in_ip, r.sign_in_country. Built so you can render "we sent a code to m•••@example.com from Riyadh."

  4. 4

    User enters the 8-digit code

    Client calls Account::SubmitVerification(code). On success, the session opens normally.

Picking a policy

There's no single right answer. A few heuristics, in order of increasing friction:

  • Free public utility: new_hwid_or_ip - keeps the friction invisible for legitimate users, kicks in when someone hands their account around.
  • Paid SaaS: new_hwid - anchors the account to one machine, but tolerates IP churn.
  • High-value / regulated: always - full MFA-equivalent. Pair with a short session window.
Was this page useful?