StrongDM 201 · Access Module · October 2025
📘 StrongDM 201 · Access

Access Management
Training Guide

A comprehensive deep-dive into how StrongDM manages identities, resources, and access controls — covering users, roles, workflows, and device trust.

Users & Permissions Roles & Access Rules Approval Workflows Standing Access Device Trust 3rd Party Integrations
Users & Accounts

Human users and non-human service accounts. Permission levels, admin tokens, and identity management.

pg 20–26
Roles & Access Rules

How roles group identities and grant resource access via static or dynamic access rules.

pg 27–33
Workflows

Approval and Access workflows for just-in-time, policy-driven resource access with time-limited grants.

pg 37–51
Device Trust

Integrating endpoint security posture (CrowdStrike, SentinelOne) into StrongDM policies.

pg 72–80
💡 How to use this guide: Navigate using the sidebar or Prev / Next buttons. Each section includes key concepts, interactive accordions, and knowledge-check questions to reinforce learning.
👤

Users & Accounts

Identities that interact with the StrongDM platform — slides 20–26

Human Users

What is a User?
  • An identity that can log in via Admin UI, StrongDM client, or CLI.
  • Requires an email address and first & last name at creation.
  • An invitation email is sent to the specified address to join the network.
  • Can be assigned one of five permission levels (no custom levels).

Permission Levels

Action Admin Auditor DB Admin Team Leader User
Access datasources, servers, clusters, clouds & websites✓✓✓✓✓
Access dashboards✓✓–––
Audit activities, queries & SSH captures✓✓–––
Audit account configuration✓✓–––
Grant administrative access✓––––
Grant access to datasources, servers, clusters, clouds & websites✓––––
Invite and suspend users✓––✓–
Manage user details✓––––
Manage service accounts, admin tokens & API keys✓––––
Create roles and manage their access✓––––
Move users into and out of roles✓––✓–
Manage datasources, servers, clusters, clouds & websites✓–✓––
Manage relays and gateways✓––––
Update account settings✓––––

Service Accounts

Non-Human Identities
  • Provide programmatic access to resources — no email or full name required, only a display name.
  • Authenticate to the StrongDM control plane with admin tokens.
  • When created, the token has no admin permissions — resource access is granted via roles.
  • Auto-Connect is disabled by default (security best practice), since service accounts cannot self-authenticate the way humans can.
⚠ Note: The admin token shown only once at creation time — copy it immediately. It cannot be retrieved later. You can rotate credentials to generate a new token.
Quick Recap: Users vs Service Accounts ▼
Human Users
  • Require email + name
  • Login via UI, client, CLI
  • Invited via email
  • 5 permission levels
Service Accounts
  • Display name only
  • Authenticate with admin token
  • Auto-Connect off by default
  • Access via roles
🔑

Roles & Access Rules

Grouping identities and defining resource access — slides 27–33

What is a Role?

Roles are the primary mechanism for providing access to resources in StrongDM. Both human users and service accounts can be added to roles. Roles have two configurable components:

👥 Members

Individual user identities that share attributes and are managed as a group. Identities can belong to multiple roles simultaneously.

📋 Access Rules

Define which resources role members can access. Predates policies — if policies are not enabled, this is the sole resource access control.

⚠ Note: Members can also be added to roles via SCIM integrations (System for Cross-Domain Identity Management) for automated provisioning.

Access Rule Types

📌 Static Rules — explicit resource assignment ▼
  • Resources are explicitly selected and added to the role from a list.
  • Good for targeted access where the resource list is well-known and stable.
  • Requires manual updates when new resources need to be added.
  • Example: Grant access to marketing-db-1, SSH-07, and dev-web.
🔄 Dynamic Rules — tag-based automatic assignment ▼
  • Resources are added automatically based on resource type and tags.
  • Best for organizations with a well-defined tagging strategy.
  • New resources with matching tags are automatically added to the appropriate role.
  • Example: Grant access to all staging servers in the us-east-1 region.
Access updates automatically when resources are created, modified, or removed — no manual intervention needed.
⚠ Important: The same rule interface design is used in the Access Workflow feature, but selections in Access Rules are not connected to selections in Access Workflow. Do not confuse one with the other.
🔄

User & Group Provisioning

Syncing users from external identity providers — slides 34–36

