Authentication policy

A domain user can hold four kinds of credential: a main password, app passwords, a passkey, and an authenticator app.

The authentication policy decides which of them you accept. You never hold the credentials themselves, only the rules they must satisfy.

It's two settings, one per area a user signs in from, each set on the domain as a default and on each user as an override. Policy tiering explains which wins.

The two settings

Traditional password authentication covers every service that asks for a plain username and password and can't ask for more: IMAP, POP3, SMTP submission, FTP, SFTP, CardDAV, and CalDAV.

Setting	Effect
Allow password & app passwords	The main password works on these services, and so does an app password.
Disallow password, allow app passwords	The main password stops working here. The user creates an app password for each app.

Modern (browser-based) authentication covers sign-in through a browser: webmail, the sign-in portal, and every application that uses the identity provider.

Setting	Effect
Allow password	A password alone signs the user in.
Allow password with 2FA	After the password, the user gives a second factor.
Passwordless (using any Passkeys)	A password doesn't work for a browser sign-in.
Passwordless (certified security key only)	A password doesn't work for a browser sign-in, and only a certified security key does. A passkey on a phone or in a password manager doesn't.

Two things this setting doesn't change

• A passkey is always accepted, whatever you set. The one exception is Passwordless (certified security key only), which accepts only a certified security key.
• The portal never skips an authenticator app the user enrolled. Such a user gives the code at every password sign-in, even where the policy doesn't ask for a second factor.

Certified security keys

A certified security key is a hardware key, e.g. USB or NFC. At registration it sends a signed statement of its model, which the panel checks against the FIDO metadata; that proves the private key stays in dedicated hardware.

A passkey on a phone, on a laptop, or in a password manager such as iCloud Keychain or Google Password Manager is never certified: it synchronizes between devices and gives no proof of its hardware.

Under Passwordless (certified security key only):

• The sign-in portal refuses every passkey that isn't a certified security key.
• It also refuses to register one. The user registers the key with Register a certified security key in the More ways to add a passkey menu.
• The panel won't let you select this value for a user who has no certified security key yet.

A domain default with this value can lock users out

The domain default isn't checked. A user without a certified security key who gets the domain value can't sign in through the browser, so make sure every user has one before you set it on the domain.

"Trust this computer for 30 days"

This checkbox on the two-factor prompt is the one shortcut there is: it remembers the browser, so later password sign-ins on that computer don't ask for the code.

• The trust expires 30 days after the user last gave the code.
• It's revoked automatically when the password changes or the user sets up the authenticator app again.
• The user can revoke all of them with Revoke Trusted Computers on the portal's home page.

An application still gets a real challenge

A session that used the shortcut is reported to an identity-provider application as single-factor, so an application that asks for a second factor still gets one.

An operator can turn the shortcut off for one user through the trusted-computer policy (host:user:edit --trusted-computer=false on the command line). Every trusted browser stops being trusted immediately.

Approval on another device

A user can add their phones and computers as devices. A device with approvals on then approves a password sign-in as a second factor; a device that only shows sign-in alerts isn't one. An approval is an alternative to the code from an authenticator app:

• It satisfies Allow password with 2FA; the user doesn't also need an authenticator app.
• It doesn't change a passwordless policy. A passkey sign-in never asks for a second factor.
• It isn't phishing-resistant, so an application that asks for phr doesn't accept it. See Authentication strength.

An operator can turn approvals off for one user or for all users of a mail service through the device-approval policy (host:user:edit --device-approval=false or service:mail:edit --device-approval=false). The devices then send only sign-in alerts. To stop all notifications to devices, turn off Notifications to Devices (Web Push) on the identity provider's Authentication tab.

The paths a policy leaves open

Under the default policy, the main password works everywhere and no second factor is needed. A user who set up every kind of credential has these ways in:

At the top, the diagram splits into the two areas the settings control:

• The left branch is traditional authentication, where the only question is which secret you accept.
• The right branch is the browser sign-in, where you can add a second step and where passkeys work. A passkey is the one credential that needs no password.

Make both settings stricter, with app passwords only on the traditional branch and passkeys only in the browser, and every password path closes:

The main password now opens nothing: a mail client holds an app password and the browser takes a passkey. That's the strictest position the policy can express, and once the user has set up their clients, it costs them nothing.

Where the panel draws this for you

The panel draws the same diagram from the real settings, so you don't have to work out a policy's result yourself:

Where	Drawn from
A domain user's Authentication tab, under Domain Accounts	That user's effective policy and real credentials. A path is also grey when the credential doesn't exist, with a message such as "no password set" or "none registered".
The domain's Mail service page, and the form where you edit its policy	The default policy. It updates live as you change the settings, so you can see before saving whether you'd lock out a whole domain.

Both have a protocol chooser above the diagram, because the two branches aren't available everywhere:

Scenario	Traditional	Browser-based
Webmail	No	Yes
Email app: IMAP, POP3, submission, CardDAV, CalDAV	Yes	Yes, where the client supports it
Shares: FTP, SFTP	Yes	No
HTTP, for restricted website content	Only with HTTP basic authentication	Yes
Connected app, with OAuth2 and OpenID Connect	No	Yes

"Passwordless" alone doesn't close every way in

A file share never uses the browser branch, so the traditional setting alone decides its access. That's why "disallow the main password" is safe to apply widely, and why passwordless on its own isn't enough.

Choose a position

We recommend a position stricter than the default: disallow the main password for traditional authentication.

Why

The mail and file protocols can't ask for a second factor, so the main password on those protocols is fully exposed to brute force, credential stuffing, and phishing. And it's the same secret that opens the panel and the sign-in portal.

An app password limits that exposure. Each one:

• is a long random string the portal generates
• lives in exactly one app
• can be revoked on its own
• can't sign in to a browser or change an account setting

If an app password is stolen, the user loses one app, not their identity.

On the browser side, prefer passkeys: a passkey is bound to the site, so it can't be phished or replayed. Allow password with 2FA is the middle step for a user who isn't ready to drop passwords. Passwordless (certified security key only) is the strictest; use it only if everyone with access owns a security key.

tip

The panel gives this reasoning in full behind the Why restrict password authentication? link on each authentication-policy form.

What the policy doesn't cover

The authentication policy decides how a user proves their identity, not what they can reach afterwards.

Need	Use
Turn off a whole protocol, or limit connections to a list of networks you accept	The separate Email Access Policy. See Account types.
A user an attacker already compromised	Not a policy edit. Use Lock Down Account. See Manage domain users.