top of page

Considerations When Implementing a Privileged Access Management (PAM) System

In today’s world, where there are headlines nearly every day regarding yet another company getting hacked, the question is no longer “Will we be hacked, too?” but is rather “When will we be hacked and how far will they get?”. Contrary to popular belief, threats do not always come from outside of an organization—threat actors can be external or internal. To lessen the impact of a security breach, privileged access and identity management have become an absolute necessity to protect your organization from these kinds of attacks.

Selecting a vendor and/or product(s) that fit your organization’s security needs can seem overwhelming, but there are many resources available to aid in your selection process. For example, a good starting point would be going to industry-specific events and talking to peers about what they have chosen or are considering for their PAM needs. Another option might be to work with a list of chosen vendors to implement proofs of concept (POCs) to test your specific use cases and validate whether the vendor(s) products can work with most of your use cases.

Though each organization comes with their own unique use cases that must be addressed, there are various general use cases that exist in most environments that should be considered. First, and most importantly, are Enterprise and Domain Admin accounts, often referred to as the “keys to the kingdom”. These accounts should be secured as soon as possible, their passwords rotated often, and access granted to them as little as possible, with strict controls in place for access. The second most important accounts to secure are elevated accounts, which aren’t at the level of Enterprise or Domain admin accounts but still have elevated privileges in the domain and/or locally on systems in the domain, such as Windows Local Admin, Exchange Admin, etc.

Now that controls have been put into place for Enterprise and Domain Admin accounts, as well as elevated accounts, service accounts should be addressed next, which is often a time-consuming process. Even so, these accounts should not be neglected as they can easily be forgotten if a formal process is not in place for password rotation, as well as overall lifecycle management. Service accounts seem to get neglected because password rotation for a service account can break applications, kill services, and cause chaos if the account has not been properly documented. It takes time to test service account password rotation, but it is valuable to the security of your organization to implement these types of controls.

Once your organization has decided on a vendor/product and are satisfied that they meet all or most of your use cases, you can begin by adding the accounts into the product. This is an excellent first step towards the goal of the product managing the password.

After you have added the accounts, you can begin to prepare for those accounts to be managed by your chosen product. At this point, it is recommended to meet with the team(s) that use the accounts, determine which environment the accounts are in (development, test, production, etc.), and work with the team(s) using the accounts to find a way to test and prove password rotation will not interrupt their operations. This gives you an opportunity to work through any issues encountered and can help eliminate excuses for not rotating passwords.

For more information on implementing a PAM solution in your organization, contact the experts at Identity And Access Solutions and check-out our Privileged Access Management page.


bottom of page