Identity Governance and Administration (IGA) has a long and evolutionary nature. From the early incarnations of the early 2000’s of tools that could essentially sit in from of a SQL database and correlate, normalise and find exceptions in account data, through to today’s AI driven insights engines, backed by huge data lakes. The one thing that is constant, is change.
However, IGA was never just about the tooling and tech. It requires a multi-faceted approach that covers the triptych of people, process and technology.
So where does the distress conversation come into play? Is it in distress? I think firstly, let’s take a step back before we get into all the doom and gloom and look at a few meta-patterns.
Firstly IGA is still hugely relevant. The sector of suppliers has not shrunk or disappeared – like for example Enterprise Single Sign On or IPX – remember that? No of course not – unless you learnt your directory trade courtesy of Novell.
Why is IGA so relevant? Well for many in regulated industries (see banking, insurance, credit, investments, healthcare…) having a solid IGA plan is essential. To that end the classic equation of “as long as the IGA software + services costs less than the compliance fine…” that’s a win. We’ll buy some. And be auto-magically compliant.
But what impact does this seam of latent demand have? Well organisations put budget aside. It’s not a “nice to have”, vendors don’t need to burn marketing spend on “market awareness” campaigns and edu-ware narratives. Buy side practitioners – know they need IGA. They also know pretty much what they think their internal requirements look like – and can typically generate an evolving set of vendor questions and requirements on demand.
This can lead to an incrementally innovative set of market interactions – with suppliers each year becoming more adept at delivering solutions that are “longer, faster, stronger” than the previous years. They can answer request for proposals (RFP’s) at will, deliver nice demo’s and pilots. Result.
So that all sounds great. There is no distress there at all. Why are we talking about distress again? Well a few things need to play out here. Firstly, the chances an organisation is entering the IGA space for the first time is likely to be quite small. Many will have existing COTS (commercial off the shelf) products or indeed if not, will have the dreaded IGA-by-Excel approach. Even if the latter is un-scaleable, un-supportable and largely un-suitable. Something exists and needs migrating.
Enter the first distress alarm bell. Migrations typically suck. Any new technology typically gets assessed by the existing approach, with all it’s customized, hacked-together legacy charm. Successful IGA requires PPT. People, process and technology. Not slides. Processes for identity on-boarding, off-boarding, change and permissions management need to evolve to reflect changes in business function and risk. That requires business analysis. Data needs migrating. And often cleaning. Remediation, response and recovery stages also need to be (re)developed and integrated to the new technology landscape.
The (mis)alignment with the business is really distress alarm number two – and one which often results in constant technology swap outs – as the technology often requires the business to fit to it – when it fact the technology should be meeting the “business” where the business is. Prescriptive workflow, process and organisational structures will not end well.
Our most recent community poll at The Cyber Hut asked this rather leading and loaded question regards IGA distress. With n=65, the top response was this process-related topic. Asking organisations to change how they manage identity data or their relationship to it, to suit software will result in project delay at its best and project termination at its worst.
Deployment time fared second in the poll – which might really be a consequence of other factors – perhaps relating to process change or data and connectivity in general.
A few aspects to consider though for IGA in 2024. Firstly the systems under management are now likely to be in different locations, with different operational owners, service level agreements and responsibility models. The rise of cloud and the various different deployment models introduce subtle complexity. Data needs to be ingested from different places – perhaps via native APIs or connectors – and needs centralising and normalising. For IGA to be successful the breadth and depth of data integration options need to be a) large and b) extensible – with either customers themselves or delivery and integration partners being able to connect to new systems as a business as usual activity (BAU) not a project change management exercise. This is likely to also cover activity logs, permissions, threat intel and risk too.
So getting data into an IGA platform is still crucial – the volume and complexity may now be higher, but this process equally should be easier.
Back to the process consideration. The IGA tooling should really “bend” to the business not the other way around. We’re talking about process for exception handling, remediation, access request, access remediation, approvals, high risk identities and permissions and so on. Neutrality here is key in order to improve IGA coverage. Once a system and function is being managed via automation it can then be optimised from within the system, not as a pre-requisite for on-boarding.
IGA is complex yet crucial. Technology advances in the last 5 years mean that many IGA solutions are now cloud-aware (either deployed in or connect to), have extensible connector frameworks and provide generic process integration options. One thing I haven’t mentioned that is now critical to all aspects is AI (drink!).
So where does AI fit in here? IGA is really moving into the big-data problem space, so it would be surprising if AI didn’t have a role (no pun, maybe a little, intended) to play here. There are some obvious areas that AI could help with that could reduce some of the perceived “distress”. What about the following:
- Filtering access request data – what permissions should a user request?
- Identifying exception permissions – peer comparisons for example
- Helping to label discovered entitlements
- Helping to provide risk ratings for permissions
- Helping to map assigned permissions and used permissions
No team member ever wants more alerts, approvals or exceptions to manage. IGA can generate all three. Fortunately it also has the potential to improve how all three can be handled – allowing a more fine-grained focus on high risk or business impacting cases where human intervention is really needed.
It’s not all doom and gloom. If your IGA project is in distress – take comfort it seems you might not be alone. Also take comfort in the fact that this sector continually evolves and new capabilities are improving all the time.
Related Research: