Local Sign-In
Local sign-in is a username and password held by the platform. Even where single sign-on carries most users, a few local accounts usually remain.
Where to find it
Architect Panel → Security:
- Authentication Methods — whether local sign-in is enabled
- Blocked User Accounts — accounts banned after failed attempts
- Disabled User Accounts — accounts closed administratively
Architect Panel → Configuration:
- Site Settings — Login Page Mode
Two login page modes
Login Page Mode chooses between two behaviours, and the choice is a genuine trade-off:
- Standard — e-mail and password on one page. The form responds identically whether or not the address is registered, so an attacker learns nothing by trying addresses.
- E-mail check — asks for the e-mail first, then adapts: a password field for a known address, a registration form for an unknown one. Better for the user, and it discloses whether an address is registered.
Choosing
The disclosure is not always a problem. For a public service where anybody may register, knowing an address exists reveals little. For an internal system, or anywhere membership is itself sensitive — a support service, a health context — it can matter a great deal.
Default to standard mode unless the smoother registration journey is worth the disclosure. Make it a decision rather than an accident of configuration.
Local accounts need the most care
They are not covered by your directory's joiners and leavers process, so nothing removes them automatically. They are also disproportionately privileged, because local accounts tend to be the ones created for administrators and emergencies.
Keep a list of every local account, who owns it, and why it exists. Review it at least annually.
Shared accounts
A local account several people use destroys attribution — the audit trail records the account, and the account is not a person. It also trips account banning constantly, because a failure by any user counts against everybody.
Where a shared account exists because a task needs one, that is an argument for a service identity with its own credentials, not for people sharing a login.
Protect them properly
A second factor on every local account, and passkeys where the account is administrative. These are the accounts an attacker would most like, and there is no directory policy standing behind them.
Do not let them accumulate
Local accounts created for a project, a migration or a supplier tend to outlive their purpose silently. Give them an owner and an expected end date when you create them.
Worked example
A review of an organisation's twelve local accounts finds four still active for projects that ended: two supplier accounts, one migration account and one created for testing. All four are disabled with the reason recorded. The remaining eight are given named owners and a second factor.
Recommendations
- Default to standard login mode unless you have decided otherwise.
- Inventory local accounts and review annually.
- Never share a local account — use a service identity.
- Require a second factor on every local account.