What is User Provisioning?
  • Lets you manage users in one place (your IdP) and have them automatically populate in StrongDM.
  • Eliminates the need to create duplicate user records in StrongDM.
  • Users are set up in the external service first, then synced to StrongDM.
  • Provisioned users cannot be individually edited within StrongDM — changes must be made at the source.
  • Provisioned users get resource access the same way as native users: by assigning them to roles.

Supported Providers

Azure AD

Sync users and groups via SCIM from Microsoft Azure Active Directory.

Okta

Automate user lifecycle management using Okta's SCIM integration.

Google Workspace

Provision users directly from Google Workspace directory.

OneLogin & Generic SCIM

Use any SCIM 2.0-compliant provider via the Generic SCIM endpoint.

SCIM 2.0 Protocol

StrongDM uses the System for Cross-Domain Identity Management (SCIM) 2.0 API, which allows compliant applications to manage user and group provisioning automatically.

SCIM Users API SCIM Groups API Automatic sync Source-of-truth: external IdP
💡 Detailed setup instructions for each IdP integration are covered in the "Integrating with IdPs" section of the StrongDM 201 — Authentication module.
⚡

Workflows

Approval and access workflows for just-in-time access — slides 37–51

Overview

When StrongDM policies are enabled, administrators can use Workflow Approval functionality. Workflows are triggered by a policy match and prompt users to request access to resources.

There are two workflow types that work together:

Access Workflow

Defines what resources appear in the Request Access Catalog and who (which roles) can see that catalog.

Approval Workflow

Defines who approves or denies requests, and how (automatically, via ServiceNow, or manually).

⚠ Critical: An Access Workflow cannot be saved without selecting an Approval Workflow. They are linked.

Approval Workflow Types

✅ Automatic Approval — instant, no human review ▼
  • Requests meeting policy requirements are instantly approved — no human intervention needed.
  • Ideal for machine-to-machine interactions or low-risk resources where friction should be minimized.
  • Available out-of-the-box in all StrongDM installations.
🔧 ServiceNow Approval — ITSM-driven approvals ▼
  • Integrates with ServiceNow — requests and approvals are managed via ServiceNow workflows.
  • Requires installation of the StrongDM ServiceNow application from the ServiceNow Store.
  • Useful for organizations with existing ITSM change-management processes.
👥 Manual Approval — designated StrongDM approvers ▼
  • Selected StrongDM users or roles must manually approve or deny each request.
  • User receives an "Approval Workflow Notification" prompt on their StrongDM client.
  • Approver sees the request in Admin UI under Access → Request Access → Requests.
  • Approver clicks Actions → View request details → Approve.
  • Once approved, user can access the resource via the StrongDM client.
Note: Approvers can only approve their own requests if "Requesters may approve their own requests" is enabled in Approval Workflows Settings.
# Confirm access post-approval via CLI
sdm status
# Shows: resource name, status, address, type, tags, expiry

Creating an Access Workflow

1

Assign Resources

Define which resources appear in the user's Access Catalog. Users will be able to request these resources.

2

Attach Roles

Select which roles can view and request from this Access Catalog. Only role members can see the catalog entries.

3

Set Approval Criteria

Choose the Approval Workflow (Automatic, ServiceNow, or Manual) that will process requests for this workflow.

Access Duration Settings

Workflow Settings
  • Granted access is not permanent — it is time-limited.
  • Maximum permitted duration is 45 days per request.
  • Two modes: User-specified duration (user chooses, up to the max) or Fixed duration (admin sets, users cannot change).
  • Policy-triggered access (via the "With" policy statement) grants access for the configured approval duration (e.g., 4 hours).
🛡️

Standing Access

Understanding persistent access and the zero-privilege model — slides 52–65

What is Standing Access?

"Standing access" refers to how long a user has access to a resource — specifically, persistent access that doesn't require requesting each time. When a role's Access Rule grants a resource directly, that user has standing access: the resource is always visible on their StrongDM client and no catalog request is required.

⚠ This is generally discouraged and should be reserved for testing or carefully considered use-cases. Even with standing access, policy-based controls can still require approval before an actual connection is made.

The Standing Access Spectrum

Unrestricted Standing Access Zero Standing Privileges
Frictionless user experience Reduced attack surface

