Every beginning has its end.  What goes up most go down.  The circle of life.

Lifecycle exists everywhere, but very specifically in identity management.  The "phrase du jour" appears to be Identity Governance and Administration but at one point it was Identity Lifecycle Management...lifecycle is the governance and administration part of the new phrase.

Going through customer requirements every day, I noticed that lifecycle is sometimes forgotten due to these new phrases.  But the biggest security threat you have is the users who have access that are no longer with your firm.   Or have a new less secure job within the firm.  Or were a contractor that is now working with your competitor.

Two objects within your identity store need lifecycle most desperately: users and groups/roles.  If you manage those, the permissions will follow.  These two objects need several actions: start/stop dates and attestation / certification.  Basically set the parameters of the lifecycle and give a mechanism to approve that identity lifecycle and allow exceptions.

Let's start with user lifecycle.  You have several types of users: internal & external, person & application, permanent & temporary.

• Internal/external users: these should be in a metadirectory that allows you to manage them separately and not equally.  Internal users should have their lifecycle determined by an HR system, you really don't need to set an expiration date unless they are temps/contractors.  External users should have a set policy on how long they live with an internal user attesting to their account on a scheduled basis.
• Person v. application users: The person object is an EmpowerID terminlogy to note the user's identity, linking each application user account (AD, SalesForce, Google Apps for example) to the person object.  Application accounts should either have a lifecycle that needs attestation and certification or be tied to a role or group membership (which likewise has a lifecycle).
• Permanent v. temporary users:  Temporary users come with a builtin lifecycle, you know that you are only authorized to hire a contractor for a 3 month engagement, it is easy to tie an expiration date to that user but you need to have an attestation workflow that easily extends the user without having to re-grant all of their privileges.

For role and group lifecycle, you need to manage three things: the lifecycle of the role/group itself, the membership of that role/group, and the permissions that the role/group has.  EmpowerID delivers stock workflow templates for all of these lifecycle actions. 

• The lifecycle of the role/group itself: This is similar to a user lifecycle in that the business owner of the role and/or group needs to attest to its usefulness to the business every x months.  The ability to determine different lifecycles for each role/group is essential as well as have some never expire roles (domain admins for example).
• The membership of that role/group:  The membership certification of a group is a regulatory requirement in many industries but one that is often overlooked.  The business owner should have a way to either certify the rule that populates the group (clinicians in Ohio for example) or the exact membership.  Any membership exception needs to be noted and certified as well.
• The permissions that the role/group has: Once you know the group should exist and the membership is correct, the owner of the resource should attest to which groups and/or roles have access.  They don't need to worry about whether the membership is correct, the proper business owner already did that, they just need to say "yes, my patient records should be accessed by Ohio clinicians".

These identity lifecycle workflows can be incorporated into your provisioning, audit and governance workflows without much more effort.  You will have better regulatory compliance, your business will be more secure, and your users will be the right users having the right access to the right resources.  Schedule a demo of how identity lifecycle management should work now.