MFA trusted devices

MFA trusted devices let users skip repeated MFA prompts on a browser they trust. After eligible MFA verification or setup, users can choose to trust the browser on a separate Trust this device page at the end of sign-in or sign-up. Logto then stores a time-limited credential in a first-party cookie. On a later sign-in, a valid credential can fulfill the MFA verification step without user interaction.

A trusted device is not a new MFA factor and does not change when Logto requires MFA. It can fulfill only the MFA step in a sign-in flow. It cannot satisfy identity verification, recent verification, account recovery, MFA factor management, or another sensitive account operation.

How trusted devices work

When a sign-in reaches the MFA verification step, Logto:

1. Evaluates the existing MFA policy to decide whether MFA is required.
2. Checks whether trusted devices are enabled for the tenant and allowed by every organization the user belongs to.
3. Validates the browser cookie against an active server-side record for the identified user.
4. Completes MFA automatically when the credential is valid. Otherwise, Logto clears an invalid credential and continues with the conventional MFA flow.

Trust a device during sign-in or sign-up

The built-in sign-in experience presents Trust this device as a separate page at the end of an eligible sign-in or sign-up flow, after required profile completion and MFA steps. Trusting the browser is an explicit choice on this page, separate from MFA verification or setup.

The page appears only when trusted devices are enabled for the tenant, allowed by every organization the user belongs to, and the current interaction contains eligible MFA proof:

• Successful MFA verification with an enabled authenticator app OTP, passkey (WebAuthn), email verification code, or SMS verification code.
• Successful binding of an authenticator app or passkey during MFA setup, including setup during sign-up.

The page is not shown during password reset or when the interaction has no eligible MFA proof. Backup code verification or an existing trusted-device credential alone does not qualify, so the page is not shown on every sign-in or sign-up. A previous Skip choice can also suppress the page, as described below.

On the page, users can choose:

• Trust this device for N days: opt in for the configured trust duration. Logto creates the trusted-device record and cookie credential only after the complete interaction succeeds.
• Skip: continue without creating a trusted device. Skipping this page does not skip any required MFA verification or setup.

When a user selects Skip, Logto stores a separate opt-out cookie scoped to that tenant and user in the current browser. Its lifetime is the configured trust duration at the time of skipping. While the browser retains this cookie, later sign-ins do not show the page again. After it expires or is cleared, a later eligible flow can show the page again. The opt-out cookie does not grant device trust or fulfill MFA.

Trusting the device after selecting Skip:

If a user selects Skip and later wants to trust the current browser, the recommended approach is to delete the corresponding opt-out cookie for the Logto domain using the browser's cookie settings or developer tools. Its name starts with __Host-logto-device-trust-opt-out-.

Alternatively, clear all cookies for the Logto domain.

After either option, sign in again, complete eligible MFA verification or setup, and choose Trust this device for N days when the page appears.

Trusted-device creation and post-sign-in metadata updates are best effort, so a failure does not fail an otherwise successful authentication interaction.

Configure the trusted-device policy

Global policy

Navigate to Console > Multi-factor authentication and configure Trusted devices:

• Enable or disable trusted devices for the tenant. The policy is disabled by default.
• Set a whole-number trust duration from 1 through 365 days. The default is 30 days.

The duration is fixed when a trusted device is created. Using the device does not extend its expiration time, and changing the duration affects only devices created afterward.

Disabling the global policy prevents existing trusted devices from fulfilling MFA, but does not delete them. If you enable the policy again, records that have not expired or been removed can become usable again.

Organization-level restrictions

An organization can allow or disallow trusted devices for its members. This setting can only tighten the tenant-level policy:

• An organization cannot enable trusted devices when the global policy is disabled.
• If any organization the user belongs to disallows trusted devices, the user's trusted-device credential cannot fulfill MFA, regardless of whether that organization requires MFA.
• Organizations do not have a separate trust duration. The global duration applies.

Disallowing trusted devices for an organization suspends their use for affected members. It does not delete their records, and it does not prevent users or administrators from listing or removing them.

Browser and cookie limitations

Trusted-device reuse requires the browser context to preserve and return a persistent first-party cookie for the same Logto endpoint. It represents a browser profile, not a physical device.

WebViews, system browsers, custom tabs, privacy modes, cookie-disabled browsers, and other ephemeral contexts can use trusted devices only when their cookie store persists the credential. If the cookie is unavailable on a later sign-in, Logto continues with conventional MFA instead of failing authentication. Different browsers, browser profiles, Logto domains, tenants, and users do not share trusted-device credentials.

nota:

Logto does not use browser fingerprinting or pre-detect whether a client will persist the cookie. Native apps and custom sign-in flows should treat trusted-device creation as best effort and keep the conventional MFA flow available.

Manage trusted devices

