StrongDM Security Guide: Hardening Nodes, Tokens, Policies and Audit Logs

StrongDM brokers access to databases, servers, Kubernetes clusters and web applications, so the nodes, tokens and administrative rights that run it become a single control point for a large share of your infrastructure. Whoever holds an unscoped admin token, the Administrator permission level, a node install token or a proxy cluster secret key can change who reaches production. This guide covers the customer-side settings that harden a StrongDM organisation, as described in StrongDM's documentation: placing gateways, relays and proxy clusters, handling node keys, scoping admin tokens and service accounts, designing permission levels, roles and access workflows, writing Cedar policies, and keeping audit logs and replays under your own control. It is written for platform, identity and security engineers who administer StrongDM. For the wider discipline, see the Privileged Access Management Guide.

This is an independent guide from NHI Mgmt Group, based on StrongDM's public documentation as of November 2026. It is not sponsored or reviewed by StrongDM. Product features change, so confirm settings against StrongDM's current documentation.

Key takeaways

• Admin tokens are the quiet super-users. Each token carries resource:action permissions and an expiry of one week, one month, one year or never; give every token the narrowest permission list and a finite expiry, and rotate tokens owned by people who leave.
• Node secrets are shown once and must be treated as credentials. Gateway and relay install tokens and proxy cluster secret keys appear a single time; store them in a secrets manager and use the overlapping key slots to rotate cluster keys without downtime.
• Keep sensitive resources behind relays or segmented clusters. Relays open no inbound ports and reach out over 443, so the resource network needs only egress rules.
• Policies decide what a granted user may actually do. Cedar forbid statements always win, so use them for MFA, justification and command-level limits on production databases.
• Decide where audit data lives before go-live. The Log Encryption & Storage settings control whether queries and replays are stored with StrongDM, kept locally on nodes, encrypted with your public key and streamed to your own storage.

How the StrongDM architecture shapes the attack surface

Users and service accounts authenticate to the StrongDM control plane, usually through single sign-on, and receive access defined by roles, access workflows and policies. Traffic to resources flows through nodes that you host: gateways and relays, or proxy clusters, which StrongDM describes as the recommended deployment. Gateways are the entry point that clients reach; they decrypt client traffic and deconstruct requests for auditing. Relays connect to resources but accept no client connections, building a reverse tunnel to a gateway. From the resource's point of view, every session comes from a node, which is what makes the nodes and the credentials they hold tier-zero.

The ATT&CK techniques most relevant to a privileged access broker are T1078 Valid Accounts (a compromised identity provider account), T1528 Steal Application Access Token and T1550.001 Application Access Token (a copied admin or service token), T1552.001 Credentials In Files (tokens left in shell profiles, CI variables or /etc/sysconfig files) and T1098 Account Manipulation (an attacker granting themselves roles).

Gateways, relays and proxy clusters

StrongDM documents two node models. Gateways and relays suit smaller or simpler networks; proxy clusters suit large networks that benefit from segmentation, and StrongDM recommends one proxy cluster per environment that hosts resources.

Hardening the nodes

• Use relays for sensitive segments: StrongDM positions relays for networks that cannot expose ports, such as segments holding PHI or PII. Because the relay builds a reverse tunnel, the firewall needs egress rules only.
• Segment clusters by environment: every worker in a proxy cluster must reach the same set of resources, so a production cluster and a development cluster should be separate clusters with separate keys.
• Capture join secrets straight into a vault: install tokens and cluster secret keys are displayed once. Paste them into your secrets manager or deployment pipeline secret, never into a ticket or chat.
• Rotate cluster keys with the overlap: each cluster allows four keys by default. Create a new key, update workers, confirm they authenticate, then delete the old key; both keys work during the overlap.
• Treat node hosts as tier-zero: the sysconfig files hold join secrets, and relays hold secret store credentials. Restrict interactive login to node hosts, keep them patched, and build them from a controlled image.
• Watch node status: a relay that cannot reach any gateway shows as isolated, and nodes with no heartbeat for 30 days are removed automatically. Unexpected new nodes, or nodes changing IP, deserve investigation.

For jump host design principles that apply equally to StrongDM nodes, see Securing the Bastion Host.

Admin tokens and service accounts

StrongDM has two token-based principal types. Admin tokens automate administration: auditing, managing users, roles, resources, nodes, access and secret stores. Service accounts give machines and applications resource access through roles, authenticating with an access token instead of a username and password. Both are non-human identities and belong in your NHI inventory; see the Service Account Security Guide.

