Expanded security policy controls

Sign-up and sign-in need more than a single on/off switch. Bot traffic, leaked passwords, repeated guesses, unfamiliar devices, and bursty clients each need their own knobs, and some apps should not accept every email that hits the registration form. Authentication policies now expose finer-grained controls for those checks, plus a registration policy that can restrict who is allowed to sign up.

This is the longer note behind the August 18 changelog entry.

What the policies cover

Open Authentication > Policies. The policy strip includes Password, Registration, Countries, Rate limiting, Bot detection, Brute force, Breached passwords, and Device risk.

• Bot detection scores automated traffic and can stay silent, step up, or block
• Breached passwords checks known-bad secrets on sign-up and related password paths
• Brute force applies lockouts and progressive delay when enabled
• Device risk challenges unrecognized device fingerprints and can flag impossible travel
• Rate limiting applies fixed-window counters on sign-in, sign-up, and password change
• Registration restricts who may create an account (disposable and trash mail, domain allow/block lists, subaddresses), with a "Test an email" preview

Registration policy persists with the same environment restrictions store as Authentication > Restrictions (sign-up mode, allowlist/blocklist, subaddress and disposable blocks). The policy tab is the editor; Restrictions is the access-oriented view of the same rules.

These policies are environment-scoped. A strict prod registration list does not apply to dev unless you configure it there.

Set it up

In the Authdog console, select the project and environment, then open Authentication > Policies:

1. Walk each sub-tab you care about (bot detection, breached passwords, brute force, device risk, rate limiting).
2. Open Registration and set who may sign up. Use the email tester before saving.
3. Confirm Restrictions if you also manage Public / Restricted / Waitlist sign-up mode.
4. Exercise sign-up and sign-in on the hosted Account Portal with an allowed address and a blocked one.

Password policy (length, character classes, "Test a password") stays on the Password sub-tab. It is separate from registration eligibility.

Trust boundaries

A policy is a gate on the request. It does not replace MFA, Lidar correlation, or bot protection add-ons (reCAPTCHA / Turnstile). Bot-detection policy and a captcha add-on can both run; they answer different questions.

Registration allowlists are not proof of identity. They only decide whether that email may create an account. Breached-password and brute-force outcomes follow the policy you saved; a warn mode is not a hard block.

Do not treat a green readiness tile on the home dashboard as a full security review. Readiness reports whether password, MFA, and geo coverage exist; it does not tune these policies for you.

Try it

Tighten registration on a non-production environment, then attempt sign-up with an address the policy should reject. Policy location is Authentication > Policies. Broader controls are summarized in Security. The original release note is in the changelog.