The key is balancing user needs for frictionless access against security requirements. Most organizations aim for a position closer to zero standing privileges, especially for sensitive resources.

Security Maturity Levels

Level 1 — Identity-Based Access ▼
Identity-based access management has been adopted. Users authenticate with a known identity, but no special controls on what resources they can access beyond basic IAM.
Level 2 — Privileged Access ▼
Additional security measures for privileged accounts, often via a PAM solution. High-privilege actions are logged and controlled.
Level 3 — Just-in-Time Access ▼
JIT access implemented for highly sensitive credentials. Security expands beyond just privileged accounts — users request access only when needed, and it expires automatically.
⭐ Level 4 — Dynamic Access (Ideal) ▼
Zero Standing Privileges approach embraced. JIT access implemented across all technical staff and the full tech stack. Audit and compliance requirements fully supported. This is the target state for most mature security organizations.

Entitlements Visibility

Three Perspectives

The Admin UI provides real-time visibility into who has access to what. All views show live/active entitlements at the moment of access.

👤 User Entitlement

Path: Principals → Users → [Name] → Entitlements — shows what resources a user can access, how access was granted, duration, and last use. Can revoke directly.

Sample: New employee audit
🔑 Role Entitlement

Path: Principals → Roles → [Name] → Entitlements — shows all resources accessible to a role and last access timestamp.

Sample: Role sprawl audit
🖥️ Resource Entitlement

Path: Resources → [Type] → Entitlements — shows all users/roles with access to a specific resource. Can revoke directly.

Sample: Critical resource audit
🔗

3rd Party Approval

External integrations for access requests and approvals — slides 66–71

Overview

In addition to requesting and approving access via the StrongDM Admin UI, users and approvers can send requests and approvals through third-party integrations. This meets users where they already work, reducing friction.

Available Integrations

Slack

Request access directly from a Slack app or channel. Approvers are notified in Slack and approve within the app.

Enterprise

Microsoft Teams

Allow access requests and approvals through Microsoft Teams channels and bots.

Enterprise

ServiceNow

Manage requests and approvals via ServiceNow ITSM workflows for full change-management integration.

Enterprise

Jira

Manage requests and approvals through Jira tickets for teams already using Jira for work management.

Enterprise

Slack Integration Flow

1

User Requests via Slack

User makes a resource access request directly in the Slack app or a designated channel.

2

Slack Notifies Approver

Slack notifies the Access Workflow Approver designated in StrongDM.

3

Approver Grants Access in Slack

The approver grants entitlement to the user directly within the Slack app — no need to open the StrongDM console.

4

StrongDM Enforces Access

StrongDM enforces the access entitlement. The user receives Just-In-Time access in their StrongDM client.

💻

Device Trust

Endpoint security posture in policy evaluation — slides 72–80

What is Device Trust?
  • A security mode that enables StrongDM to work with endpoint management software to evaluate a device's security posture before granting access.
  • Configured using the policy builder — the "When" clause in a policy can include device trust conditions.
  • Must be explicitly enabled in Settings → Security → Device Trust — policies alone won't activate it.
  • Supported providers include: SentinelOne, CrowdStrike, Microsoft Defender, Duo.

Trust Levels

✅ High Trust

Device passes all security checks. Healthy posture.

context.trust.status == "good"

⚠️ Low Trust

Device has security issues or is in a degraded state.

context.trust.status == "bad"

🔵 Exempt

Device is explicitly excluded from Device Trust requirements.

context.trust.status == "exempt"

❓ Unknown

Device trust status cannot be determined (agent not installed, etc.).

context.trust.status == "unknown"
💡 Policies can be written for devices that match or do not match a trust level using "is" / "is not" conditions in the policy builder.

Enabling Device Trust — Required Steps

1

Setup 3rd Party Integration

Go to Settings → Security → Device Trust. Enable Device Trust and select your provider (e.g., SentinelOne, CrowdStrike).

2

Complete Integration Steps

Install the vendor agent on endpoints and connect the vendor's control plane to StrongDM per the vendor's documentation.

3

Configure StrongDM Policies

Use the policy builder to add Device Trust conditions in the "When" clause (e.g., "Device is High Trust"). The policy editor will show the injected trust status check.

⚠ Note: As of October 2025, StrongDM policies do not warn the administrator that Device Trust must also be enabled in Settings. The policies will exist but have no effect until the setting is turned on.

