The purpose is to ensure that privileged users do not know their own passwords.

Our organization is more secure, and we are confident that the privileged users who are using the systems are actually the users they claim to be due to two-factor authentication because we are using two-factor authentication in One Identity Safeguard.

It is easy for us to revoke access as well. Previously, we did not know who had access to a system, but now, we can see what access is currently open to systems directly from one single pane of glass, allowing us to revoke that access if necessary. We have limited the possibilities for malicious actions and have made it safer for our users when they are using privileged accounts. They only have privileged access when using that account, but they do not know the password. While nothing is 100% secure, it is more difficult to misuse that privileged account. In the past, IT administrators could log in with domain administrator access on their normal PCs, which made everything work without needing to elevate their rights. Now they cannot do that because they no longer know the password. They are required to go through One Identity Safeguard to elevate their rights.

In the beginning, we had some pushback from the administrators because they could not log in directly to a server or a system. They have to go through the web interface and log in. We had to educate them and put in a little bit of effort. We made them aware that we were also taking risks away from them so that nobody could misuse their credentials. People become administrators only when they want to use the system. When they are done using it, the account is disabled, and administrative privileges are revoked.

Previously, we had external consultants who had accounts, but we did not necessarily know when they were using the account. We now know because we have put up an approval flow. The external company needs to request access for a user, they need to call us and provide a ticket number. We then can approve it. We can also approve them for a specific duration, such as two hours. After that, the user needs to request access again and he needs to be approved. We now know when external people are using our systems. All the external privileged users are now disabled, which were not disabled before because we did not know when they needed to use the system. They did not have a normal user and a privileged account. They just had one user who could log in to the systems. Now, they need to have a normal user that can log in to One Identity Safeguard, and then the privileged account will only be enabled when we have approved the access to the system. The normal user does not have any access besides logging in to One Identity Safeguard. So, there was some pushback because administrators had to raise a ticket. We also tightened up our ticket system to ensure that IT does not do any work unless there is a ticket.

Our management can see that our security posture has greatly improved because, on a normal day, we do not have any privileged users who are enabled, so it is very difficult to elevate access to various systems. If they are not active, privileged access is revoked, and there is no access without a ticket.

We use the transparent mode feature for privileged sessions. It is very easy because it just goes through the Safeguard session. That session is used as a proxy now, so we can limit our end-user's access to server assets. Only the session has access to the servers, so we can do micro-segmentation in a different way now on our network.

The transparent mode is rather seamless because the user does not see this Safeguard session. They only see the Safeguard for privileged passwords because that is the interface that is there, a single pane of glass. When they request access to an IDP session or server, they see a different background because it goes through the process that does the recording but the users do not see that.

The transparent mode helps to monitor privileged accounts which we could not do before.

We have integrated it with test and development. They do not know the password either. Previously, they were the kings of their kingdom, whereas now, they are just users of their kingdom. They also now have to go through One Identity Safeguard.

If a privileged user does something malicious or suspicious, with session recordings, we can see what happened. We can see this person authenticated with two factors when he logged into One Identity Safeguard. If it was not something malicious, we can use this information to become better so that the issue will not happen again.

The implementation time was quick. It was basically up and running within a week.

I like the features that allow you to rotate your password, give you access to an RDP session without knowing your password, and record sessions. This is helpful for external people coming in, as we can review what they have been doing and use the recordings for training purposes. For example, if I want to upgrade a system that an external consultant did, these recordings can help identify issues. We can set different keywords to cut off a session if something malicious is detected. We can prevent a malicious action.

We use it to log in to various systems such as Linux and Windows, which is very convenient. There is also a personal vault for browser use, allowing us to save credentials for business-related websites securely. If a user leaves the company, I can assign that vault to another user. I can share credentials, save files within One Identity Safeguard, and ensure that certificates and license numbers are securely stored. I can see who has access to the files. I can save license numbers and license files in One Identity Safeguard, so I know where they are saved. I can also give access only to those who need it, as opposed to them residing on a file share or OneDrive, where access is not as transparent.

From a management point of view, it would be beneficial if One Identity Safeguard Privilege Password and One Identity Safeguard Privilege Session had a more similar interface. Also, if Privilege Session pushed more data to Safeguard Privilege Password, an admin would only need to log in to one place. They could then see the sessions and everything happening, even if it is running on a separate appliance. Why should I log into Safeguard for Privilege Session separately when it has been requested through the Privilege Password appliance? It would be advantageous if it was seen as one unified box, even though they are different. This is the improvement I would like to see.

I have used the solution for less than a year.

It is stable. I would rate it a nine out of ten for stability.

It is very scalable. I would rate it a nine out of ten for scalability.

Our clients are medium to large enterprises.

Most clients use regular support, but some clients use premium support.

In previous work, I have used CyberArk and Secret Server. One Identity Safeguard is way cheaper, intuitive, and easier to use. Its implementation costs are much lower than CyberArk.

