StrongDM Reviews

I have been using StrongDM for around one year as a client. My main use case for StrongDM is to authenticate my user to get access to the cloud environment.

A specific example of how I use StrongDM to access my cloud environment is that I typically need to access Kubernetes resources, and to do that, I use StrongDM to find the resource inside SDM and connect to it. This is the only use case I have.

The best feature StrongDM offers is that it is easy to integrate with a command line.

The command line integration helps me in my day-to-day work because our DevOps team created a script that automatically connects StrongDM to the correct cloud resource, and it works all the time.

I find the ability to integrate StrongDM via command line and UI that allows me to connect or disconnect specific resources useful and unique; the ease of it stands out for me.

StrongDM has positively impacted my organization by ensuring that every developer has access to cloud resources, which are audited by the organization, allowing us to keep track of who accesses what and control the access.

StrongDM is very stable in my experience.

Regarding StrongDM's scalability, since I am using the StrongDM client that runs on my laptop, I cannot assess much about its scalability, but the response time is very fast, so I assume the scalability is good.

I did not use any different solutions; this is my first time using it in this company.

I am not aware of StrongDM's AI capabilities, including its governance and security.

I don't know about StrongDM's AI capabilities regarding its accuracy and reliability of output since I don't use this feature.

I would say that StrongDM is deployed on-premises in my organization, but I am not certain because I am not involved in those details.

I assess StrongDM's effectiveness in closing breach paths in real time as a very effective way.

I don't have an opinion on the importance of StrongDM's continuous authorization versus periodic checks for my organization.

I am not aware of how StrongDM's credential-less access control integrates with existing vaults and secret managers, but I am getting access to cloud resources and have not explored those features.

I assess StrongDM's ability to unify access across different systems in my organization as effective; we mostly use access to our cloud resources and work with different cloud providers.

I am not involved in the pricing, setup cost, or licensing, as it is managed by different DevOps teams.

I have not interacted with StrongDM's customer support, so I cannot comment on it.

It is difficult for me to give any advice because I am using StrongDM as a regular user, but I am very satisfied. I give StrongDM an overall rating of ten out of ten.

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 was able to replace the combination of different products we previously used for accessing resources on private networks. It provided a simple interface that allowed a few people to manage many resources and securely handle access management needs efficiently.

We primarily used StrongDM for access to resources on private networks like EC2 machines, Kubernetes clusters, and various databases. StrongDM facilitated secure access to these, helped with managing access securely via AWS Secrets Manager, and ensured no passwords were circulated within systems or documentation.

It would be beneficial to have better control and alignment between frequent updates and improved communication regarding possible negative effects on existing customer bases. Also, documentation sometimes lags behind the new features which can be a problem.

I have been using StrongDM for a year and a half.

StrongDM is stable and performs well as expected. We did not encounter stability issues with it.

Our environment was small, so we didn't face any scalability issues. However, based on the architecture and provided features, I believe it can scale both vertically and horizontally if needed.

The technical support is responsive and knowledgeable. We have a ticketing system and didn't need much direct contact with sales engineers because the support handled our needs well.

Positive

We used a client VPN for accessing resources and tools like KeyPass for password management. StrongDM replaced the puzzle of different solutions with one single product, which made managing resources more efficient.

The initial setup was simple due to clear communication and knowledgeable sales engineers who provided necessary help immediately.

Our team consisted of five members, with one person primarily responsible for the system. Two others, including myself, supported the configuration in specific areas like databases and SSH access.

The leadership chose StrongDM after comparative research, which suggests economic benefits. It was mentioned that while the product is rapidly gaining features, it might become cost-prohibitive for wider usage.

I was not part of the evaluation process; another person was running the POC.

The communication is sufficient for implementing StrongDM from scratch. Sales and sales engineers are knowledgeable, providing helpful resources.

I'd rate the solution nine out of ten.

We use it for zero-trust privileged access.

Any time we have a new resource, we can have it automatically picked up and provisioned based on tags to give the right people access to the right resources.

I don't have to think about giving anyone access to anything. All of the logging is handled for us, including for auditing purposes. Looking through the audit logs is not a painful experience. Everything is in one place if we need to go back and look at what happened.

I like the easiness of integrating it with all of our existing data sources. We've also found a few other use cases where we've been able to grant access to third-party resources that require IP-level whitelisting in addition to authentication for remote workers.

We started to use it as a client-side or split tunnel VPN. We are unable to overwrite the endpoints and direct traffic that way, but that's a technical limitation, and I understand why it's there.

I have been using it for about four years. 

We've had a few issues in the past, but those have all been resolved based on interactions with StrongDM and the addition of some new features to the product. For example, the egress routing functionality solved a fair amount of our problems. So, I don't think there are any outstanding issues that we're aware of or have complained about.

I would rate the stability a nine out of ten. The only reason it's not a ten is that there's some automated patching that happens in the background. This was years ago, but we had some issues where that were causing us problems, and we had no way of scheduling it at different times.

We haven't run into any issues with scalability at this point. 

The only issues we've encountered are when you have a very large amount of data sources, we're talking above 2000. Then, the routing algorithm for directing traffic on the StrongDM backend takes a little bit of time to figure out where to route traffic whenever you bring up and down relays or gateways.

We do not have any issues with StrongDM's scalability at the size of our organization right now.

That's how we got some of those feature requests in. We've only contacted support one or two times without a feature request. The support interactions have been minimal because of how good the documentation is.

The initial setup was fairly straightforward as we run everything in Docker. From that side, there wasn't much effort required from StrongDM. However, integrating it into our environment was completely on us.

The licensing is per user per month.  It's pretty close to the same or in line with all of the other pricing for tools that do similar things.

A first-time definitely needs to have some background experience with setting up services to run, but it's no different than onboarding any other service.

My recommendation: Do not change the gateway or relay names, and everything will be great. But that's only really a problem if you deploy within Kubernetes and use a deployment rather than a stateful set.

Overall, I would rate it a nine out of ten.