How Device Trust Works

Data Flow
A

Host sends status to vendor

The Device Trust vendor agent on Host A reports the device's security posture to the vendor control plane.

B

StrongDM queries vendor

The StrongDM control plane queries the vendor control plane for the trust status of all customer hosts.

C

StrongDM enforces policy

Based on the device's trust level and the configured policy, StrongDM grants or denies the host access to the resource via the gateway.

📝

Knowledge Check

Test your understanding of the Access module

0/8

Your Score

Answer the questions below to track your progress.

📋 Question 1 of 8
What are the two required fields when creating a human user in StrongDM?
A Username and password
B Email address and first/last name
C Email address and permission level
D Display name only
✅ Correct! Users require an email and first and last name. The permission level can be set after creation.
❌ Not quite. Users require an email address and first and last name. The permission level can be set later. Note that "display name only" applies to service accounts.
📋 Question 2 of 8
Which permission level can invite and suspend users AND move users into and out of roles, but CANNOT grant administrative access?
A Auditor
B Database Administrator
C Team Leader
D Administrator
✅ Correct! The Team Leader can invite/suspend users and move users in/out of roles — but cannot grant admin access or manage resources.
❌ The answer is Team Leader. Team Leaders can invite/suspend users and manage role membership, but they don't have admin-level privileges.
📋 Question 3 of 8
What is a key difference between a Service Account and a human user in StrongDM?
A Service accounts cannot be added to roles
B Service accounts authenticate with admin tokens and only require a display name
C Service accounts have admin permissions by default
D Service accounts can be given any of the five permission levels
✅ Correct! Service accounts use admin tokens for authentication and only need a display name. They have no admin permissions by default and get resource access through roles.
❌ Service accounts authenticate using admin tokens, only need a display name, and come with no admin permissions by default. They can be added to roles.
📋 Question 4 of 8
Which type of Access Rule automatically adds a newly created resource to a role when that resource matches configured tags?
A Static Rule
B Dynamic Rule
C Policy Rule
D Approval Rule
✅ Correct! Dynamic Rules grant access based on resource type and tags. Resources are automatically added to the role when they are created or modified to match the rule criteria.
❌ Dynamic Rules use resource type and tags to automatically include resources. Static rules require explicit, manual selection of each resource.
📋 Question 5 of 8
What is the maximum permitted duration for access granted through a Workflow request?
A 7 days
B 30 days
C 45 days
D 90 days
✅ Correct! The maximum permitted duration for workflow-based access requests is 45 days.
❌ The maximum permitted duration is 45 days. The default example shown in settings is 30 days, but the platform maximum is 45 days.
📋 Question 6 of 8
When a user is given Standing Access to a resource via a Role's Access Rule, what happens?
A The user must still request access via the Access Catalog each time
B The resource is always visible on the StrongDM client and no catalog request is required
C The access expires after 24 hours automatically
D The user receives a notification to confirm access each session
✅ Correct! Standing Access means the resource is always visible in the StrongDM client and the user does not need to request access through the Catalog each time they need it.
❌ Standing Access means the resource is always visible on the client — no catalog request needed. This is generally discouraged as it increases the attack surface.
📋 Question 7 of 8
Which of the following is NOT a supported 3rd-party integration for access request approvals in StrongDM?
A Slack
B Jira
C GitHub
D ServiceNow
✅ Correct! GitHub is not a supported approval integration. The four supported options are Slack, Microsoft Teams, ServiceNow, and Jira.
❌ GitHub is not a supported integration. StrongDM supports Slack, Microsoft Teams, ServiceNow, and Jira for 3rd party access approvals.
📋 Question 8 of 8
For Device Trust policies to take effect in StrongDM, which configuration step is required BEYOND writing the policy?
A Restart the StrongDM gateway
B Enable the policy in the Policy Library
C Enable Device Trust in Settings → Security
D No additional steps — the policy takes effect automatically
✅ Correct! Device Trust must be explicitly enabled in Settings → Security → Device Trust. Writing the policy alone is not sufficient — StrongDM does not warn you about this requirement in the policy editor.
❌ Beyond writing the policy, you must enable Device Trust in Settings → Security → Device Trust. StrongDM does not currently warn administrators that this step is required.