It is on par with Secret Server, but you do not have session recordings. You just have the privileged passwords and rotation features. You need to harden the Windows because it was installed on Windows, whereas One Identity Safeguard is already a hardened appliance. One Identity Safeguard is more secure than Secret Server. However, I used Secret Server a couple of years ago. It has probably matured now.

We are using the virtual appliance because we already have a virtual environment. The only on-prem setup we have are the physical servers that run a hypervisor. We like to have everything virtual. We can also secure a virtual appliance in a different way compared to the physical appliance. With a physical appliance, if something happens, we have to get hold of the vendor and sort out how fast they can ship a replacement, whereas we can deploy a virtual appliance instantly and get it up and running if there is a problem.

One Identity Safeguard Privilege Password is rather straightforward, rating it as an eight out of ten. Privilege Session is more like a six out of ten, being a bit more complex if I want to use all the features. However, if I just want to use it in Transparent mode, it is easier.

In total, it takes less than two weeks, depending on the landscape. Some preparation, like obtaining certificates and securing a backup share, is required first. I do require input from others to implement it within two weeks. If I can gather all the necessary data and access, the implementation becomes more straightforward.

The deployment was disruptive in a way for the privileged users because they now needed to log in through the web interface, whereas previously, they could log in directly. There are more or different steps. Instead of clicking directly on an asset they want to log in to, they need to log in to a different web page and request access. There are a few more mouse clicks than before, but we now have a better security posture of our environment.

To manage and do the implementation, you need to know certain things. You can also use a trusted partner for implementation. If you do not change anything in the system or do not want to do other connection types, you do not need that much training. You need to be aware of what you should look for. A three-day workshop with a partner would be sufficient. For end-users who need to use the system, a two-hour training would be enough.

We have two One Identity Safeguard specialists in our organization.

It is more expensive than Secret Server but way less expensive than CyberArk. As a customer, I would like the pricing to be lower, but it has a good price point.

There is no reason not to recommend it. Everyone should have a PAM solution to prevent privileged user damage and mitigate risks like stolen passwords or insecure storage. If you want to ensure recordings of activities, be it from external people or highly privileged users, then this is essential. This reduces the risk of malicious insiders. You cannot always prevent it, but having recordings allows you to pinpoint activities before a system failure. You can consider having SPA analytics for additional security. We do not have that yet because of the price, but we might add it later.

I would rate One Identity Safeguard a nine out of ten.

We are using it internally because I work in a consultancy company. I use it both for our internal privileged accounts. We have different systems like Google Cloud, some internal servers, data centers, etc. To secure those privileged accounts, like the administrator accounts and root accounts, I use One Identity Safeguard to rotate passwords, authorize sessions, and more. The second use case is that we also implement One Identity Safeguard for different customers.

The most significant benefit is that in the past, we saved passwords in Notepad files or Excel files. Now, we do not, and we have more security. We do not have saved passwords or plain text passwords in different places within the organization. That is probably the most significant benefit regarding security.

In terms of integrations, we have basic integrations for our Windows and Unix servers. We do the transparent connection for LDP and SSH, and that is all. The integration is simple overall for this kind of connection. However, if we want to integrate different consoles or different systems, it is a bit more complex because it is not so much out of the box, but for our current systems, it was very easy.

End-users require just a couple of training sessions and some documentation, and they are ready to go. They can start using the tool as an end user in a week or less. Managers or administrators require a technical specialist training workshop, which is a full-week course. After that, they need one to three months of training with laboratories and documentation. They would need at least three months to work well with the platform.

There is ease of implementation. Compared to other PAM solutions, it is easy to implement and use from an administrator's point of view. That is the most important benefit. It is very simple to implement and use.

We should be able to create customized connectors in a better way. For ad hoc or special use cases, I sometimes find we have limitations. Improving the way we develop new connectors for non-typical systems would be beneficial.

Another area for improvement could be the threat detection capabilities, like those seen in other PAM vendors. The ability to detect strange behaviors during a transparent connection or detect risky sessions and respond immediately would also be a good improvement.

We have had good feedback about One Identity Safeguard, but for LDP and SSH sessions, when we have to connect to a different console, such as a web console, the customers sometimes complain about the efficiency of the sessions. It takes extra time, and the user experience is not so good when you are using different connectors than normal ones.

I have been using it since 2020, so about five years now.

I would rate it a nine out of ten for stability. It is like a black box. It is an appliance. It is difficult for things to go wrong.

It is scalable. I would rate it a nine out of ten for scalability. It is easy if you need to implement resources.

In our organization, we have 15-20 people working with this solution. Our clients are medium enterprises.

We use their partner support. It is usually okay. When I have day-to-day incidents and problems, the response is good enough in terms of time and quality. However, with complex problems, the response is not as fast.

