The sign-in portal

Your domain users never see the control panel. They see the sign-in portal, a site on the domain of your identity provider, where they sign in, manage their credentials, and reach webmail.

This page describes the portal from your side: what to support your users with, and what you've given them control of.

What a user can do after signing in

The portal's home page collects the self-service actions:

Action	What it does
Open Webmail	Opens webmail.
Setup Mail Application	A page of server settings to copy, downloads for automatic configuration, and advice about authentication. See Mail clients & webmail.
Change Password	Set Password if the user currently has no password.
Go Passwordless	Removes the password; the user then signs in with passkeys only. Appears once the user has a passkey. See Remove the password.
Setup Two-Factor Authentication	Enrolls an authenticator app by scanning a QR code. The portal then shows ten backup codes once.
Backup Codes	Appears after two-factor authentication is set up. Shows how many codes remain; the user can show, copy, or download them, or make a new set.
Create / Manage Passkeys	Passwordless sign-in with a fingerprint, a face, or the device PIN. The user can also put a passkey on a second device through a link valid for ten minutes, and registers a certified security key here too.
Create / Manage App Passwords	A password for one application, for a mail client that can't sign in through a browser. The value is shown once, when it's created.
Your Devices	Add a phone or computer that can approve a sign-in, alert the user to sign-ins, or both.
Revoke Trusted Computers	Appears after two-factor authentication is set up. Forgets every browser remembered through "Trust this computer for 30 days"; the next sign-in on each asks for the code again.
Active Sessions and Connected Apps	The same lists you see on the user's panel page, from the user's side. They sign out a session and revoke an application's access.
Profile & Preferences	Name, language, time zone, and contact details.

Two-factor authentication can be mandatory

If your authentication policy requires two-factor authentication, the portal doesn't let the user continue until the setup is complete.

A security-sensitive step has a guard

Before adding a passkey, the user confirms their identity with their password or an existing passkey, so nobody can add a credential from a signed-in, unattended browser.

Before removing their password, or setting one when they have none, the user confirms with a passkey. A password isn't enough.

If the user deletes the passkey they're currently using, the session ends.

Backup codes

A backup code signs the user in once, in place of the code from the authenticator app, for when they lose the phone with the app.

• The portal makes ten codes when two-factor authentication is set up and shows them once, with Copy All and Download.
• At the two-factor prompt, the user selects Use a backup code. Each code works once. The same prompt accepts a code when an application asks for a stronger sign-in.
• The user gets an email each time a backup code is used, with how many remain.
• On the Backup Codes page, the user can show the codes again or make a new set, after confirming their identity. A new set invalidates the old codes.
• A year after the user last looked at the codes, the portal asks after sign-in: "Do you still have your backup codes?" It also asks when the last code is used.

When a user can't sign in

A user who lost both the authenticator app and the backup codes can ask you for help from the Can't sign in? page. See When a domain user cannot sign in.

Remove the password

A user with a passkey can remove their password; a passkey is then the only way to sign in. A password that doesn't exist can't be guessed, stolen, or leaked, which matters most on the mail protocols, where a password needs no second factor.

The portal suggests the removal in two places:

• on the Passkeys page, while the user has a passkey
• on the home page, after a passkey has signed the user in once

If the user selects Not Now, both suggestions stop. Go Passwordless stays on the Security & Sign-In page.

Before the removal, the portal shows the user:

• the passkeys that remain. If only one remains and it can't leave its device, the portal tells the user to add a second one.
• every mail protocol that used the password since it was set, from the email access log, which keeps 180 days.
• the user's file shares. An FTP client that uses the password stops working; an app password keeps working.
• that nobody can send them a new password. They'd have to ask you for a welcome link.

The user then confirms their identity with a passkey. If a mail application still uses the password, they also confirm that it will stop working.

After the removal:

What	Result
Browser sign-in	A passkey only, with no second step.
A mail client with the password	Stops working. The user sets it up again with browser sign-in or an app password.
The user's sessions	Webmail, connected applications, and the user's other browsers are signed out.
The authenticator app and backup codes	Kept but unused. They work again if the user sets a password.
Email	The user gets an email saying the password was removed.
The auth log	Records Password removed. When the user removed it themselves, the entry isn't a warning.

The user can set a password again at any time with Set Password. On the user's Authentication tab you see "no password set".

When the user loses the passkeys

Use Reset credentials on the user's page. See Managing domain users. The welcome link lets the user set up a new passkey or a password.

