Native Auth & MFA

Native email/password authentication is FrontLine's built-in login method. It serves as the primary auth mode for tenants not using SSO, and as a break-glass fallback for SSO-enforced tenants.

When native auth is available

Native login is available in two scenarios:

1. SSO not enforced — the tenant has not enabled the Enforce SSO policy. All users can choose between SSO and native login.
2. Break-glass accounts — when SSO is enforced, designated admin accounts can still use native login if Allow native break-glass is enabled.

caution

Break-glass account activation is a high-severity audited event. Use break-glass accounts only for emergency access when the SSO provider is unavailable.

Password policy

All native accounts must meet these password requirements:

Requirement	Value
Minimum length	12 characters
Uppercase letter	At least one
Lowercase letter	At least one
Digit	At least one
Symbol	At least one
Breached password check	Passwords are checked against the HaveIBeenPwned database at registration and password change

Passwords that appear in known data breaches are rejected.

Account lockout

Failed login attempts trigger progressive lockout:

Setting	Default	Description
Max failed attempts	10	Consecutive failures before the account is locked (tenant-configurable)
Lockout behaviour	Progressive backoff	Each subsequent failure increases the wait time before the next attempt is allowed
Auto-unlock	Yes	Accounts automatically unlock after the backoff period expires

Rate limiting is applied by both IP address and account to prevent brute-force attacks.

Multi-Factor Authentication (MFA)

MFA adds a second verification step after password entry. It is required by default for all native accounts.

Supported MFA methods

Method	Description
TOTP (authenticator app)	Time-based one-time password using any TOTP-compatible app (Google Authenticator, Authy, 1Password, etc.)
Email OTP	One-time code sent to the user's registered email address

MFA enrollment

1. After first login with a native account, the user is prompted to set up MFA.
2. For TOTP: Scan the QR code with an authenticator app, then enter the verification code.
3. For email OTP: Confirm the registered email address, then enter the code sent to it.

MFA enrollment and de-enrollment events are audited.

MFA for SSO sessions

For SSO sessions, MFA status depends on the identity provider:

• If the IdP assertion includes a satisfied MFA context class, FrontLine sets mfa = true on the session.
• If the IdP does not provide MFA context, FrontLine can perform its own MFA step-up after SSO handoff (configurable per tenant).

Sensitive actions requiring MFA

Certain high-privilege actions require an MFA-verified session regardless of login method:

• Salary approvals
• Role assignment changes
• Data erasure execution
• IdP configuration changes

If a user's session does not have MFA verified, they are prompted to complete an MFA challenge before proceeding.

Device trust ("Remember this device")

After a successful MFA challenge, users can opt to trust their current device for a configurable period. This skips the MFA prompt on subsequent logins from the same browser.

Configuration

Setting	Default	Description
Device trust enabled	On	Whether the "Remember this device" checkbox appears after MFA
Trust TTL	30 days	How long the device remains trusted (1–90 days)

How device trust works

1. After completing MFA, the user checks "Remember this device for N days".
2. FrontLine issues a secure, signed cookie tied to the user, tenant, and browser fingerprint.
3. On the next login from the same browser, the cookie is validated and MFA is skipped.
4. The session is issued with full MFA status (mfa = true).

When device trust is revoked

The trusted device cookie is automatically invalidated when any of the following occur:

• The user changes their password
• The user de-enrolls from MFA
• The user signs out via "Sign out of all devices"
• A tenant admin performs a force logout for the user
• The tenant disables the Device trust setting
• The user switches to a different browser (fingerprint mismatch)

tip

If a user reports being prompted for MFA unexpectedly, check whether any of the above revocation events occurred. Browser updates can also change the fingerprint and trigger a new MFA challenge.

Session management

Token lifecycle

Token	Lifetime	Description
Access token	15 minutes	Short-lived JWT carrying all auth context
Refresh token	7 days (rolling)	Rotated on each use; used to issue new access tokens

Force logout

Tenant admins can force-logout a user from Settings → Users → [User] → Force Logout. This:

• Invalidates all active refresh tokens for that user
• Revokes all trusted device cookies
• Emits an audit event

Session theft detection

FrontLine uses refresh token rotation. If a refresh token is reused after it has already been rotated (indicating possible token theft), the entire session chain is revoked immediately.

Configuring authentication policies

1. Navigate to Settings → Security & SSO.
2. Under Authentication Policy, configure:
   • Enforce SSO — toggle on to require SSO for all non-break-glass users
   • Allow native break-glass — toggle on to designate emergency admin accounts
   • MFA policy — set to "Native accounts only" or "All sessions"
   • Device trust — enable/disable and set TTL
3. Save changes.

danger

Enabling Enforce SSO without a working SSO configuration will lock out all non-break-glass users. Always test SSO thoroughly before enabling enforcement.