I have experience with CyberArk. I would say CyberArk is a more complex solution in terms of implementation, day-to-day administration, and maintenance. It is more complex and difficult in some ways, but for advanced or difficult connectors, CyberArk has more capabilities to develop customized connectors. It can cover more special or ad hoc use cases, but at the price of more complexity overall.

One Identity Safeguard is at the top level because it covers almost all the general PAM use cases. It covers password rotation, transparent connections, threat detection, isolation, etc. It can cover the needs of most organizations. We have also been able to better cover more complex use cases with One Identity Safeguard than with other PAM solutions.

We have a virtual appliance. We chose the virtual appliance because we were already using a virtual machine infrastructure, so it was easy for us. Our implementation is not complex. We do not have a lot of regulations. It does not matter if we lose connectivity. It is not the end of the world, so for us, a virtual appliance was good enough. It was easier to implement. We do not need to rely on physical devices.

To implement and be functional, it takes days, probably one week, but when I go to a customer and need to do all the configuration and integrate systems, it can take a couple of months overall. It takes days to implement, but configuring and integrating everything can take some months.

In terms of maintenance, it requires less maintenance compared to other PAM solutions. There is not much maintenance regarding the infrastructure. They are, black boxes or appliances, but they do require maintenance in terms of day-to-day configuration, permissions, and connectors.

We did not cover many use cases regarding efficiency and cost reduction, so we did not see ROI directly. However, being more secure makes it less probable that we will suffer an attack or data loss, which is a cost reduction, but I did not see much time reduction. There is about 10% savings.

It is cheaper than CyberArk. Its price is fair.

We use the solution’s transparent mode feature for privileged sessions. There was an impact on the users with the roll-out of this feature because we changed the way people were connecting to systems and faced some problems like communication and networking problems. People did not have the correct permissions at the time. That was a bit of a problem, but we now have a seamless integration. It took us a couple of months to have everything working.

I will recommend it to some customers because it is easy to deploy, administer, and configure. The price is fair. The scalability is also good.

Overall, I would rate it an eight out of ten. It covers pretty much all use cases, but sometimes there is a lack of customization.

We use it to handle secure access to our Windows and Linux servers and also to manage some of our user accounts. This includes password rotation, JIT, and disabling accounts when they are not in use.

We use their physical appliance.

I look after the backend, but I am also a user of it. In general, users do not love it because there are extra steps to what they are used to, but it is an intuitive service. The approval workflows work particularly well with their integration into Teams. From a backend point of view, it is not too bad. There are a few places where the interface could be slightly different, but mostly, it is fairly intuitive.

The Approval Anywhere feature provides an approval process. We use it for our external contractors. It is nice and easy once things are set up from their point of view, and it provides the university with an additional layer or multiple layers of security, which we did not have before.

We have integrated it with Identity Manager, which is another One Identity product. We have not integrated it with anything else. We thought about integrating it with ServiceNow to have a one-stop shop from ServiceNow to make API calls and requests from there. However, we wanted to keep things a bit simpler at this point. The interface is pretty nice. Asking users to go via the Safeguard method works well.

It provides secure and centralized access to both on-prem and cloud servers, which we did not have before. Previously, there were myriad ways to access our servers, so this centralizing feature is beneficial.

The auditing and approval mechanisms are features we did not have before and are greatly appreciated.

I do not have any integrations at the moment, and I also do not use the API to automate this. I have to set up user accounts, then privilege accounts, and then linked accounts, and do some association there. There are many steps. We are still in the onboarding phase, and it seems very manual. Ideally, a single interface to integrate all these processes would be useful.

A couple of missing features that I have seen are about to come out, and I am happy they are addressing customer feedback with exactly what I wanted.

I have used the solution for probably about 18 months to 2 years.

We have not had any issues with the core product itself, but there is an add-on called SCALUS, which is quite critical to the user experience, and that does not work. They have been having issues with that for quite a long time, like months. That is not great at all.

Scalability is fine. We have a cluster of SPPs and a cluster of SPSs, and we can add a node to that cluster without much fuss. We did it on one of the clusters, so it is all good.

They are quick to acknowledge a call or case, possibly due to SLA requirements. Overall, it is a hit-and-miss. Sometimes, I get a very helpful response and they address issues on a call. Other times, I am politely informed they cannot help.

I did not use any similar solution previously.

It was a little bit of stop-and-start. Quite a few people were involved, but we had One Identity's professional service's help as well. We had something working within a week.

It does require maintenance. It is not a SaaS service. It is not a hosted service, so I have to resolve any issues that come along. I have to deal with any feature enhancements and patching.

We had One Identity's professional service. We had probably four people from our side.

We bought their other products, so it was not that expensive. It is one of those where the more you buy, the cheaper it is.

I would rate One Identity Safeguard an eight out of ten.

