Allowlist & blocklist

Sometimes attack protection isn't about how someone signs in but whether they should at all. The allowlist and blocklist let you decide precisely who is admitted, by identifier and by network address.

Identifier lists

Under Security → Restrictions you maintain two lists whose entries can be an email address, an @domain or an E.164 phone number:

• Blocklist — anyone matching is refused. Use it to keep out a specific abuser or a disposable-email domain.

• Allowlist — the set of identifiers permitted to sign up.

Allow-list-only sign-up

The allowlist only takes effect when you turn on allow-list-only sign-up. With it on, only identifiers on the allowlist may create an account — everyone else is turned away. This is the switch that makes Atlas a private, invite-style deployment:

• A company tool that should only admit @acme.com addresses → allowlist @acme.com, enable allow-list-only.

• A private beta → allowlist the specific testers.

With the toggle off, the allowlist is inert and the blocklist still applies.

IP allow/deny rules

Separately, Atlas supports IP allow/deny rules — individual IPs or CIDR ranges, evaluated in priority order. Use them to lock a sensitive instance (for example an internal admin app) to your office or VPN ranges, or to deny a range that's generating abuse.

Set it up

1. Open Security → Restrictions.

2. Add entries to the allow or block list (email, @domain or E.164 phone).

3. To make the allowlist authoritative, enable allow-list-only sign-up.

4. Add IP rules (allow or deny, with a priority) if you need network-level control.

5. Save. Editing the lists requires owner or admin.

Interplay with the rest

Restrictions run before a user is ever created, so they compose with attack protection (which governs how hard it is to attempt) and with enterprise SSO (which governs how a domain's users must sign in).

Next

Control how long sessions live and how to end them → Session security.