Gating Sign-In

A type can be set to gate login — nobody signs in without holding that verification. It is the strongest thing in this area and the easiest to regret.

Where to find it

Architect Panel → Security:

• User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

• Blocked User Accounts — where lock-out reports will surface
• Authentication Methods — the sign-in routes affected

What it does

Sign-in requires the verification. Somebody without it cannot proceed past authentication, however valid their password and second factor.

When it is right

• A legal requirement that only verified people use the service — age restrictions being the common case.
• A closed professional service where affiliation is the basis of membership.
• An environment where an unverified account should not exist at all.

When it is not

Anywhere verification unlocks part of the service. If a student discount needs verification, gate the discount, not sign-in — otherwise every non-student is locked out of a service they are entitled to use.

This is the mistake to avoid: gating login is for "may this person be here at all", not "what may they do once here". The second question is answered by the awarded group.

Introduce it carefully

1. Enable the type without gating, and let people verify.
2. Watch how many hold it. Do not guess.
3. Tell users the requirement is coming, with a date.
4. Make sure the verification path works for everybody who should pass, including the awkward cases.
5. Only then turn on gating.

Gating first and hoping people verify locks out your user base on the day you enable it.

The unverified cannot always fix it themselves

Think through what somebody blocked at sign-in actually sees, and whether they can reach the verification from there. If verification requires being signed in, and sign-in requires verification, you have built a loop — and it is not obvious until a real user hits it.

Test this specifically, with an account that has never verified.

Keep an administrative route in

Make sure administrators are not gated by the same requirement, or that at least one account is exempt. Locking every administrator out behind a verification that is failing is a bad afternoon.

Plan for provider outages

If verification gates sign-in and the provider is unavailable, new and expiring users cannot get in. Know in advance whether you would lift the gate temporarily, and who can do that.

Worked example

An age-restricted service enables the age check without gating and reaches 89% within three weeks. It writes to the remainder, confirms the flow works for people without a passport via the supported route, and gates sign-in a month later. Administrators are exempt. Fewer than twenty users are affected on the day, all of whom can verify from the block screen.

Recommendations

• Gate access to features, not sign-in, unless membership itself depends on it.
• Enable and measure before gating.
• Test with a never-verified account for the loop.
• Exempt at least one administrator.