Master advanced authentication, secrets management, certificate authorities, and deployment architecture across two comprehensive modules.
How StrongDM stores, manages, and retrieves encrypted credentials for resources across your infrastructure.
fse/secret/FSE-DB).Use this decision tree to determine the right option for your deployment.
| Feature | Stored in StrongDM | StrongDM Vault |
|---|---|---|
| Default option | ✓ Yes | ✗ No |
| Configuration required | None needed | Required |
| Credential rotation | ✗ Not supported | ✓ Supported |
| License requirement | Any license | Enterprise only |
| Stores passwords, certs, keys | ✓ Yes | ✓ Yes |
| Previously known as | "Strong Vault" | — |
These secret engines can automatically rotate passwords on the resource AND update the secret store. Supported resource types:
Stores arbitrary secrets in the supported secret store without automatic rotation on a resource. Use when:
When a secret is created in StrongDM Vault (e.g., with path fse/secret/FSE-DB), you reference it from the resource configuration using key arguments:
?key=username and ?key=password arguments are required by StrongDM Vault to reference individual fields.
How StrongDM automates credential lifecycle management including retrieve, rotate, and validate operations.
Fetches the current managed secret from the secret store so a user can view and copy it.
The secrets engine retrieves the managed secret from the secret store.
The node authenticates against the resource (e.g., Active Directory) to confirm the secret is still valid.
The secret is shown in a popup on the Admin UI. Users can copy it for use in other systems.
Both the policy evaluation and the actual read are logged — in Logs → Policies and Logs → Secrets respectively.
Replaces the existing credential on both the resource and in the secret store atomically.
The node creates a new credential based on the password policy configured in the secret engine.
The new credential is written to the resource (e.g., AD account password is changed).
The new credential is saved to the secret store so future retrievals return the current value.
Checks whether the stored secret still matches what the resource expects — useful if someone changed a password directly on the resource outside of StrongDM.
The current managed secret is pulled from the store.
The node attempts to log in to the resource using the stored secret.
If validation succeeds: the stored secret is confirmed valid.
If validation fails: the credential was changed out-of-band — run a Rotate to re-sync.
StrongDM::ManagedSecret::Action::"retrieve" as the action format and StrongDM::ManagedSecret as the resource type.
How StrongDM uses CAs to establish identity and enable certificate-based authentication for SSH and RDP.
Confirms an entity is who it claims to be — preventing attackers from impersonating servers or users.
Once verified, the CA issues a certificate bound to the entity via a public key. The certificate derives its trust from the CA.
Compromised or misused certificates can be added to a Certificate Revocation List (CRL) by the CA.
| Client | Server | |
| Initiate SSH connection | → | |
| Verify host key against trusted Host CA | ← | Send SSH Host Key Cert (signed by Host CA) |
| Send SSH User Key Cert (signed by User CA) | → | Verify client key (optional) |
| Host key validated | ← | Accept connection |
|
Establish Secure Channel
|
||
Used for DNS-based resource connections. Tag: se-dnscert
Used for Remote Desktop Protocol connections. Tag: se-rdpcert
Used for SAML-based authentication flows. Tag: se-samlcert
Used for SSH certificate-based authentication. Tag: se-sshcert
Understanding how traffic flows from users to resources, and what makes a production-grade StrongDM deployment different from the lab environment.
Logging on identifies the user to the StrongDM network. User identities are associated with one or more Roles, which determine accessible resources.
Users can authenticate using their StrongDM account credentials or via an integrated Identity Provider (IdP) such as Google, Okta, or Azure AD.
Users request access via Access → Request Access → Catalog in the StrongDM console. After approval, the resource appears in the SDM client with a local address (e.g., 127.0.0.1:10006).
Users connect using their normal tools (SSH client, database client, browser) to that local address — StrongDM handles the rest transparently.
StrongDM uses a proprietary routing protocol hosted in the control plane to find the best path through the proxy network. Three routing modes exist:
StrongDM's security role doesn't end at access — it continues monitoring with:
The lab uses only one Gateway — no high availability. Production requires multiple Gateways for redundancy.
The lab has no Relay. Production environments separate the resource network from the DMZ using Relays behind firewalls.
Client, Gateway, and resources are all in the same network. Production uses separate subnets and security devices (firewalls, DMZ).
How nodes work together to securely route traffic from users to resources across network boundaries without inbound firewall rules.
The Relay and Gateway both register with app.strongdm.com via TCP 443 and subscribe to a GRPC notification queue.
The control plane sends each node the list of relevant Gateways and Relays it should know about, including routing information.
The Relay establishes a persistent outbound TLS tunnel to the Gateway on TCP 5000. The Gateway maintains this connection.
When a user connects, their traffic travels through the SDM client → Gateway → Relay → Resource via the established TLS tunnel. The final hop uses the resource's native protocol (SSH, SQL, RDP, etc.).