The policy is a different thing

A Passwordless authentication policy stops password sign-in in the browser; the password still exists, and a mail client can use it if your policy allows. Once the user removes their password, no protocol accepts one.

Devices

On the Your Devices page, the user adds the browser of a phone or computer as a device, after confirming their identity.

A device can do two things, and the user picks one or both per device:

Function	What happens
Approve a sign-in	After the password, the sign-in page shows a two-digit number and waits. The user's devices show a notification; the user opens it, sees where the sign-in comes from, and selects the same number, and the sign-in continues. This is a second factor, like an authenticator app code. Approvals are off when a device is added; the user can turn them on then or later, per device, after confirming their identity.
Sign-in alerts	The device shows a notification when somebody signs in from another browser, and when somebody types the correct password without completing the sign-in. Alerts are on when a device is added; the user can turn them off and on per device.

Some facts about devices:

• A device never approves its own sign-in. To approve on a phone, the user signs in on a different computer or phone.
• A device that only shows sign-in alerts isn't a second factor. It gets no approval requests, and no backup codes are made for it. Use it for a computer that should see sign-ins but not approve them.
• One phone or computer can be a device of several domain users, e.g. info@ and the same person's personal address: the user signs in as each and adds the device again. Each domain user then has its own device with its own settings, and each notification shows the address it's for. One browser can be a device of at most ten domain users.
• If the user selects the wrong number or No, It Was Not Me, the portal refuses the sign-in, sends no requests to the devices for 30 minutes, records the attempt in the auth log, and emails the user. Since the attacker knew the password, the user should change it.
• The authenticator app and backup codes keep working alongside devices. When an approving device is the user's first second factor, the portal makes ten backup codes and shows them once.
• On an iPhone or iPad, the user first adds the portal to the Home Screen and opens it from there; Safari doesn't show notifications for a site that's only in a tab.
• Notifications go through the browser maker's notification service: Google, Apple, Mozilla, or Microsoft. The contents are encrypted, so the service can't read them, but it knows when the portal sends one. If you don't want this, turn off Notifications to Devices (Web Push) on the identity provider's Authentication tab.

An approval isn't phishing-resistant

A fake sign-in page can show the user the real number. That's why the approval screen shows the location and browser of the sign-in, and the user should check them before approving. A badge after the location marks a VPN, a Tor exit node, or a datacenter. A passkey is safer, because it works only on the real site.

The welcome flow

A new user, or one whose credentials you reset, enters through a welcome link. There is no open registration.

• The link is single-use and valid for 72 hours.
• It comes with an 8-digit PIN, which the user can type with their email address on the portal's claim page, for when a full link is hard to send.
• Issuing a new link invalidates the previous one.

The link starts a short setup session of about half an hour, in which the user:

1. sets a password, their own or a generated one the portal shows once, or registers a passkey instead and has no password;
2. enrolls in two-factor authentication, if the portal offers or requires it;
3. finishes, and signs in normally with what they chose.

The flow doesn't let the user finish in a state they can't sign in from, e.g. with a password alone when your policy is passwordless.

After a lockdown, the portal tells the user why

If the link comes from a lockdown, the page also lists the security measures you applied.

Sign-in

The sign-in page takes a username and password, or a passkey; your policy decides what happens next. A password sign-in can ask for a two-factor code or an approval on a device. Under Passwordless (using any Passkeys), password sign-in isn't available. Under Passwordless (certified security key only), the page also refuses every passkey that isn't a certified security key.

A user under a passwordless policy can still type a password into the form. The page then says the account doesn't sign in with a password and points to the passkey or security key. It says this for a correct and for an incorrect password alike, so it doesn't tell a stranger that a password is correct; the auth log records which it was.

When the user arrives from an application, webmail included, the page names the application they're about to enter, and keeps naming it through a sign-out, a second factor, or enrolling one. The first access to an application shows a consent step. See Scopes and consent.

Put your brand on the portal

The portal starts with a neutral style. Brand it under the identity provider's Branding and Style tabs:

Tab	What you set
Branding	A Brand Name, a square Brand Image that is also the favicon, and an optional wide Wordmark that replaces both in the header. Each has an optional dark-mode version. Also a Footer in rich text.
Style	The portal's theme: colors, fonts, and corner radius. A live preview shows the result before you save. Use a preset, or pick an accent color and let the rest follow.

These settings apply to everything the portal serves, sign-in, consent, welcome, and self-service pages, for every user of that identity provider.