Many organizations start off with a homegrown approach to IGA using a combination of spreadsheets, helpdesk tickets and manual intervention. 

Whilst a homegrown approach can work for small organizations with a small number of users, as the organization grows it rapidly becomes problematic – generating issues with efficiency and security. This is particularly true for any organization which faces regulatory compliance requirements, such as PCI-DSS, HIPPA or PSD2. 

Lifecycles for different types of users vary somewhat – but the core principles remain the same. Identity lifecycle management covers every action that has to take place from the moment the individual joins the organization until the moment they leave, including all of the inevitable change that takes place between these two events. 

The importance of identity lifecycle management throughout the entire process: 

1. New User Joins the Organization 

The identity lifecycle starts when a new user joins the organization. Typically, for an employee, this means that a record is created for the individual in the HR system, maybe on receipt of an offer acceptance letter. This record, usually created and managed by the HR department, will include key information about the individual including start and end dates, contact information and their job title and department. Usually the HR system has no concept of what access to applications and systems an individual should have, which is where the challenges start. 

In order to start managing access, the first thing the IT department needs is notification about the new user which in many cases relies on someone in HR sending an email, and on someone in IT picking up the email and reacting promptly. In some cases, this might work smoothly, but in many other cases there may be delays or the notification may be not sent or missed completely. This ineffective identity lifecycle management can result in a new starter being unable to work for some time after joining the organization, which is a poor user experience and has a cost in terms of lost productivity. 

2. Digital Identity Created 

Once IT has been notified about the new starter, someone has to create a digital identity for the new user. At its simplest this is a username and password to enable the user to log in – in many cases this means an Active Directory account needs to be created, a username assigned, and the users initial password created and communicated. 

This process can take up to half an hour per user – this maybe seems insignificant but in the context of a busy IT department, if there are a large number of users to manage the overhead quickly builds up. On top of that, if the process is manual then issues can develop over time in terms of standardisation – is a common username format being used, are users being placed in the right OU in Active Directory etc. Further, communicating the initial password to the new user can be problematic – doing it in person is inefficient, but there are security issues inherent in emailing out a password to a manager or to the individual – ideally no one should ever know a password other than the individual. 

3. Create Accounts for All Systems the individual will need 

It’s not enough to simply create one AD account for new users. Typically, users need access to multiple applications in order to do their job. This presents a couple of problems, without identity lifecycle management in place. 

Firstly - how do you know which applications they need access to? Unless you have tightly defined access rules, how is someone from the IT department meant to know what access someone from the Engineering team needs? Often, organizations make a ‘best guess’, or copy the access from another user from the same department. This can be a dangerous approach leading to users gaining more access than they should, particularly if there are poor controls governing access. 

Secondly – creating all of these accounts takes time. Typically, different administrators are involved to create accounts in each application. This means a lot of emails need to be sent, or Helpdesk tickets need to be raised – leading to a lot of delays before a user’s access is fully provisioned. All of this adds up to costs in terms of lost productivity. 

4. The user’s role changes 

The one thing we can be certain of is that once provisioned, a user’s access will need to change. This could be due to a change in role, or maybe a temporary project assignment. Whatever the reason, if a role changes, then access must change with it. This presents the same challenges as above – all over again. How does the IT department know what access the user needs in their new role? And crucially, how do they know what access is no longer required and should be removed? 

There is also the question of authorisation – how does the IT department know who authorised the change? Presumably there will be an email or helpdesk ticket raised, but if not then the IT administrator is relying on trust alone. In either case, there is no audit trail showing how a user came to have their access. 

5. Create Accounts for the New Systems that the User Needs 

Once again, multiple individuals might be involved in modifying all of this access and creating or removing accounts across multiple applications – so again there could be a delay, during which time the user potentially has unauthorised access. 

6. Provide the auditor with proof 

At some point, sooner rather than later for companies with regulatory compliance requirements, it is very likely that the auditor is going to ask for proof that users have the right access to applications and systems. With DIY IGA, this is extremely difficult to provide – partly down to the logistical problem of identifying all of the relevant application owners and managers to perform the validation, identifying all of the users to be validated, and moving spreadsheets around to collect the information. But the problems get even harder in the absence of a central IGA system which understands the relationships between user accounts across different applications. For example, there may be multiple users called Jane Smith working for the company. One application may have a user account for jsmith, and another for j.smith. Which Jane Smith do they relate to? Or do they actually relate to another individual altogether – John Smith? Working through these matching and correlation issues is extremely time consuming and error prone, and at the end it is highly likely that the auditor will not be satisfied with the output. Ultimately this could affect the organization’s ability to conform with regulations, and in some cases can impact the ability to win new contracts. 

7. The user leaves the organization 

The end of the identity lifecycle occurs when the user leaves or ends their relationship with the organization. Unfortunately, whereas human beings are very good at granting access when it is needed, in order to get a job done, they are very poor at following process to remove access when it is no longer needed, as removing access has no tangible effect on pressing day-to-day business. This means that in many cases there is a long delay between someone leaving the organization and their access being disabled or removed – and in many cases their access may never be removed. This is particularly true for contractors – employees are usually removed from the payroll system before the next pay day, so there is a trigger to remove access, but there is no such event when a contractor stops working for the organization. In this case, the relevant manager must remember and take the time to advise IT that the account is no longer needed, which in many cases does not happen. 

The outcome is a build-up of accounts and access for individuals who no longer work for the organization, which creates a very large security and commercial risk. 

8. Disable the user’s access 

When the user leaves, we need to disable all of their access – not just their Active Directory account. However, if there are no clear rules governing what access someone should have according to their rules, and no central location to lookup the access that they actually have, it is very hard to be sure that all access to all systems has been removed or disabled. Therefore, when a user leaves the building for the last time, their organization cannot be sure that some institutional data may be going with them. This poses a significant commercial and security risk, avoidable through identity lifecycle management. 

Doing it yourself, can work for some organizations, for a time. But ultimately the issues that it creates in terms of inefficiency and more importantly security and compliance mean that it rapidly becomes a non-viable approach. This is where Identity Governance and Administration platforms come in. 

Interested in learning more about Fastpath's Identity Lifecycle Management through IGA? View "Reduce your IT workload with Identity Governance and Access Controls" on-demand by clicking the button below: