More and more non-human accounts are appearing in organizations. Accounts that belong to things, robots, RPAs (Robotic Process Automation components), devices, sensors and what not. Accounts that need access to systems, processes, networks, APIs and data. And in that regard, it might make sense to manage those accounts just like human accounts. 

Identity Lifecycle management 

Human accounts are usually managed in an IGA solution. IGA is the acronym for identity governance and administration. An IGA system is an information system that is designed to automate the joiner, mover and leaver process of employees (including temporary employees, etc.). And it also, as much as possible, automates granting and revocation of authorizations of accounts. Personnel changes in the HRM system are assessed by the IGA facility and then the corresponding authorizations are granted or revoked on the basis of Role Based Access Control principles (RBAC). The identity lifecycle is the guiding principle: Identities come to exist in the identity life cycle when entering into a working relationship with an organization (in the ‘joiner’ process) and they are removed when the employment relationship is terminated (‘leaver’). IGA takes the identity feed from the hrm-system as its source and then, on demand, creates the accounts and authorizations in target systems such as active directory. 

IGA manages identities, accounts and authorizations. So what could be more logical than using the IGA system for non-human accounts as well? Can we manage the RPAs and other things in an IGA system? 

No, in my opinion this is not possible. In my opinion it is not even desirable 

Lifecycle of things 

Non-human identities do not come from the HRM process. They don’t come from the joiner, mover and leaver processes. These identities derive from change management processes and the results of those processes are registered as configuration item in a CMDB, the Configuration Management DataBase. There is no on-boarding or off-boarding, but there is creation and phasing out of components like things and robots and other non-human identities. And the initiator of the change, the requester, is the owner of the component that is being created. So there is a management process, change management, and there is an administration, the CMDB. And as part of the change an account and authorizations are created. It is part of the creation of the component, it is part of the configuration of the component. 

Managing non-human identities such as RPAs, robots, things, etc. in an IGA solution is therefore not obvious, the governing process is not an HRM-like process and the results of this change management process are already registered in an administration, the CMDB. No need to duplicate the effort. 

The limitations of IGA

IGA cannot manage accounts and authorizations for things. If an IGA facility were to be used for managing things (in some environments this is sometimes referred to as ‘best practice’), several questions arise that are actually unanswerable: 

• In which department is the component included or used? 
• Who is the robot’s line manager? 
• What is the role, or what are the authorizations? 
• How do we arrange attestation/certification? 
• Who assigns the password and who is accountable for managing the account and the password? 
• How about things that have AI/ML capabilities and that will decide by themselves if and when they need more or less access, because they have learned to be more efficient? 
• How would you change the role of a thing in an IGA system?
• And last but not least… who can manage the thing itself?

There are some key differences between human and non-human accounts. One of the differences is that things not only need to have their own account in order to perform tasks as a subject, things are also managed themselves. Things have to be configured to perform those tasks. Things are not regular identities that IGA can do anything with. More obvious is to think of a thing as a configuration item that must be managed using a Privileged Access Management (PAM) system. The change that leads to the component results in a CI in the CMDB and in an object that is managed via a Privileged Access Management system. 

And, looking at the last of the bullets above, you can’t change the authorizations of a thing by just giving it a new role in an IGA system. Changing of authorizations is both the result of a change, and the acceptance of the changing authorizations by the owner of the assets that the thing is acting upon. Authorization management for things is not Role Based Access Control. 

Best practices for managing the Identity of Things

These principles can be seen as best practices for management of non-human identities and accounts: 

• The component life cycle is managed via the regular change management process (either development or procurement). 
• The requester of the change is to be considered the owner of the component. 
• Register the component, with it’s owners, it’s account and autorizations, in the CMDB. 
• Use clear (account) naming conventions, like “rpa_”
• Every non-human account should be present as an object in the CMDB. 
• If a non-personal account cannot be found in the CMDB: Remove the account from the platform or system! 
• Access from the component to services, systems and data is to be defined and realized as part of the change (and should be documented as such) – that is of course nothing new, that’s just standard procedure for any change. 
• Access to the component for configuration and customization is best done via a Privileged Access procedure. The owner should decide who can have access to the component. That should also be designed in the change and registered in the CMDB. 
• Do NOT manage non-human accounts in the IGA system. 

Many organizations are convinced that their CMDB is not correct, or complete. Even in that case, one should still manage components via the change process and not in the IGA system. Better a not fully functioning change management process and a not-complete CMDB than an IGA system that will then be ‘infected’ by a malfunctioning change management process. 

This article highlights the differences between human and non-human identities: https://bok.idpro.org/article/id/52/