Token hygiene

1. Scope by job: a reporting job needs list permissions only. StrongDM notes that some commands need extra grants (listing relays also needs datasource list rights), so test the token against its real job and add only what fails.
2. Pick a finite expiry: choose one week for short projects and one year at most for pipelines, and record a renewal owner. Reserve "never" for documented exceptions with a review date.
3. Store tokens in a secrets manager: inject SDM_ADMIN_TOKEN at runtime rather than exporting it in shell profiles or CI configuration files.
4. Handle leavers deliberately: tokens stay usable after their creator is suspended, and the suspension dialog asks whether to delete them. StrongDM recommends rotating tokens if a holder leaves, if the owner is suspended or if compromise is suspected.
5. Tag and inventory: use --tags to record owner, system and purpose, and reconcile the token list quarterly.

For general token practice, see the API Key Management Guide.

Permission levels, roles and SSO

Administrative power in StrongDM comes from the user's permission level. Resource access comes from roles. Keep the two separate in your design.

• Roles: static rules list specific resources; dynamic rules match a resource type and tags, with an advanced mode supporting AND, OR, NOT and parentheses. A dynamic rule such as env=prod AND team=payments grants new matching resources automatically, so control who can set tags on resources.
• Role ownership: the Managed by filter shows roles managed through SCIM. Provision roles from the identity provider where possible so joiner, mover and leaver changes flow automatically.
• SSO only: set Allow Password Login to Disable for users, keep Allow non-SSO users? off unless you have a documented break-glass need, and turn off Allow password login for admins? once SSO is confirmed working (StrongDM advises keeping it on until then).
• MFA at the identity provider: StrongDM recommends enabling MFA through your identity provider; in-product MFA then applies to desktop app re-authentication and policy prompts. Enable SSO Reauthentication? defaults to Yes for Okta and should stay on.
• Suspend in both places: users suspended in the identity provider lose sessions, but StrongDM recommends suspending or deleting them in StrongDM too.

Access workflows and Cedar policies

Access workflows (Enterprise plan) provide just-in-time access: users see resources in their catalog only through the roles attached to a workflow, request them, and approvers grant access for a set duration. For the model behind this, see the JIT Access Guide.

• Duration: choose a fixed duration for production, or a user-specified duration with a low cap. The organisation default maximum is 30 days, configurable in 15-minute increments; for privileged production access, hours are usually enough.
• Self-approval: leave Requesters may approve their own requests off for privileged workflows so an approver cannot grant themselves access.
• Request timeout: set Request timeout duration so stale requests close rather than waiting for an absent approver.
• Precedence: where resources overlap, the workflow higher in the list wins, so put the strictest production workflow first.
• Early revocation: approvers can revoke granted access before it expires; build that into incident runbooks.

Policies add conditions on top of grants, written in Cedar as permit and forbid statements. With no global access policy, access is denied by default; with one, all granted actions are permitted and forbid statements carve out exceptions. Any forbid wins over any permit.

From CLI 51.53.0, a policy change that forbids a connection disconnects existing sessions within five seconds, which makes a targeted forbid statement a fast containment tool. For policy design, see the Policy-as-Code for Authorisation Guide.

Secret stores and credential custody

StrongDM can reference resource credentials by path in an external store (StrongDM Vault and a range of third-party secret stores, including the major cloud providers' secret managers; check StrongDM's documentation for the current list). The relay authenticates to the store and retrieves credentials itself, so neither store credentials nor resource credentials are sent to StrongDM.

• Require secret stores: set Allow credentials to be stored in StrongDM to No under Settings > Security so new resources must use a store. Existing resources are unaffected, so plan their migration; a resource's store cannot be changed after creation, so recreate it.
• Provision relay credentials per host: sdm nodesecrets ties credentials to the host where they are set, and they cannot be used on a cloned host.
• Scope the relay's vault identity: give it read access only to the paths its resources need. See the Secrets Management Guide.
• Plan for vault outages: if the store is unreachable the dependent resource goes offline, although already-authenticated connections stay active.

Audit logs, replays and export

StrongDM records activities (Admin UI and CLI events), queries (resource access and commands), replays for SSH, Kubernetes and RDP sessions, and node errors in sdm.log. The settings are under Settings > Security > Log Encryption & Storage.