Our customer is a public service organization with about 800 privileged accounts and 8,000 functional accounts. The client already has a relatively unadvanced identity management implementation. It's a request-based identity management solution. What we're doing now is getting better control of the privileged accounts and getting rid of the old technology.

The end users don't know of an alternative. They are still subject to identity management through what is quite a large, manual process instead of process automation. For instance, the users do not have a self-service port where they can automatically get privileges they don't have today. Everything goes via the ITSM manual control workflow.

It's the manual processing our client currently has that is what we are thinking of improving. The installation was not set up by my team, but our job is to focus on the most sensitive information assets and secure insights into how service and other infrastructure are managed through privileged accounts. After that, we will work on simplifying the everyday user experience.

We work with just the physical appliances. It wasn't my decision. It was what the client already had. Regarding the form factor, just put it in a rack and it works. It's not an issue.

We're introducing the solution's transparent mode for privileged sessions. This is part of what the client hasn't used before. It will simplify their administrative situation greatly. So far, the rollout of this feature has been a seamless process, but we're still in the midst of rolling it out. The benefits will be on the risk side.

Right now, the way accounts are managed, you don't necessarily know who is using an account. There's a shared admin account, and that's not a good thing. And those accounts are shared in wallets by several people. One of the real benefits of safeguarding here is that the client will have an absolute audit of who is using an administrative interface, whether it's server or network.

The identity discovery is good, and the performance is pretty good value.

Something for One Identity to look at is having integration guidelines for how to logically group accounts. This is always something you need people to do. It would be especially helpful when you have thousands of servers, and within each and every one there are between two and five admin accounts.

I have been working with One Identity Safeguard for about six years. I'm a consultant, and I work with various technologies. When One Identity came out with it about six years ago, I was one of the first to engage with it.

We haven't had any issues with the stability of Safeguard.

It's scalable, at least in this environment. I haven't worked in a very large-scale environment with this technology. At least you don't have bottlenecks in your operating system or external virtualization. For this organization with 10,000 people, it seems to be working.

We have a specialist who is super-deep in One Identity and has done a couple of the most complex installations of the solution in Norway. He is better than any support organization you could come up with. He's really special.

Setting it up is not complex. The complex bit is migrating from the various wallet types into Safeguard because users have to be trained in a new methodology of how to use Safeguard. We need to shut down the old access as Safeguard becomes the only way in. That is the tricky part. It's not Safeguard in and of itself which is tricky. On the contrary, Safeguard is simple to use.

We haven't finished the deployment yet, but the plan is to do it over two months. We have six people on our team who are involved with the client.

We have created the training material, and each user gets online training, documentation, and a facilitated meeting. Each user gets a full eight hours of training. The training is distributed over a couple of weeks.

We've been able to manage disruption so far. That is because we provide the users with a semi-automatic tool that makes them responsible for transferring their own accounts from the wallet to Safeguard instead of us doing it for them. And that gives the end user the control they need to not mess up their own secrets. They have access and all the means to make it as non-disruptive for them as possible. I wouldn't call it a custom build, but we've created a process that they have to follow. It partly gives them something that extracts all the secrets from the current wallet and populates them into a Safeguard. But they have to do it themselves and validate that they have done it.

Letting the users have control over their own migration is a key part of the strategy because big bangs usually end up with a big bang. What I mean is that you can end with a big disaster if the users don't feel that they are able to use Safeguard on time, or if they don't know whether their accounts are still in the old process or the new one. The key strategy is to not rearrange privileged groups before the migration. Even though most admin users have too much access, we're not fixing that right now. We will do that after the migration. We want the migration process to be as smooth as possible.

It's not difficult to maintain. Compared to the One Identity software, there is less maintenance. That's why one chooses appliances, to have less maintenance. Just give it power and it works.

Because we're talking about a digital world now, very few organizations question the need for some sort of identity management solution. One Identity makes sense for organizations that have some of their own infrastructure and cannot go fully to the cloud. For organizations that have everything in Azure cloud, it may not make sense to use this solution. For an organization like that, One Identity does not provide any ROI. But for any organization with more than 10,000 people and its own local infrastructure, One Identity makes sense and provides a good ROI.

They have comparable pricing. All identity products are essentially priced in a similar way. It's a per-user base. Usually, they start at one price, and when you start pricing the competition, you typically get a bit of a discount or more favorable payment terms. For example, you might not have to pay until you've enrolled all the users. You don't have to pay upfront for all people in the organization until they've been enrolled.

There are also integration costs and migration costs. That's the big one.

One Identity is the simplest to work with and has the best discovery function. There's very little kludge in the software. It's probably the quickest for going from zero to operational of all the alternatives in the marketplace.

What it lacks, compared to some, is specific SAP integration for clients that have that. Our current client doesn't have SAP, so it's not an issue for them. And potentially, SailPoint has more pre-made connectors. That means if you have a large number of systems you want to provision into, then SailPoint is the way to go.

