Steven -- Appreciate the follow-up and what you say makes sense. Given the potential for damage by superuser accounts, it does seem like accountability is needed especially there. What happens now seems like this is a case of the experts doing what they keep others from doing -- sort of like doctors who smoke tobacco. I wonder also if part of the problem is that makers of infrastructure systems have never been pressed to provide the hooks necessary to implement fine-grained access to different admin functions, which would make role-based (duties-based) access easier for an IAM system to implement. Some (all?) PAM systems hack authorization by assigning admin users permissions to run specific executables, which has some value. But IAM (ABAC) systems like Axiomatics (and perhaps others) implement analogous strategies, using query re-write, for example, to limit access based on table metadata (cols) or content (cell values). Presumably they could do something similar for access to specific executables or combinations of executables and parameters. In any case, to your point about over-provisioning of access to sysadmins: it seems a good deal of grief could be eliminated in sysadmins could be blocked from accessing business data in the clear. Presumably, only business types need to see that. In the (little bit of non-hands-on) research I've done on PAM offerings one glaring problem seemed to be that the authentication required to check out and use the superuser credentials was not itself particularly strong, i.e., it was password based. (Reminds me of pins protecting soft certs.) As for the bootstrapping issue, I guess you can't have the IAM system protect the other systems until somebody installs the IAM system. But then that goes for the PAM system, too. At this point I am still inclined to believe that it would be a good idea for major relying parties (i.e. customers like governments and large corporations) to establish a goal being able to use one system and one set of policies to control admin-account access as well as user access to info resources and functions. Again, thanks for the follow-up! Martin On 1/30/2020 5:10 PM, Steven Legg wrote: Hi Martin, This is an elaboration on my answer to your question during the TC conference call: why does Privileged Access/Account Management exist? IMO, the simple answer is that PAM exists because superuser accounts exist. Superuser accounts tend to be shared accounts used by a number of administrators who all know the password. One problem with this is ensuring that only the right people know the current password as the composition of the group of administrators changes over time. If someone leaves the group then the password should be changed and all the remaining group members informed, but that is easier said than done and often skimped. Another problem is monitoring and auditing what individual administrators are doing. Since they are all using the same login credentials we can't associate any particular action with any particular person. A PAM solution addresses these problems by changing the privileged account password for each session (and keeping it hidden) and recording who created the session and the actions they performed because the administrators log in to the PAM solution as themselves. The shared superuser account is the essential problem. The obvious alternative is to have the administrators authenticate using individual identities and to manage the access controls to give each administrator the access they need. When an administrator leaves, their account can be disabled/removed (by another administrator with the access rights to do so) and, assuming all user actions are recorded, we know who did what when. We still need a way to bootstrap the initial identities and access controls and this is something that a superuser account has traditionally been used for. However, there has been a tendency to attach all sorts of administrative activities with the superuser account, to the extent that some administrative actions can only be performed by the superuser account. A reason applications might do this is to avoid having to address managing access rights for administrative activities. So inadequate or non-existent support for managing access rights for administrative actions forces administrative users to use a common superuser account and, consequently, PAM is a thing. At least, that's the way I see it. Regards, Steven -- Martin F Smith BFC Consulting, LLC McLean, VA 703 389-3224 mobile