StrongDM Vault
This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the StrongDM Help Center.
Overview
StrongDM Vault provides centralized management and rotation of credentials using a mechanism called secret engines. StrongDM Vault's secret engines are a feature that can be configured to manage and rotate credentials within a target database or service and within a secret store, in tandem. The chosen secret store can be StrongDM Vault's secret store, or any supported third-party secrets management or vault provider. Secrets within the secret store can then be used by StrongDM admins when configuring resource connections or entitling credential retrieval to users. The non-specific Key Value secret engine type can also be used to directly manage credentials within a secret store, without tying to any particular resource or service or performing automatic rotation.
Example Scenario: You wish to provide access to a PostgreSQL database through StrongDM, and you wish the credentials for the PostgreSQL database to be managed within StrongDM and rotated on a regular cadence.
You do not have a secrets management or vault provider of your own that you wish to integrate, so you set up an instance of the StrongDM Vault secret store.
You set up an instance of the PostgreSQL secret engine, which will allow you to rotate credentials within your Postgres instance. When credentials are rotated within that target database by the engine, it will also rotate a copy of those credentials within the secret store you just created.
You use the PostgreSQL secret engine to set up a managed set of credentials for a user that already exists in your Postgres database. Now that user's credentials will be rotated on a set schedule, both within the database itself and in the secret store.
You set up your database as a resource in StrongDM, configuring it to use the secret store for authentication to PostgreSQL, and pointing its username and password paths to the credentials you just added.
An end user of your StrongDM organization can now be given permissions to connect to the PostgreSQL resource through StrongDM, using credentials that are automatically rotated on a cadence and that are never shown to the end user.
Supported Secret Stores
A secret store is a vault or other external secret management service in which you can store and centrally manage credentials. StrongDM Vault is secret store agnostic. You can store your secrets with any supported secret storage service, and integrate it with StrongDM. Once this integration is set up, the node that reaches out to StrongDM for credentials is instead directed to authenticate itself to the secret store through the integration. Then it is able to fetch and use the credentials stored there for this resource.
StrongDM Vault secret engines require a backing secret store in which to store copies of credentials to use for resource access. The supported secret store providers are:
StrongDM Vault (requires nodes to be running version 51.51.0 or higher)
A secret store can be used for authentication to resources as an alternative to adding credentials directly to resources. When credentials are stored directly in resource configuration, the node that authenticates user traffic to the resource uses those credentials. When configured to use secret stores, the node instead reaches out to the secret store to obtain those credentials and authenticate the user to the resource.
Secret stores are used for two primary reasons:
Security Requirements: In some cases, if you already use a secret store internally, your security protocols may require that you not store resource credentials directly with other services like StrongDM, and continue to use your approved secret store.
Centralized Credential Management: A secret store provides a central place to manage credentials, so that they can be created, rotated, and deleted from one place, which is of increasing usefulness with larger sets of resources.
To learn more about configuring specific secret store integrations with StrongDM, see the Secret Stores section.
Secrets Management with StrongDM Vault
If your organization uses a secret store provider for credentials, you likely use that provider's interface to manage your secrets. However, in some cases, it might be preferable for administrators to be able to use StrongDM to manage credentials for resources that StrongDM is proxying traffic to.
StrongDM Vault secret engines can be configured for various target databases or services to manage and rotate credentials within the target. These engines also store copies of the rotated credentials in a backing secret store of your choice, so that when proxying user traffic to the target resource, the secret store can be referenced for credentials.
The currently available secret engines that are resource-specific and support rotation are:
Active Directory Secret Engine: StrongDM Vault can manage and rotate credentials within Active Directory, which can then be used when connecting to resources through StrongDM that would normally require AD credentials.
Microsoft SQL Secret Engine: StrongDM Vault can manage and rotate credentials within MSSQL databases that can then be added as resources and accessed through StrongDM.
MySQL Secret Engine: StrongDM Vault can manage and rotate credentials within MySQL databases that can then be added as resources and accessed through StrongDM.
PostgreSQL Secret Engine: StrongDM Vault can manage and rotate credentials within PostgreSQL databases that can then be added as resources and accessed through StrongDM.
If you have a lot of resources that you want to manage credentials for through StrongDM Vault, you need a lot of secret engines! The resource-specific secret engines that can do rotation connect to the actual database (or directory) to rotate credentials, in addition to doing so within a secret store, so you need one for each such resource. If you choose to use the Key Value secret engine, it is less specific since rotation is not involved, and can be used for many different types of resources at once to manage secrets only within a secret store.
The last type of secret engine is different in that it is not specific to a particular type of target resource or service. The Key Value secret engine can be used to manually create, update, or delete secrets within a supported secret store. This secret engine does not provide rotation or updates directly within any target resource, but only manages secrets stored in the secret store. This secret engine type can be used to manage credentials that you add to secret stores for connecting to resources through StrongDM that there are no secret engines for. Credentials can be added to a secret store for those resources using a Key Value engine, manually or through automations. This engine type is also useful for the management of secrets that do not pertain to resource connection, such as end users fetching an administrative Windows credential for themselves.
See the Example Scenario for a detailed step-by-step setup of a secret engine for a particular purpose.
StrongDM Vault use cases
Management of secrets using StrongDM Vault can solve for a variety of use cases, but here are a few core solutions provided by StrongDM Vault.
Automated Rotation for Secrets Used by StrongDM: StrongDM resource configurations can reference credentials stored in a StrongDM Vault or third-party secret store, and rotate those credentials at the source and in the secret store. This enables secretless access for end users while ensuring that backend credentials (for example, AD, Postgres, MySQL, MSSQL) are automatically rotated on a schedule. This improves security without adding operational overhead.
Controlled Checkout of AD Credentials for Admin Workflows: Admins may need temporary access to privileged AD accounts for specific operational workflows. StrongDM’s AD Secrets Engine supports credential checkout with automatic rotation for credentials that are entitled to users with policy. Rotation can occur either on a schedule or immediately after the credential is returned, ensuring safe, auditable, and time-bound use.
Breakglass Credentials for Emergency or Maintenance Access: Highly privileged AD or database superadmin accounts that are required for break-glass or critical maintenance workflows can be stored in a secret store, entitled to users using policy, and checked out under audit. After use, StrongDM automatically rotates these credentials to restore a secure baseline.
Shared API Keys Without Rotation Requirements: Teams sometimes need to share API keys, local administrator passwords, or credentials for resources that StrongDM is not used to access. You can store, manage, and retrieve those using the Key Value Engine backed by a secret store. These secrets are not rotated, but StrongDM provides centralized access controls and audit logging for visibility and governance (and storage, if StrongDM Vault is used).
Managed Secrets
To add managed secrets in the Admin UI, you need to have already configured a secret store as well as one or more secret engines. Once you've done so, follow these steps to manage secrets.
In the Admin UI and go to Settings > Secrets Management.
Select the Secrets tab and click Add Secrets.
On the dialog that displays, set the following properties:
Name: Enter a unique name for this secret. This name will display throughout StrongDM and help you to identify the managed secret.
Description: Optionally enter a description of the secret to help you to remember what it is for.
Select Secret Engine: Use the dropdown menu to select the secret engine to use to manage how and when users access secrets and facilitate the rotation of secrets.
Select or add tags: Optionally assign tags to the managed secret.
Click Save.
The Secrets tab now displays the secret that you just added, along with any other managed secrets that have been added via the Admin UI and CLI. You may now edit the secret's settings in order to schedule rotation and set a password complexity rules, view entitlements for the secret, and see any activities related to the secret.
Secret settings
After you have created a managed secret, you can set password complexity requirements, such as the number of symbols required, for passwords that are generated, rotated, or updated, to suit the needs of your organization.
For AD managed secrets only (not Key Value), you may schedule automatic password rotation by setting the credential rotation interval. A secret is valid for the given amount of time set, after which it is automatically rotated. If no interval is set or it is set to the default zero seconds, then there is no automatic password rotation, and rotation will need to be done manually for the secret on the Secrets tab.
The Settings tab is where you can update the secret's properties, set your password policy, and schedule automatic rotation. To get to the settings in the Admin UI, go back to Settings > Secrets Management Secrets. Click on the name of a managed secret and then click on the Settings tab to view or edit the secret's details. Alternatively, you can click Actions > View.
The following properties are shown on the Settings tab.
Name
Read Only
Name of the managed secret
AD-dev-secret
Description
Optional
Description of the managed secret to help you to remember what it is for
AD dev environment
Select secret engine
Required
Name of the secret engine configured for this managed secret
Example Name
Select or add tags
Required
Tags consisting of key-value pairs <KEY>=<VALUE>
env=dev
User DN
Required
For AD managed secrets, the user DN; should exactly match the distingushedName value found in the account attribute editor in Active Directory
Password
Optional
Password of the managed secret
1234567890
Credential rotation interval
Required
Amount of time in days, hours, and minutes that the secret is valid before it is rotated
0 days, 12 hours, 0 minutes
Timeout after credential read
Required
Amount of time in days, hours, and minutes for the secret to be viewed before it expires
1 days, 0 hours, 0 minutes
Length
Optional
Password length; if not set, defaults to zero (0)
24
Number of Digits
Optional
Number of digits to use when generating the password; if not set, defaults to zero (0)
24
Number of Symbols
Optional
Number of symbols to use when generating the password; if not set, defaults to zero (0)
2
Exclude Characters
Optional
Enter any characters to exclude when generating the password
@
Exclude Uppercase
Optional
Select the checkbox to exclude uppercase letters when generating the password
Allow Repeat
Optional
Select the checkbox to allow consecutive characters to repeat
If you rename an existing managed secret, and then later attempt to create a new secret that reuses the old name, this will create an error. If the original secret is removed rather than renamed, then that original name becomes available again.
Interaction with managed secrets
StrongDM admins may view managed secrets from the Admin UI in Settings > Secrets Management > Secrets tab. The Secrets tab displays the following details for each secret:
Name
Name the secret was given to it when created
TestUserCredentials
Path
The path of the secret store the secret is kept in appended with the name of the secret
test_ad/subdir/TestUserCredentials
Type
Type of secret; corresponds to the type of the secret engine used to manage the secret
Active Directory
Secret Engine
Name of the secret engine that was given to it when created
TestActiveDirectoryEngine
Tags
Tags given the secret by administrators
exampletag
Actions
Actions available for you to perform on this secret; view or delete
N/A
Secrets can be entitled to particular end users through policies and action control as well as being visible to admins who can manage secrets.Entitlement of secrets to a user can be used to allow the user to manually retrieve them for various purposes outside of StrongDM resource access. For example, this process might be used to audit and log the retrieval of a Windows administrator credential as needed by users.
See the Policy-Based Secrets Entitlement section for more details on how to entitle secrets to users, or see the Retrieve Secrets section for details on how to retrieve and interact with secrets as a user.
Secrets entitlements
From the Secrets tab, click on the name of a managed secret and then click on the Entitlements tab to view all the entitlements for the selected secret. Alternatively, you can click Actions > View. For managed secrets, entitlements are the specific actions (for example, retrieve, rotate, or validate) that the user or service account is allowed to perform on the given secret, as permitted by policy.
The Entitlements tab displays the following fields.
Name
Name of the user; this field may be blank for service accounts
Glick, Alice
Type
Type of account (user or service account)
User
Actions
Actions that the user is permitted to take on the secret (retrieve, rotate, or validate)
Retrieve, Rotate, Validate
Granted By
Name of policy
example policy
Last Accessed
Timestamp of when the secret was last accessed; this field is empty if the secret has never been accessed
Jul 10, 2025 1:45 PM
To learn more about entitling secrets to principals, read the Policy-Based Secrets Entitlement section.
Secrets activity
From the Secrets tab, click on the name of a managed secret and then click on the Activity tab to view all activities for the selected secret. Alternatively, you can click Actions > View.
For managed secrets, activities are the actions that a user has taken on the managed secret (for example, viewing, rotating, or validating). Note that activities are different than entitlements, as activities are what the user has actually done versus what the user is permitted to do.
The Activity tab displays the following fields.
Date
Timestamp for the activity
Jul 10, 2025 1:00 PM
Operation
Operation(s) performed on the secret
TTL_ROTATE
User
Name of the user, or "System" if for an automatic rotation
System
Logs for Secrets
Logs for secrets are recorded in the following areas within StrongDM:
Activity logs: Secret engine and managed secrets activities such as the creation, update, deletion, or rotation of secrets.
Secrets logs: All user activity related to secrets, such as retrieval of secrets by authorized users.
Policy logs: Any secrets activity that matches an evaluated policy is captured in the policy logs
Manage StrongDM Vault and secrets from the CLI
You can manage secret engines and create, update, remove, rotate, retrieve, and validate managed secrets all from the StrongDM CLI. See the dedicated guide to Secrets Management via CLI for more details.
Example Scenario: PostgreSQL Resource and StrongDM Vault Secret Store
1. Set up a secret store
If you haven't already done so, you should configure a secret store. This ensures that a secret store is already set up to contain secrets that can be managed. You may skip this step if you already have a secret store configured, but in this example we'll set up an instance of StrongDM Vault secret store.
To add a secret store in the Admin UI, follow these steps.
Log in to the Admin UI and go to Settings > Secrets Management. The settings that display are organized into four tabs for setting up secret stores, secret engines, secrets, and certificate authorities.
Select the Secret Stores tab and click the add secret store button.
On the form that displays, set the properties for the specific secret store you wish to add. In this case, we would create a secret store of the type StrongDM Vault and name it as desired. If the secret store type you choose is not StrongDM Vault, your nodes will also need to be configured to access the secret store provider. Please see the individual secret store documentation for requirements, properties, and configuration details for your specific secret store type.
The Secret Stores tab now displays the secret store that you just added.
2. Set up a secret engine
The following instructions show you how to set up a PostgreSQL secret engine.
Go to the Admin UI under Settings > Secrets Management. Then select the Secret Engines tab and select Add secret engine.
Select PostgreSQL for the type and then choose the secret store we just made as the Secret Store.
Set a meaningful path for the Secret Store Root Path. This could have something to do with the engine type, or the particular database this engine is for, or simply mirror the engine name.
Choose which nodes you would like to use to perform actions against your PostgreSQL instance and the secret store.
Fill in Postgres credential information for the account you wish to use to manage the credentials on the database, as well as any rotation specifics you wish and select Create.
If you have any questions about the setup of the PostgreSQL secret engine, follow the detailed steps in the PostgreSQL Secret Engine guide, and then return here.
3. Create a managed secret
Next, create a secret using the PostgreSQL secret engine. This will allow the secret engine to begin rotating the password for the selected username, and also begin storing it in our StrongDM Vault secret store, so that we can use it for proxying connections to the PostgreSQL database.
Go to the Admin UI under Settings > Secrets Management. Then select the Secrets tab and select Add Secret.
Fill in a Name and Description for the secret.
It may be reasonable to correlate this name with the PostgreSQL username or with the resource name that you intend to use this credential to access, if it is going to be used for leased credential access to the database.
For Select secret engine, select the engine you just created.
Fill in the name of the Database and the Username we are linking this secret to. You may enter the current Password for the user, or leave it blank, and it will be synchronized on first rotation.
Set any desired rotation specifics and then select Save.
4. Configure the resource to use this secret
Lastly, configure the resource to use this secret to authenticate to the PostgreSQL database. In this example, we'll connect using the secret we made as a leased credential user.
Fill in the resource configuration as you normally would, but for Secret Store, select the StrongDM Vault secret store we created. For Username (path) put /<SECRET_ENGINE_PATH>/SECRET_PATH?key=username and for Password (path) put /<SECRET_ENGINE_PATH>/secret<SECRET_PATH>path?key=password.
Now you should be able to grant access to this resource to a user through a role, if you have not done so already, or through Just-in-Time access with workflows, and attempt accessing it.
Further Reading
For more details about the PostgreSQL secret engine, see the PostgreSQL Secret Engine guide.
For more details about PostgreSQL resource setup, see the PostgreSQL Resource Configuration guide.
Conclusions
When deploying StrongDM, consider which method you plan to use to manage the credentials that you intend to use to authenticate StrongDM to resources.
Store credentials with each resource record as you configure it. This option is simplest, and a good option for organizations that do not already use secret stores or who do not have large amounts of resources.
Next step: Check out our resource guides on how to configure a resource with StrongDM.
Set up a StrongDM Vault secret store and use StrongDM to manage those credentials centrally, rather than having to edit each resource when needing to update credentials.
Next step: Choose a secret engine type from the list at the top of this page, or the navigation sidebar, and follow that guide to create the secret engine and use it to manage credentials and store them in a StrongDM Vault secret store.
Use your organization's third-party secret store. Set up the secret store integration with StrongDM, then configure resources to simply check a path within that secret store for the credentials, leaving you free to rotate and change them as desired from within your third-party tool without updating StrongDM resources.
Next Step: Review the supported secret store providers and read the guide on how to connect the one you choose to StrongDM.
Bring your own secret store, but use StrongDM to manage it, removing the need to use another tool to manage secrets when your admins already use StrongDM to manage access.
Next step: Review the list of supported secret stores above, configure its integration with StrongDM using the secret stores guides, and then select which secret engines you wish to use alongside your secret store and follow the guide(s) to set up a secret engine and create secrets in your store.
Last updated
Was this helpful?