As for privileged access management, if you have an abnormal number of servers—more than 10,000—a whole lot of network elements, and several types of platforms, you might have to go for CyberArk.

But One Identity is a very good package for most organizations. It's one of the simplest to use. CyberArk is the leader in the marketplace, but typically, it is too complex and too big for Norwegian organizations. One Identity PAM has the simplicity to fit Norwegian businesses. It has enough features for any medium-sized business under 50,000 people and under 10,000 servers. For those organizations, One Identity is a safe pick.

I would absolutely recommend One Identity.

Very large organizations with complex technologies and a very large number of devices can consider other options. But One Identity has a very good suite of technologies.

We introduce One Identity Safeguard to customers, primarily Italian customers who need to partner with solutions that protect their target resources.

What I like about One Identity Safeguard is its interface, which is easy to understand, even for people new to the product. I also like that the solution collects data without any access to the machine, plus it has a feature that lets people explore access to machines within a network.

Regarding the usability and functionality of One Identity Safeguard, the most common feedback I receive from users is that the solution is easy to use and can easily move data.

I also like that One Identity Safeguard lets you configure the maximum number of connections to the target, a configuration I didn't find in its competitor.

My customers use the transparent mode for privileged sessions in One Identity Safeguard, and it is easy to use, though it may be more difficult to configure. I haven't received any customer complaints about that feature, so it's not that difficult to use.

To start using One Identity Safeguard in terms of training for people who manage the solution and the end-users, my colleague and I took a course from One Identity. That training was enough for the basic features, but for some other features, my colleague and I had to create some tickets, though he and I know the database and processes. For users, it is easy because my company provides them with a two-page resource manual with screenshots. Then, I spent some time with the managers to show how One Identity Safeguard works, which is very easy because I've used the solution before.

The analytics interface of One Identity Safeguard is also easy to understand.

A feature I found in a competitor would make One Identity Safeguard better, and that is the ability to load balance the traffic in the target. For example, in two machines with some applications, I would like to balance traffic between the two machines with the help of One Identity Safeguard. It would be great if the solution allowed users to add some applications to a cluster and balance the traffic between the applications.

I've been working with One Identity Safeguard for customers for six months.

Stability-wise, One Identity Safeguard is okay. It's been running for almost one year, and there's no problem with its stability, so, in terms of stability, it's a seven out of ten for me.

The scalability, including the clustering for One Identity Safeguard, could be improved. It is fair right now, scalability-wise, and from an engineering perspective, it may not be as easy to do that because the appliance would have to be encrypted, and there's a security requirement. Still, it would be nicer if scalability could be improved in One Identity Safeguard.

Support for One Identity Safeguard could be improved because sometimes the support team doesn't have an answer or solution for some bugs. Support-wise, it's an eight out of ten for me.

I used a different solution previously, but One Identity Safeguard could limit the maximum number of connections to a target. The other solution, on the other hand, could not do that but has a load-balancing feature.

My company deploys One Identity Safeguard for customers, and I found the process easy.

My customers use the One Identity Safeguard virtual appliances.

I have not used the Cloud Assistant feature of the solution.

I have not used the Remote Access feature for privileged users in One Identity Safeguard.

My company does not integrate the solution with any other parts of the business, such as development, operations, and RPA. It was just tested but not rolled out in production.

In terms of how the deployment of One Identity Safeguard affects privileged users may be a complex question because the customer didn't have a previous infrastructure. The customer is now building the infrastructure, so it's a dynamic environment. The customer doesn't have an old environment.

I'm a One Identity Safeguard integrator, and my company also resells it.

Regarding maintenance, usually, it's not required. Still, sometimes a user could complain about not being able to access passwords in One Identity Safeguard or that there is some misconfiguration I need to analyze, and in the end, the issue is with the target appliance and not One Identity Safeguard.

My rating for One Identity Safeguard is eight out of ten overall.

We use the virtual appliance of One Identity Safeguard to enhance security when external support is logged into our internal network. This is because it is the riskiest situation when an external company logs into servers to provide support. We want to increase security and monitoring to minimize risk. We have better monitoring tools to help us achieve this.

Managing the remote access for privileged users feature is moderately difficult.

We currently use only one feature, which is privileged access to remote desktop servers with rotating passwords for privileged accounts. This is the main feature we use, and it typically disconnects external users from the system before giving them a different user to use for logging in. We have to use the Safeguard session in an integrated separate session or with the exact name available to record the sessions.

The GUI has room for improvement because it is confusing and cumbersome.

I have been using One Identity Safeguard for two months.

One Identity Safeguard is stable and provides great performance.

The technical support varies depending on who is assigned to our ticket.

The initial setup was complex, and we had to put it behind a firewall for security. This made it difficult to open the ports needed to set up the connections. It was a time-consuming process, and we had to work with the integrator to complete it. It took several days of work, but the tool is powerful and worth the effort to set up.