• Storage choice: Store with StrongDM? is set per category (SSH, RDP, Kubernetes, Queries, Cloud, Web). If off, only session metadata is stored and the logs cannot be viewed in the Admin UI or sent by Log Stream, so pair that choice with local logging.
• Your own key: choose Public key for remote and local encryption so only you can decrypt query bodies and authorisation data. Metadata stays visible, and saving encryption settings restarts all nodes, so schedule the change.
• Local logging: Store logs locally? supports Log Files, Stdout, TCP, Socket and Syslog, in JSON or CSV. If a Socket, Syslog or TCP destination is unreachable at startup, nodes shut down, so make the collector highly available before pointing nodes at it.
• Export and retention: Log Stream (Enterprise) sends audit logs to object storage such as Amazon S3. Retention in StrongDM is 13 months on Enterprise and 30 days otherwise; keep longer copies yourself where regulation requires.
• Policy evaluations: view them under Logs > Policies; in exported data, events carrying the authz field are policy evaluations.

For review practice, see the Privileged Session Management Guide.

How to implement

1. Baseline: export the lists of administrators, admin tokens, service accounts, nodes, roles and workflows. Record owner and purpose for each token and node.
2. Identity first: connect SSO with MFA at the identity provider, enable SCIM role management, and disable password login once a tested break-glass path exists.
3. Reduce Administrators: move onboarding staff to Database Administrator, reviewers to Auditor and managers to Team Leader, leaving a small Administrator group.
4. Fix tokens: re-issue unscoped or never-expiring admin tokens with narrow permissions and finite expiry, store them in a vault, then delete the old ones. Deletion is immediate, so cut over each consumer first.
5. Logging before policies: configure log encryption, local logging and export, and confirm events arrive in your SIEM before tightening access, so you can see what breaks.
6. Pilot policies: start with a global access policy plus forbid statements for one non-production resource group (MFA and justification), review Logs > Policies for a week, then extend to production.
7. Move production to workflows: remove standing roles for production, publish access workflows with fixed short durations and no self-approval.
8. Roll back safely: keep previous role memberships exported; a policy statement can be removed, and a disabled workflow cancels pending requests immediately, so announce changes to users first.

Detection and measurement

Stream activity, query and policy logs into your SIEM and alert on the events that change trust:

• Permission level changed to Administrator, or new roles or access rules created outside change windows.
• Admin token created with no expiry, with broad permissions, or used from an unfamiliar network.
• New gateway, relay or proxy cluster key created; nodes changing state to isolated.
• Changes to Log Encryption & Storage, SSO or password login settings.
• Policy denials spiking for one principal, which can indicate credential misuse.

For rule ideas, see Detection Engineering for Non-Human Identities Guide.

Common failure patterns

• Never-expiring automation tokens: a pipeline token created with expiry "never" and broad permissions outlives the engineer and the project.
• Join secrets in tickets: install tokens pasted into chat or change records, where anyone with access to the history can register a node.
• Tag sprawl: dynamic rules based on tags that many teams can edit, so mislabelling a resource silently grants access.
• Self-approval left on: approvers able to grant their own requests, removing the second person from privileged access.
• Logging to a fragile collector: a syslog target that is down at startup causes nodes to shut down and restart in a loop.
• Leaver tokens left in place: tokens kept after their owner's suspension without rotation.

Framework mapping

Practitioner checklist

• Administrator permission level held by a small named group, reviewed quarterly.
• Every admin token scoped, tagged with an owner and set to a finite expiry.
• Admin and service account tokens injected from a secrets manager, never stored in profiles or CI files.
• Node install tokens and proxy cluster secret keys captured once into a vault; cluster keys rotated on a schedule.
• Sensitive resource segments reached through relays or dedicated proxy clusters with egress-only rules.
• Password login disabled for users and admins once SSO and break-glass are tested; MFA at the identity provider.
• Production access through workflows with fixed short durations and self-approval off.
• Cedar policies requiring MFA and justification for production, reviewed in Logs > Policies.
• Allow credentials to be stored in StrongDM set to No, with existing resources migrated to a secret store.
• Logs encrypted with your public key, exported to your storage and SIEM, retained to your policy.

Standards and references

• StrongDM: Gateways and Relays
• StrongDM: Proxy Clusters
• StrongDM: Admin Tokens
• StrongDM: Permission Levels
• StrongDM: Access Workflows
• StrongDM: Policies
• StrongDM: Secret Stores
• StrongDM: Logs

Related NHI Mgmt Group resources: Cloud PAM and Just in Time Access · Privileged access management (PAM) vault rollout playbook · JIT Access Guide · Service Account Security Guide