Getting Help
Know where to turn when things don't go as planned. This module covers the support resources available to you as a StrongDM user or administrator.
Learning Objectives
- Explain the support resources that are available to you
Support Channels
Submit a Ticket
File a support request through the StrongDM support portal for technical issues, bugs, or questions. Tickets are routed based on your support tier.
Status Page
Check real-time system health, outage history, and incident updates at status.strongdm.com before filing a ticket.
Release Notes
Stay current with new features, bug fixes, and breaking changes by reviewing release notes regularly — especially before upgrades.
Support Tiers
Response times, channels, and SLAs vary by your plan. Know your tier so you can set the right expectations when engaging support.
Pro tip: Always check the status page at status.strongdm.com first. If there's an active incident, a ticket will resolve itself when the incident closes — saving you time.
Reference Links
| Resource | URL |
|---|---|
| StrongDM Support Guide | www.strongdm.com/support → |
| StrongDM Status Page | status.strongdm.com → |
| Release Notes | www.strongdm.com/docs/release-notes → |
| Support Tiers | www.strongdm.com/support → |
Knowledge Check
You notice StrongDM is behaving unexpectedly. What should you do first before submitting a support ticket?
✓ Correct! Checking the status page first tells you whether there's an active incident — which would resolve on its own without a ticket.
Getting Started
Set up your first StrongDM environment. Understand the components, install the software stack, and establish your first resource connection.
Learning Objectives
- Describe available technical documentation repositories
- Understand the components of StrongDM-in-a-box
- Install the StrongDM client, Gateway, and Relay
- Connect to a resource and understand what proxies are
StrongDM-in-a-Box Lab
Instruqt Hosted Lab
StrongDM provides a hands-on lab environment hosted on a third-party platform called Instruqt. This gives you a pre-configured environment to practice installations and configurations without needing your own infrastructure.
Alternative: If Instruqt is unavailable or you prefer a self-hosted environment, download the StrongDM-in-a-box lab guide included in this module. It recreates the Instruqt environment on your own infrastructure.
Core Components
StrongDM Client
Installed on the end-user's machine. Authenticates the user and routes their traffic through the StrongDM proxy network using TLS.
Gateway
The network proxy component. Receives traffic from the client via TLS, authenticates to the target resource, and forwards the session. Sits between the internet and your private resources.
Relay
Similar to a Gateway but cannot be reached directly from the internet. Relays sit behind a Gateway to proxy traffic to resources in highly segmented networks.
Resource
Any digital infrastructure (database, server, cloud console, website) your organization needs to protect and control access to.
Traffic Flow Architecture
Proxy network traffic flow
proxy network
How Proxies Work
Proxies connect on your behalf
A proxy intermediates between the user and the target resource. The resource only ever sees a connection from the Gateway — not from the user directly. This is what allows StrongDM to enforce policy, log every session, and inject credentials securely.
Credentials are held by the proxy
Resources require authentication (username, password, SSH key, etc.). When a proxy is involved, the proxy holds and presents these credentials to the resource on the user's behalf. The user never sees or handles the raw credential — only the Gateway does.
Knowledge Check
What protocol does the StrongDM client use to communicate with the Gateway inside the proxy network?
✓ Correct! Traffic between the StrongDM client and the Gateway is always encrypted over TLS, regardless of the underlying protocol the resource uses.
Introduction to Resources
Dive deeper into how resources are registered, accessed, and secured. Covers identities, credential leasing, and secret store integrations.
Learning Objectives
- Understand the networking requirements to access a resource
- Understand, at a high level, how proxies work
- Understand how StrongDM policies control access to resources
- Connect to resources in the StrongDM-in-a-box lab
What Is a Resource?
Any digital infrastructure your org manages
A resource is anything your organization creates or uses — databases, SSH servers, Kubernetes clusters, web applications, cloud consoles. StrongDM proxies network traffic to these resources and enforces access based on policies you define.
In the StrongDM-in-a-box lab, the Web server and SSH server running on a Linux host are the resources. The Gateway allows or forbids traffic to them based on StrongDM policies.
| Topic | Reference URL |
|---|---|
| Resources overview | strongdm.com/docs/admin/resources → |
| Add a resource | strongdm.com/docs/admin/quickstart/#add-a-resource → |
Identities
Native StrongDM Users
Created directly in StrongDM using a unique email address and a first/last name. These are the default user type for getting started. Duplicate names are accepted but unique names are strongly recommended.
Service Accounts (Non-Human Identities)
Used by programs, scripts, and automated processes rather than humans. They run persistently and carry high-level privileges — their credentials must be known to every dependent system, making them a high-value security target.
Note: Externally managed users from Identity Providers (IdPs) such as Okta or Azure AD are discussed in depth in StrongDM 201 – Authentication.
Credential Leasing
Credentials are injected at the last mile
StrongDM Gateways and Relays inject credentials during the final hop to the resource. The credential is never transferred to the client in any form. Users connect through StrongDM but never see or possess the underlying username/password or SSH key for the resource.
Credential injection flow
Red arrow = last-mile hop where credentials are injected. Credentials never leave the Gateway/Relay.
Dual-key decryption model
Credentials are unlocked at runtime only when both conditions are met: a cryptographically valid proxy instance (Gateway or Relay) requests decryption and it does so on behalf of a cryptographically valid user session. Neither the user alone nor the proxy alone can decrypt the credential.
| Topic | Reference URL |
|---|---|
| Credential handling | strongdm.com/docs/…/credential-handling → |
| Credential leasing | strongdm.com/docs/…/credential-leasing → |
| Identity alias | strongdm.com/docs/admin/users/identity-alias → |
Secret Stores
Strong Vault — zero configuration
Every StrongDM deployment includes Strong Vault as the default secret store. It stores passwords, certificates, and SSH keys. Credentials stored in Strong Vault are encrypted immediately and are never retrievable after setup — but can be rotated. No configuration is needed, which is why there is no "Details" button in the Admin UI for this option.
StrongDM is vault agnostic
If your organization already uses HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or another supported provider, StrongDM can integrate with it. Your existing credential rotation workflows don't need to change. When a client connects, the Gateway authenticates to your secret store, fetches the credential, uses it for the session, and then discards it — it is never stored or recorded by StrongDM.
Setting up a third-party secret store
Configure the secret store provider
Register your third-party vault (e.g., HashiCorp Vault, AWS Secrets Manager) in StrongDM's Admin UI under Secret Stores.
Authenticate your Gateway/Relay
Configure your Gateway or Relay servers with the credentials or IAM roles needed to authenticate with the secret store at runtime.
Point each resource to its credential path
When adding a resource in StrongDM, provide the path (key name) where the credential lives in your secret store — not the credential itself.
| Topic | Reference URL |
|---|---|
| StrongDM Secret Stores overview | strongdm.com/docs/…/secret-stores → |
| About Secret Stores (admin guide) | strongdm.com/docs/admin/secret-stores → |
| Blog: Works with your secrets manager | strongdm.com/blog/strongdm-works-with-your-secrets-manager → |
Knowledge Check
A user connects to an SSH server through StrongDM. Where does the credential injection happen?
✓ Correct! Credentials are injected during the last-mile hop by the Gateway or Relay. They are never sent to the client and never leave the Gateway/Relay server.