Three people were required for the deployment.

We used an integrator to help implement One Identity Safeguard. The integrator was good. He was able to train our people to deploy the solution.

I would rate One Identity Safeguard eight out of ten.

A moderate amount of training was required for our people to start using One Identity Safeguard.

We have up to five people using the solution.

The only maintenance required is for patching.

One Identity Safeguard is a great product once we become familiar with it. The GUI takes some getting used to.

I work for a bank, and we use Safeguard to manage access to our Internet banking services. We use Safeguard for two things: identity and access management and detection recording. We have our services onboarded on SysTrack doing RDP directly to the servers or station, and we use virtual appliances for collection. The solution covers around 150 users at this organization.

I like Safeguard's snapshot feature that enables us to review the last time an application was opened and by whom. If there are any issues, we can look behind the scenes to see what has been done. We can suspend a user's access or close off a server.

We've had issues managing accounts and access to some data saved on the servers. Accounts are granted a new working certificate daily. We have an account to do it on APIs online and sync it with that. If the path changes at some point or someone changes the password, I don't know if it's from the Active Directory or what.

I have used Safeguard for one year.

Safeguard is stable.

It's scalable, depending on the solution case. I don't know if it's domain-based because it was not restricted. We're gradually moving to the Azure cloud.

One Identity support is okay.

Deploying Safeguard was straightforward.

I rate One Identity Safeguard eight out of 10.

We are using One Identity Safeguard for our data protection.

We are utilizing the virtual appliance solution because it is slightly more cost-effective and allows us to manage it remotely.

Secure Remote Access feature is being utilized by non-technical users, primarily for multi-factor authentications. We are implementing MFA; however, some users in our branch are not yet connected. Consequently, we are resorting to using a VPN in our access control measures. At times, we have also employed remote branches for auditing and monitoring any potentially suspicious activities. Our endpoint security is consistently updated and ensures encryption for all the internet services we utilize.

It is important that the Secure Remote Access feature does not rely on a VPN. One Identity Safeguard provides us with the ability to manage access to the system network and data from our remote branches through the Secure Remote Access feature, ensuring a secure and confidential connection on the backend.

We have integrated One Identity Safeguard with our DevOps processes to assist in managing the parameters. Prior to the integration, we used to wait for certain automation related to security, either already completed or sometimes people would proceed without reporting. However, after the implementation, it has proven to be highly effective for security testing through automation at various stages, particularly in the pipeline, and for conducting critical analysis. This has significantly improved our understanding.

There are numerous valuable data protection features, including the content and information that offer us more scalable protection as needed.

We also have access to immediate support for situations that we are unable to handle.

Some of our users find the functionality a bit complex, and it could be made more user-friendly.

The integration of automation, security monitoring, and secure configuration can be enhanced. We can integrate these elements using Ansible or any other necessary tools. This would be advantageous in terms of time and effort saved during implementation, especially when dealing with merged branches. This approach will guarantee that the code is approved, tested, and verified, potentially resulting in substantial time savings.

I have been using One Identity Safeguard for ten years.

Premier Support is valuable because it enables us to receive prompt assistance whenever we encounter any type of issue.

The time to deploy varies from a few minutes to several hours depending on the scenario.

We integrate security tests into our CI/CD pipeline for privileged users to ensure that these users are not affected.

We also assessed CyberArk, which is a more robust Privileged Access Management solution compared to One Identity Safeguard. However, it comes with a significantly higher cost.

I would rate One Identity Safeguard an eight out of ten.

We conducted training sessions for all employees and managers in our company. The training was tailored to each person's skills in order to streamline the training process and facilitate the deployment procedures.

We primarily use the solution to manage identities.

It's a good solution for managing identities under OneFile for authorization.

So far, the useability and functionality are very good.

We use the Approval Anywhere, or cloud assistant feature and it is great. It enables us to add an extra layer of security for critical passwords without adding time to the approval process.

The secure remote access feature for privileged users has been useful as well. We've had moderate success with it. It doesn't apply to some reference levels. We do like that it does not make us use a VPN. It gives us more flexibility. We can push out to mobile users a bit easier.

We do have some support issues sometimes around user authorization rights and onboarding. Typically it's on the user's end where there are issues. We point them back to the instructions.

The big issue I have with the solution is the lack of timely updates. We have feature requests and would like to see the turnaround times on those features to be faster.

The pricing could always be better.

I've used the product for five or six years.

The solution has been stable.

The scalability of the solution is good. It was one of the reasons why we chose it. We needed something to scale with our customers. So far, we've been happy with its capabilities.

I haven't had issues with support so far. We do not use the vendor's premier support.

The whole effort, in terms of initial setup, took a couple of weeks. There is a learning curve associated with the process. My end-user took an hours-long course and my administrators went to training for about two to three days.

The pricing is okay compared to other products we looked at.

