Last modified on June 5, 2024


StrongDM supports three authentication models:

Additionally, you can find more information about authentication via SSO on the SSO Settings page and see a list of identity provider integrations if you wish to learn more about how to configure SSO authentication with StrongDM.

Delegated Authentication

The most common method of authenticating to StrongDM is via delegated authentication.

Authentication is commonly delegated to a directory (such as Microsoft Active Directory) or single sign-on provider (such as Okta or Google).

It is not necessary to delegate authentication but can be convenient to link existing tools with StrongDM.

Native Accounts

Native accounts are necessary for StrongDM administrative users.

Native accounts are also utilized in cases where a directory or single sign-on provider is not available.


The Hybrid authentication model employs a Directory or SSO provider, but also allows the StrongDM administrator to create accounts that are not SSO-linked. This can be useful in organizations where contractors or other non-SSO users require access to StrongDM.

Multi-factor Authentication

StrongDM supports multi-factor authentication (MFA) during a variety of authentication actions on the platform. Currently, StrongDM supports the following options for MFA:

Please see the guides for setup and usage of individual MFA providers for further information.


Password requirements are set in the Admin UI in Settings > Security. You can force the passwords of your StrongDM users to be of higher strength. By default, the only password requirement is that the password be eight characters long.

Password strength requirements can be increased from “No minimum strength” to “Medium,” “Strong,” or “Excellent.” If you require higher password strength, users need to add complexity to their passwords until they grade at the higher rating you have set as the requirement.

The strength of a password can be difficult to determine. In this case, StrongDM uses the zxcvbn password strength method to test your password strength. This method discards arbitrary rules about characters and length. Instead, this method analyzes each suggested password and gives it a strength rating based on a number of factors, including length, dictionary checking, password matching, and so forth.

Independently of the password strength requirement, you can also set a minimum length requirement for your users’ passwords. You should not set this minimum length to be lower than the default minimum for the password strength requirement that you have set.


There are two types of authentication timeouts for StrongDM users: idle timeouts, which have to do with the idle time of an authenticated user; and session timeouts, which pertain to overall length of authenticated sessions. Note that these limitations are applied for human users, not service accounts.

Idle Timeout

Idle timeouts force users to log out of the client or Admin UI after a set amount of minutes of inactivity (that is, instances where no packets are received). For example:

  • The client logs out users after 20 minutes of idleness.
  • Admin UI logs out users after 20 minutes of idleness.

Note that idle timeouts may be triggered by blocked processes and long-running queries.

Session Timeout

The session timeout forces users to log out once their session reaches the predetermined time limit. For example:

  • Users must re-authenticate every eight hours.