My main use case for StrongDM is privileged access management and infrastructure access that we cater to, as we were looking for alternatives and solutions to securely control and monitor our access to servers. We have been using different kinds of Kubernetes clusters, databases, cloud infrastructure, and internal applications. Instead of giving direct access to our employees, the idea was a VPN-heavy access with shared keys for better usage. This is how I used it during my Kafka experience about three years ago, and also in my current team at GitLab. In one of those scenarios, my experience with StrongDM while working with Kubernetes in the Kafka team illustrates how we were initially looking for a better way to manage secure access to our infrastructure. Our teams scaled across different environments and regions, primarily Europe, including Sweden and India. Before using StrongDM, we relied on VPN access and manual permission handling, which became difficult to audit and maintain over time as our team grew. Our main use case was centralized privileged access management for Kubernetes clusters. We also considered using it for Linux servers on-premises for the same application but opted out at that time due to limited usage and some internal platforms running on AWS. We aimed for developers and operations teams to get the access they needed without exposing long-lived credentials. StrongDM is instrumental in unifying access across different systems in our organization, alleviating the complications from separate tools. In the Kafka team, we had AWS infrastructure with Kubernetes clusters managing EC2 machines and internal services for different customers referring to our Kafka topics. StrongDM facilitated a centralized approach to access control, audit logging, and temporary authorization. For example, while working on the Kafka platform on EKS, developers and operations teams could utilize a unified access process across various environments, thus streamlining their work.
Iam Engineer at a manufacturing company with 10,001+ employees
Real User
Top 20
Feb 23, 2026
My use case for StrongDM is Privileged Access Management. I have privileged accounts because I am working for the Identity and Access Management team at my company. As an engineer, I have really privileged or elevated accounts for which I need my account onboarded to StrongDM, so I have to regularly use it.
Senior Data Engineer at a non-profit with 1,001-5,000 employees
Real User
Top 10
Oct 29, 2024
I was part of the team managing the infrastructure for a small startup company. We used StrongDM to provide access to cloud private networks, control user access to databases, hosts through SSH, and Kubernetes resources.
StrongDM streamlines secure, password-less access, reducing attack surfaces with its zero trust approach. It integrates smoothly with existing systems supporting IP whitelisting and excels in managing runtime features while offering comprehensive audit logging and seamless resource access.StrongDM provides organizations with enhanced security through features like password rotation and efficient management of access to resources such as EC2 instances, Kubernetes clusters, and databases. Its...
My main use case for StrongDM is privileged access management and infrastructure access that we cater to, as we were looking for alternatives and solutions to securely control and monitor our access to servers. We have been using different kinds of Kubernetes clusters, databases, cloud infrastructure, and internal applications. Instead of giving direct access to our employees, the idea was a VPN-heavy access with shared keys for better usage. This is how I used it during my Kafka experience about three years ago, and also in my current team at GitLab. In one of those scenarios, my experience with StrongDM while working with Kubernetes in the Kafka team illustrates how we were initially looking for a better way to manage secure access to our infrastructure. Our teams scaled across different environments and regions, primarily Europe, including Sweden and India. Before using StrongDM, we relied on VPN access and manual permission handling, which became difficult to audit and maintain over time as our team grew. Our main use case was centralized privileged access management for Kubernetes clusters. We also considered using it for Linux servers on-premises for the same application but opted out at that time due to limited usage and some internal platforms running on AWS. We aimed for developers and operations teams to get the access they needed without exposing long-lived credentials. StrongDM is instrumental in unifying access across different systems in our organization, alleviating the complications from separate tools. In the Kafka team, we had AWS infrastructure with Kubernetes clusters managing EC2 machines and internal services for different customers referring to our Kafka topics. StrongDM facilitated a centralized approach to access control, audit logging, and temporary authorization. For example, while working on the Kafka platform on EKS, developers and operations teams could utilize a unified access process across various environments, thus streamlining their work.
My use case involves a company I'm working in that wants to secure the connectivity between the DevOps team and the backend server in the company.
My use case for StrongDM is Privileged Access Management. I have privileged accounts because I am working for the Identity and Access Management team at my company. As an engineer, I have really privileged or elevated accounts for which I need my account onboarded to StrongDM, so I have to regularly use it.
I was part of the team managing the infrastructure for a small startup company. We used StrongDM to provide access to cloud private networks, control user access to databases, hosts through SSH, and Kubernetes resources.
We use it for zero-trust privileged access.