Choosing a Mode

The decision usually takes a minute once the question is framed properly.

Where to find it

Architect Panel → Configuration:

• Site Settings — Login Page Mode, Use E-mail Address as Username, Force External Users to Login

Architect Panel → Security:

• Passkeys — which changes the page more than either mode

The decision path

1. Can anybody register? If yes, and an account implies nothing about the person, use e-mail check.
2. Does an account imply something? Employment, membership, using a particular service — use standard.
3. Unsure? Use standard. It costs a small amount of convenience and discloses nothing, which is the safer way to be wrong.

Switching afterwards

Either direction is a settings change with no data implications, so it is not a decision you are locked into. What changes is what users see, so tell them — a sign-in page that behaves differently one morning generates support calls from people who assume something is broken.

E-mail as username

A related setting, and it interacts. Where the e-mail address is the username, the login page is asking for something the person certainly knows, which is part of why e-mail check works well.

Where usernames are separate, the disclosure question changes shape — a username is less guessable than an e-mail address, so probing is harder either way.

External users

A separate setting, Force External Users to Login, redirects visitors arriving from IP addresses outside your whitelisted ranges to the sign-in page. It is a network control — "people outside our offices must sign in" — rather than a general rule about external users, and it depends on your IP ranges being correct and current.

Passkeys change the page more

If you are enabling passkeys, that alters the sign-in experience considerably more than the choice between these two modes. Sequence the changes rather than doing both at once, so users have one thing to absorb and you can tell which change caused a support call.

Look at the page as a new user

Whichever mode you choose, open the sign-in page in a private window and complete the journey as somebody with no account. It is the quickest way to find that the registration route is missing, the reset link is hard to see, or an error message is unhelpful.

Do the same as somebody who has forgotten their password, which is the other common state.

Do not customise away the protection

If you are in standard mode for disclosure reasons, make sure nothing else on the page undoes it — a helpful error saying "no account found with that address" reintroduces exactly what the mode was chosen to prevent.

Worked example

An organisation reviews its sign-in page before enabling passkeys. It is in the default e-mail check mode, which suits its public service. The reset form is checked at the same time and found to confirm whether an address is registered — consistent with the mode, so no change is needed, but now a deliberate position rather than an accident.

Recommendations

• Default to standard when unsure — the safer way to be wrong.
• Tell users before switching.
• Sequence it separately from a passkey rollout.
• Walk the page as a new user and as a forgetful one.