Among the many acronyms in security, one that is growing in prominence is IGA: identity governance and administration. Often (incorrectly) conflated with IAM (identity access management), IGA is a framework for how companies should administrate identities and their provisioned access. While IGA is often stereotyped as a “big-company” problem, it’s more a way of thinking about access, and principles strewn in IGA solutions are pertinent to smaller companies.
IGA literature can be frustrating due to its “fluffiness”. It’s really easy to get caught up in the buzzword soup of “visibility”, “governance”, “certification”, or “credential administration”. These aren’t bad marketing terms—after all, they do sell. But sometimes, all this vision talk dilutes the actual picture of what IGA looks like in practice. Today, our goal of exploring the IGA landscape is guided by clarity; we want to establish an IGA framework for 2024 in simple, straightforward terms. We’ll discuss the factors that prompted the emergence of IGA, how to digest IGA solutions, and finally, the core functionalities of a modern IGA framework.
Similarly to IAM solutions, IGA solutions tackle how identities are created, managed, and deleted. However, IGA and IAM are not perfect **synonyms. IGA goes beyond identity management; some of its additional responsibilities include policy enforcement and compliance management. Those may be marketing terms, but they translate to tracking how employees use their access.
Taking a step backward, IGA’s predecessor, IAM, was originally necessary because (a) phish-able humans can’t be trusted with broad access and (b) identities are constantly in flux as organization charts change. This gave rise to many centralized identity providers, such as Okta and One Identity. However, modern identities are just the tip of the iceberg. Companies use hundreds of SaaS applications, and some applications are used sparingly (or, worse, not at all). Additionally, some applications have “authenticate once, use forever” bearer-token authorization flows. Together, these factors create a myriad of security weak spots. Accordingly, with visibility into how access is utilized, security teams can identify suspicious changes in behavior, potentially preventing unauthorized access.
IGA solutions are marketed as two things: automation solutions and compliance solutions.
Automation is the more apt description. From a birds-eye view, IGA solutions aren’t doing anything novel, just assigning access and monitoring access. For decades, that’s work that was already done by CISOs and security teams. The difference is that IGA automates those security practices, a necessary feature as access grows more complicated.
The impact of this is easier compliance. IGA solutions make abiding by (and auditing) government compliance and third-party compliance easier by enforcing internal policies. IGA solutions don’t alter what’s considered within the compliance regime—they simply automate tedious processes, enabling those same folks to focus on more finish-line compliance tasks.
Today’s workforce problems aren’t terribly different from those of half a decade ago, but there are some notable changes that impact the focus of IGA frameworks. Here’s a short list of those core considerations:
Generally speaking, these rules translate to features that are touted by major IGA players. However, instead of comparing specific IGA solutions with one another, let’s focus on what an ideal IGA solution should be able to do.
IGA solutions need to support a core set of features regarding the needs of an organization’s employee directory:
Fundamentally, this boils down to an IGA solution that can dynamically manage employee access based on their employment status. It’s also important that administrators can get a birds-eye view of all the access grants being afforded to employees.
Organizations have employee handbooks to ensure that data usage is safe and security practices are being followed. However, organizations cannot blindly trust that employees follow rules, since humans often take shortcuts or are slow to adopt tedious practices. (Additionally, threat vectors can be, on rare occasions, internal.)
These company policies are sometimes solely driven by in-house leadership but are otherwise influenced by compliance standards such as GDPR, CCPA, and SOC II. Granted, it’s not that IGA solutions ingest a text-block of policies and use some AI magic to govern applications; policy enforcement boils down to ensuring that employee access is in accordance with set policies.
The point of an IGA solution is to simplify identity management and governance. If an IGA solution creates more busy work for administrators than saves time, then it is effectively circumventing its primary value prop.
To address this, IGA solutions need to seamlessly integrate with existing IT infrastructure and applications. Common integrations are with cloud providers like AWS, HR solutions like Workday, engineering management solutions like Atlassian, drive solutions such as Box, and workspace solutions like Google Workspace.
IGA solutions also need to configure alerts for any breaches to policies so that administrators don’t need to constantly login and monitor—these are sometimes marketed as systems health notifications.
Today’s companies use a variety of authentication techniques.
The first technique is to lean on the IGA provider for authentication, such as SailPoint’s IdentityIQ authentication solution. Another example would be Okta, which is slowly ramping up into a fully-fledged IGA solution.
The next technique is to support pass-through authentication such as Microsoft’s Active Directory or LDAP (lightweight directory access protocol) where the IGA solution is still used as the interface for authentication even though it’s just querying an underlying employee directory.
Another common model is Single-Sign-On providers such as Google, where a service provider such as email is also used as authentication on other applications. These are typically governed by SAML, an XML-extension language that defines what properties are shared with the SSO provider.
Of course, it’s important that the most stringent of these is applied to accessing administrative accounts on an IGA solution; otherwise hackers could just exploit a company’s security by hacking their IGA solution access directly.
An IGA solution needs to work with other directory-spanning software such as HR solutions, identity providers, and other point solutions. IGA solutions are designed to be umbrella providers and therefore need to proactively act as a source of truth to unify these moving parts. Practically, this translates to strong integrations where an IGA solutions can trigger write actions in other directory-spanning software.
One of the growing acronyms within the IGA space is BDG—behavior-driven governance. Essentially, that’s monitoring how employees use applications and dispatching alerts if that usage contradicts expectations. It’s a model particularly championed by One Identity, an IGA/security solution.
There are a few features that make a BDG-type IGA solution compelling (I might’ve vomited a little after writing such an acronym-heavy phrase, e.g., an AHP):
Overall, BDG are nice-to-have features of an IGA solution. However, in 2024, they are particularly nice when companies are over-purchasing SaaS applications, especially when many SaaS applications have sensitive data.
In 2024, as more organizations adopt feature-heavy IGA solutions, they should care about some core features being present. They could be split into two groups: (i) features that improve security by providing a path to least privilege and (ii) features that streamline management by automatically doing tedious tasks.
The core mantra of IGA solutions is making sure that only the right people can do sensitive actions while keeping the process automated and efficient.