Login Page Mode

The Two Login Modes

Login Page Mode chooses between two sign-in behaviours. It ships as e-mail check.

Where to find it

Architect Panel → Configuration:

• Site Settings — Login Page Mode

Architect Panel → Security:

• Authentication Methods — the sign-in routes this applies to
• Blocked User Accounts — where repeated failures surface

Standard

E-mail and password on one page, submitted together. The form responds identically whether or not the address is registered — a wrong password and an unknown address produce the same result.

So an attacker trying addresses learns nothing.

E-mail check

Asks for the e-mail first, then adapts: a password field for a known address, a registration route for an unknown one.

Better for the user, because the page responds to who they are. And it necessarily discloses whether an address is registered, because that is what it is reacting to.

The trade is real in both directions

This is not a case of one being secure and the other convenient. Both are defensible and the right answer depends on what an account with you implies.

The question to ask: does knowing somebody has an account here tell you something about them?

Where the disclosure does not matter

A retailer, a general service, anywhere anybody may register. Knowing an address has an account reveals nothing — the person could have created one in a minute anyway.

Here the smoother journey is a straightforward gain, and e-mail check is the better choice.

Where it matters a great deal

Anywhere membership is itself sensitive: a support service, a health context, a service for people in difficulty, a members-only professional body, an internal system where account existence maps to employment.

Being able to test whether somebody has an account with a domestic abuse service, or a particular clinic, is a disclosure that could matter enormously to that person. In those cases standard mode is the right answer and the extra friction is worth it.

It is not the only disclosure

Worth checking the rest of the journey, because the login page is rarely the only place. Password reset forms, registration forms and any "check if you have an account" feature can all disclose the same thing — and fixing one while leaving the others is not much of a fix.

Whatever posture you choose, apply it consistently.

Banning applies either way

Account and address banning work in both modes, so neither leaves you exposed to unlimited guessing. The disclosure question is separate from brute-force protection.

Worked example

A public marketplace uses e-mail check, because anybody may register and the smoother journey measurably improves sign-in completion. The same organisation's staff-facing system uses standard mode, because there an account means employment and that is not something to let anybody test.

Recommendations

• Ask what an account implies about the person.
• Use standard mode where membership is sensitive.
• Check reset and registration for the same disclosure.
• Decide deliberately rather than accepting the default.

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.