We looked at a couple of other solutions from CyberArk. The useability of this solution is better.

We're partners. We've resold the solution in the past, although we aren't doing so now. We're not active resellers. It's more opportunity-based.

We are using the most up-to-date version of the solution.

While we have yet to integrate the solution with other parts of our business, we are looking to integrate it in the future with DevOps. We're in the planning phase of that.

The flexibility and integration process is seamless. I've definitely had worse experiences. The resources we had weren't very experienced and we got through everything with very few headaches. From a security and productivity standpoint, it's good.

I'd rate the product eight out of ten.

Our administrators mainly use it to protect their different packages and access secrets through Safeguard, either by checking out credentials, using encrypted sessions, or utilizing the product's API.

We are using a virtual appliance deployed in the cloud and on-premises.

The centralized storage of secrets and credentials prevents them from spreading throughout the organization. We know who has control over them and who has access. Before Safeguard, there might have been a few Post-Its stuck on screens, which isn't secure.

We have also gained visibility into the use of privileged access. It's way easier for us to see what, when, how, where, and why. We now have a good way to provide justification for doing things, instead of relying upon people to remember. Now we can demand that.

And the rich level of logging, including visual logs with video recordings of sessions, has given us more confidence in our security posture, where we have onboarded the system.

The whole product solves the privileged access management challenge for our company. We have a secure tunnel, a secure session manager, and automatic logging of sessions, which is good for forensic purposes. We have a rich level of logs and can trace what happened on which machine and see who did what.

Feedback from our users on the usability is positive regarding the UI experience. Instead of keeping their credentials on them somewhere, they now have a very easy-to-use portal with a nice GUI. There has been some feedback from people saying, "Couldn't it do this," or "Now I have to do that". But that's basically change management and not a real problem. There is some getting used to the UI, but I think the UI is very easy to understand and to use. The usability is very good and that's one of the main ways Safeguard stands out from the competition.

Safeguard, the way I see it, has two different parts: vaulting and sessions. And those two are running on different platforms. The vault itself is a locked-down Windows box, which isn't really causing any trouble. The session part is on a Linux box. They sell them separately, but together, they need to be more unified, at least from a UI perspective when you're using it as an administrator. There are some "legacy-level" menus and ways of using it that I don't really appreciate.

We are using it completely web-based, not through a fat client. The browser experience of administrating SPS (Safeguard for Privileged Sessions) needs a lot of attention from an administrative perspective to make it easier. The readability of the system itself is quite poor.

A user never really engages with that part. It's only the administrator, and maybe an auditor, who are subjected to using those menus and tools.

So the SPS could be a lot easier to administrate and the parts should be unified, from a design perspective, so that I can recognize the systems as being part of the same package. They feel like they have been forced together.

We started implementing One Identity Safeguard about one and a half years ago.

It's very robust. We haven't had any issues with Safeguard's stability.

We have done a few things that have "annoyed" it, but it has always come back. We tried to upgrade one of the session nodes, and we did it in the wrong order, but it pulled through anyway. That was quite impressive. If you deploy it on virtual servers as we have, with a virtual appliance, if you have that under control, Safeguard itself is not an issue, at least for the time being.

I believe we may have done a bigger deployment than we actually need. We were advised to use a node and another node to have a little bit of a cluster function. We went even bigger than that, so we are using the biggest version of what they recommend.

But I don't see scalability as an issue. I don't think it's something that Safeguard does particularly worse or better than anyone else. It's easy to deploy another node for the same function that you already have. Or if you want to replace something that doesn't work the way you want it to, you can switch it. It is very scalable. We haven't touched the limits of what it's capable of and I don't think we ever will.

We have about 150 users at the moment.

I don't think we are using One Identity's Premier Support. We are using some level of support from them, but that support is handled by our partner. If we raise an issue, our partner coordinates between us and One Identity.

We did not have a previous solution.

There are different kinds of solutions that Microsoft provides, called PIM, instead of PAM. It's for cloud-based roles and privileged access. We were using that before Safeguard and we are still using it for that specific use case. But we didn't have another privileged access management solution, other than human administrators. It was surely needed.

Just getting a PAM solution is many steps better than what we had before.

The initial setup wasn't really complex. We are using the virtual client, so it was fairly easy. We didn't really have to do any setup. We just had to start a virtual machine and run the appliance, following their documentation, which is very good. It was quite easy.

We are utilizing a partner for getting started so I didn't find it hard to start.

Among the things that you need to look out for, and this applies to every product, is how it fits into the network that you are going to put it in. There are a lot of specific ports that it needs to be accessed through, and you should probably keep it as locked down as possible because this system shouldn't be exposed to any other environment. That is a hard task to complete. That is not a fault of the product itself, but it comes with that can of worms.

And, of course, you have the certificate questions, the different certificates that it needs to validate sessions and keep them secure. That's quite tricky as well. Again, it's not really a Safeguard issue, but your organization needs to know that these are considerations when you start.

