The identity lifecycle involves a series of different processes, each with its own essential role. These processes can be classified into identity creation and validation (sometimes also called “registration”), authentication, and identity change management. In Part 1 of this blog series we discussed how an identity is created and validated within the enterprise. In Part 2, we discussed how registered identities authenticate themselves to the enterprise. In this final installment in the series we will discuss how identities change and how the changes are managed over time.

Modifying the Identity

Every identity management system must have a way to change identity-related information. The changes can be of several kinds.

• Identifiers related to the individual might change. For example, a name might change as a result of marriage or adoption, an address might change because someone moves, and an e-mail address might change because someone decides to use a different account.

• Identities can be modified because individuals need different privileges as their relationship with the enterprise evolves, or because individuals with similar identity information need to be uniquely identified. For example, an individual whose job responsibilities change may need to have identity information augmented with job-specific credentials such as a medical license; one individual may need to have the ability to act on behalf of another individual noted as part of the identity data set; additional data may need to be included for a father and a son with very similar names.

• The identity might not simply have evolved roles, but they may also hold multiple roles. This is particular important in external facing solutions (patients, citizens, consumers, etc.) as the individual may be approaching the system from two different points of view, and both points are valid.  A doctor, may also be a patient; a government employee, is also a citizen; and a merchant is also a customer — all of these either within or across enterprises.

• An identity may need to be archived or deleted.

It is important to remember that changes in the identity have potentially significant consequences for both the enterprise and the owner of the identity.The enterprise needs to hold to several essential tenets when it comes to identity data modification. No matter who performs the changes, even if they are performed by a trusted agent inside the enterprise, all such modifications should be logged and audited. This enables the enterprise to control the risks presented by the insider threat, including identity theft, liability exposure through inappropriate actions, or theft of enterprise resources. 

If the enterprise enables self-service by individuals to modify their data, such modifications should be permitted only after the individual has passed authentication at an appropriate level to make the change. For example, when using out-of-band one-time-passcode delivery, the enterprise should only allow self-service change by an individual after they have passed an equivalent level of authentication with an alternate authentication solution.  Changes to identity data should be treated as high-risk transactions when it comes to appropriate authentication level because such changes can be used for account hijacking, enterprise system penetration, and system privilege changes. Once again, all changes should be logged and audited.

Finally, the enterprise needs to perform periodic evaluations of its identity-related policies, processes, and technologies in order to stay abreast of the evolving risk environment. Actions that are innocuous activities alone, such as changing the e-mail address to which notifications are sent, may evolve into precursors of account hijacking or worse. Just like other areas of security, identity management is a continuing competition between attack and defense and deserves full integration into the enterprise risk management paradigm.