Authentication Methods

Authentication Methods Overview

An authentication method is a route by which somebody proves who they are. The platform supports several at once, and an identity records which route was used.

Where to find it

Architect Panel → Security:

• Authentication Methods — the console — which routes are enabled
• Two-Factor Authentication — the second factor, independent of the route
• Passkeys — device-bound credentials

Architect Panel → Integration & Connections:

• SAML Identity Providers — enterprise single sign-on
• OpenID Connect Provider — OIDC
• Azure AD Tenants — Microsoft directory
• SCIM User Provisioning — automatic account lifecycle

Identity has three parts

Everywhere the platform records who did something — audit entries, grants, clearances, break-glass events — it stores three values rather than a username:

• Method — how they signed in.
• Unique identifier — who they are within that method.
• Domain — which population they belong to.

Why three

Because a bare username cannot answer the questions that matter after the fact.

The same person may exist as a local account and as a single sign-on identity. An API client acting on somebody's behalf is not the same event as that person signing in and doing it themselves. Two different populations — staff and customers — may legitimately contain the same identifier.

Recording the method means the audit trail distinguishes all of these, and it does so permanently. It also survives renaming: an identity built on a stable identifier still resolves after somebody changes their name or e-mail address.

Methods coexist

You are not choosing one. A typical installation runs single sign-on for staff, local accounts for a handful of service or break-glass identities, and something else again for external users.

What matters is knowing which populations use which route, because that determines where an account is disabled when somebody leaves — the commonest gap in an otherwise sound setup.

The second factor is separate

Two-factor authentication and passkeys sit alongside the method rather than replacing it. A local password and a single sign-on identity can both carry a second factor, configured independently.

Know your leaver path per method

For each method in use, be able to say what happens when somebody leaves. Directory-backed methods usually handle it automatically; local accounts do not, and they are exactly the accounts most likely to be privileged.

Write this down. It is the question an auditor asks and the one that most often has no confident answer.

Keep one local route working

If every administrator signs in through an external provider and that provider is unavailable, nobody can get in to fix anything. One local administrative account, strongly protected and rarely used, is worth having.

Worked example

An organisation runs single sign-on for its 400 staff, with two local administrator accounts held for emergencies and protected by passkeys. The audit trail distinguishes staff activity from the nightly integration and from the two local accounts, so a question about who changed a record has an unambiguous answer.

Recommendations

• Document which population uses which method.
• Define the leaver path for every method, especially local accounts.
• Keep one protected local administrator as a fallback.
• Read the method, not just the name, when investigating.

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.

External Providers

External providers let people sign in with an identity they already have, so the platform never holds their password.

Where to find it

Architect Panel → Integration & Connections:

• SAML Identity Providers — enterprise single sign-on
• OpenID Connect Provider — OIDC
• Azure AD Tenants — Microsoft directory
• SCIM User Provisioning — automatic joiners, movers and leavers
• OAuth Tokens — issued tokens

Architect Panel → Security:

• Certificates — signing certificates
• Authentication Methods — enabling the route

What you gain

• No password held here, so no password to leak from here.
• Your directory's own policy — complexity, rotation, conditional access — applies without being reimplemented.
• Disabling somebody centrally disables them here.
• One fewer credential for people to manage, which measurably reduces reuse.

Provisioning is the other half

Single sign-on controls authentication. Provisioning controls account lifecycle — creating accounts, updating them, and deactivating them when somebody leaves.

Without provisioning, a leaver disabled in your directory can no longer sign in, but their account, its group memberships and its record grants all remain. That is usually acceptable, but it should be a decision rather than a surprise — and it means your access reviews still have real work to do.

Certificates expire

SAML depends on signing certificates with expiry dates, and an expired certificate stops all sign-in at once for everybody using that provider.

It is a known date, so put it in a diary well ahead. This is the most common single-sign-on outage there is, and it is entirely preventable.

Test what happens when the provider is down

Before you switch over, establish how you get in when the provider is unavailable. A directory outage that also locks every administrator out of the platform turns somebody else's incident into yours.

Keep at least one local administrative account, protected by a passkey or a second factor, and confirm it works — not by assuming, but by signing in with it.

Map groups deliberately

Where directory groups drive platform access, the mapping is a security boundary. Somebody added to a directory group by a colleague who does not know what it means here can be granted access nobody reviewed.

Keep the mapping small and explicit, and review it when either side changes.

Watch the first fortnight

Attribute mismatches, people with two identities, and users whose directory record is missing something the platform expects all surface early. Check the error log and the sign-in activity daily for the first couple of weeks.

Worked example

An organisation moves staff to Microsoft single sign-on with SCIM provisioning. Leavers are deactivated automatically the day they leave. Two local administrator accounts with passkeys are retained and tested, and the SAML certificate expiry is diarised 60 days ahead. When the directory has a two-hour outage six months later, administrators still get in.

Recommendations

• Add provisioning, not just single sign-on.
• Diary certificate expiry well in advance.
• Keep and test a local administrative fallback.
• Review the group mapping whenever either side changes.