Our technical go-live with the solution took three or four months. That was mostly related to our network issues and finding all the different ports that needed to be opened and closed. But starting the application and using it, running the GUI itself, is a matter of days. It depends on your organization and how well-equipped it is for this type of change.

We didn't force any big changes. We were debating if we should onboard our current privileged users and then force them, from day one, to use the system. Instead, we did a side-by-side solution where we started alternative users on it and then told our previous users to use it instead. And if that, somehow, was not satisfactory, they could still use their old account to complete the work. That way, we didn't jeopardize production. Every time we received feedback such as, "I need to use my old account because I cannot use this new Safeguard version," we needed to adapt and improve.

Once there were no more complaints, we started shutting down the old users who had not been onboarded to Safeguard. We didn't want to bring major change in an instant. We led them to the Safeguard solution and let them try it out, give us feedback. Generally, they found it easier to use Safeguard compared to their old ways and they started preferring it. When we saw we had no risks left, we disabled the accounts that they were using before.

In terms of training, for the admins we had a five-day course, which covered the basics. I did not receive that course, but I didn't really need it. The right partner can explain enough to you, in small sessions, about what you need to accomplish. And the user experience itself is so intuitive that you understand what you're doing. And their documentation is very easy to search and use. You don't really need much training. Of course, you need to understand how you affect different systems if you connect them to Safeguard but that depends more on your own organization than on what Safeguard is.

End-users just need a basic introduction to tell them, "Please go here, use this." They log in with known credentials and the same password as everything is under MFA. It's nothing new to them. And the user experience is very simple for them to check out the privileges that they need for the moment that they need them. That's quite self-explanatory.

We had a partner called Intragen International that helped us understand the best practices for deployment and what not to do. We had them as an adviser, but we performed every step in-house. They didn't have any access to our system. They were more of an adviser.

I believe we have a five-year deal in place, and it's an all-you-can-eat license. It's not user-based.

We also pay our implementation partner. We have a support deal set up with them, so that's a cost we have added on. But it's not applied to the Safeguard bill. The advisory role that they provide us is something that we decided we need.

We looked at the product from BeyondTrust. And we looked at CyberArk because that's what you need to do when you start this process. We also looked at a couple of other products, market leaders, according to review sites. But we mainly looked at CyberArk.

We, as an organization, realized quite early that privileged management access is hard. There were solutions that, like CyberArk, were very advanced and had huge legacy support with every type of system known to man. That was very interesting because you never know what you might have. But when we looked into CyberArk, we also felt that the system was a leader because they were first, not because they were the best. It seemed to be quite complex to deploy. Knowing our limits, we felt the Safeguard solution was more of a fit for us, and the user experience was way more intuitive than the CyberArk version.

Looking at the other competitors, they were more leaning toward a cloud-based solution or were going that way. Of course, we are always trying to get to the cloud—you never get there, but you always talk about it—and we felt that if we were going to keep all of the secrets of the company anywhere other than in our own environment, it would almost be irresponsible to have it on a vendor that always puts things in the cloud. That essentially meant we wouldn't know where they would be.

By deploying it ourselves, at least we know where the keys to the kingdom are, and we control them. The other vendors were not selected because they were too cloud-oriented for such an important part of our company. We needed to keep it ourselves and keep the responsibility in-house, and not put it anywhere else.

Safeguard had the same philosophy, allowing us to do a virtual appliance that we deployed ourselves in our own data centers, keeping every bit of information inside our walls instead of putting it on the cloud. With CyberArk, we could do that as well, but it sure seemed way harder, so we skipped that.

To prepare for Safeguard you need to know your network, and if you think you do, you don't. You need to have network personnel available during the deployment to maintain tempo in the deployment. If you don't have access to people who are able to change things in the firewalls and the like, you will stall.

The documentation, what you need to do, is very clear, but every network is different, and you really need to know where you put your Safeguard solution and that you have access to people that can help you fit it into your existing network. That's a very important step.

You also need to know what "high privilege" means to you because it's not defined in Wikipedia. You cannot go there and see what applies to your systems. You need to know that yourself. Be sure about what you want to protect and what levels of protection you want, beforehand.

And, as I mentioned, there is the issue with certificates, which is an issue for every company. It's quite a hard thing to know. Not everyone is a professional when it comes to certificates. You may need to know the certificate chain, and you might have to update it with new information and roll that out to your organization. That might not be your first thought when implementing it in your system.

But the main focus is the network, especially if you're also going to deploy Safeguard in your own cloud. That creates a little bit more of a challenge.

We use their product called Active Roles as well. We haven't really done any integration with other parts of our business. We have just given administrators and people with high privilege a secure way to access their systems through RDP and SSH. But we have not integrated any robots or development flow as of now. We are too young in this journey.