Only active records whose expiresAt is in the future are listed. Device names are derived from the latest user agent, while country and city are approximate metadata from the latest available request context. Raw IP addresses are not displayed or returned by the public APIs.

Administrator management

In Console > User management, open a user to view and remove their trusted devices. Removing a trusted device affects future sign-ins only; it does not terminate the user's active sessions.

You can also use the Management API:

• GET /api/users/{userId}/trusted-devices lists all active trusted devices for a user.
• DELETE /api/users/{userId}/trusted-devices/{trustedDeviceId} removes one trusted device owned by the user.

The list response includes id, userAgent, country, city, createdAt, lastUsedAt, and expiresAt.

curl https://[tenant-id].logto.app/api/users/[user-id]/trusted-devices \
  -H "Authorization: Bearer [management-api-access-token]"

curl -X DELETE \
  https://[tenant-id].logto.app/api/users/[user-id]/trusted-devices/[trusted-device-id] \
  -H "Authorization: Bearer [management-api-access-token]"

Learn how to authenticate with the Management API.

Account Center self-service management

In Console > Sign-in & account > Account center, configure the Trusted devices field:

• Off: users cannot list or remove trusted devices.
• Read-only: users can list trusted devices but cannot remove them.
• Edit: users can list and remove trusted devices.

The prebuilt Account Center displays active trusted devices on its security page and marks the current browser when its complete cookie credential is valid. Removing the current browser clears its trusted-device cookie but keeps the current login session active. Removing another browser's record cannot clear that browser's cookie immediately; the stale cookie is rejected and cleared when it is next presented.

For a custom account center, request the urn:logto:scope:trusted_devices scope and use the Account API with a valid identity verification record:

• GET /api/my-account/trusted-devices lists the signed-in user's active trusted devices and adds isCurrent to each item.
• DELETE /api/my-account/trusted-devices/{trustedDeviceId} removes one trusted device owned by the signed-in user. Deletion is available only to first-party applications.

curl https://[tenant-id].logto.app/api/my-account/trusted-devices \
  -H "Authorization: Bearer [account-api-access-token]" \
  -H "logto-verification-id: [verification-record-id]"

curl -X DELETE \
  https://[tenant-id].logto.app/api/my-account/trusted-devices/[trusted-device-id] \
  -H "Authorization: Bearer [account-api-access-token]" \
  -H "logto-verification-id: [verification-record-id]"

See the Account API reference and security verification guide for the authorization and verification flow.

Security model

The trusted-device credential is an opaque bearer credential with two parts: a record ID and a cryptographically random 32-byte secret.

• In production, Logto stores it in a host-only cookie with the __Host- prefix, HttpOnly, Secure, SameSite=Lax, and Path=/ attributes. Application JavaScript cannot read it.
• The server stores only the SHA-256 hash of the secret and compares credentials with a timing-safe check.
• Every credential lookup is constrained to the tenant and user and requires expiresAt to be in the future.
• Expiration is fixed at creation. Opportunistic cleanup can delete expired rows later, but cleanup timing is never used as a security control.
• Explicit removal deletes the server-side record immediately. A copied or stale cookie cannot pass validation after the record is removed.

Credential secrets and hashes are never exposed through UI, public APIs, audit logs, or webhooks. The public device ID is not a physical-device identifier and is not sufficient to authenticate. Because the cookie is a bearer credential, copying the complete cookie can replay trust for the same tenant and user until the record expires or is removed; trusted devices do not provide hardware-backed device attestation.

Audit logs and webhooks

Trusted-device-specific audit logs include:

• TrustedDevice.Created: a trusted-device record and cookie credential were created after a successful interaction.
• TrustedDevice.Used: a trusted-device credential fulfilled MFA and the sign-in completed successfully.

You can subscribe to these data mutation webhooks:

• TrustedDevice.Created: a trusted-device record was created.
• TrustedDevice.Deleted: a user or administrator removed a trusted-device record.

The event data contains the trusted-device id, userId, and expiresAt. It excludes the cookie credential, secret hash, and request IP. There is no webhook for successful use to avoid high event volume, and policy changes do not emit trusted-device lifecycle events because they do not mutate records.

Natural expiration has no TrustedDevice.Expired webhook. Expiration occurs when time passes rather than when an application mutation runs, and physical cleanup may happen later. Use the expiresAt value from TrustedDevice.Created if your integration needs to derive the expected expiration time.

Natural expiration also does not create a trusted-device-specific audit log.

See audit log event types and webhook events for the event catalogs.

Lifecycle notes

• Normal sign-out does not remove trusted devices.
• Adding, removing, or resetting MFA factors does not remove trusted devices.
• Removing a trusted device does not terminate active sessions.
• Deleting the user deletes their trusted-device records through the user data lifecycle.
• There is no trusted-device count limit or automatic eviction.