Identity & Access Management

Identity and Access Management (IAM) is a framework of policies and tools that allows organizations to provide humans, automated software, and artificial intelligence “agents” the ability to access specific resources without necessarily granting them the “keys to the kingdom.” Put another way: IAM defines “who” (an identity) is allowed to access “what” (information, capabilities, and services) within the organization’s environment.

That means Identity Access Management software has to serve two related but distinct functions. The first is to enable the creation, management, and deletion of “identities”; the second is to define what those identities can access, enforce those rules after they’re set, and modify them when appropriate. And these solutions must keep pace with the speed at which modern organizations need to operate—they can no longer afford to wait for the IT department to respond to individual requests.

Key concepts & terminology

What “identity” means in an IAM context

It’s easy to conflate “identity” with “who a person is.” That’s what the word has meant for most of history, after all, and even in the IAM context it can still refer to something associated with a person. But the definition of “identity” as it applies to IAM would be closer to “a profile or set of information tied to a specific user, machine, or other entity in an IT ecosystem,” as IBM puts it. Many people would also consider it synonymous with “account,” since that’s the term they’re most likely to encounter themselves.

This broader understanding of “identity” offers a better perspective on the breadth of functions identity management systems are expected to perform. They’re used to make sure Brenda from Research & Development has an account on the organization’s internal network, sure, but they also have to serve a similar role in the management of service accounts and the “agents” offered by AI service providers. They’re also expected to ensure that Brenda, those service accounts, and those “agents” can access the resources they need but can’t wreak havoc on the organization’s digital infrastructure in the process.

Authentication vs. authorization: Similar, not the same

The average person’s experience with IAM can blur the lines between authentication and authorization. All they know is they can’t access the resources they need without signing in to their account. That seems like a one-step process—”sign in”—but there are two distinct things happening.

Authentication vs. authorization

What an identity provider does

An identity provider is responsible for creating, managing, and deleting identities within an environment. This centralization of responsibilities makes identity providers a compelling target for adversaries, but they are central to most organizations’ digital infrastructure, so they’re willing to take the risk.

The most common identity providers are Microsoft’s Active Directory and its cloud Identity and Access Management counterpart, Entra ID. These services are often responsible for additional roles within an environment, especially mobile device management (MDM) tasks such as enforcing security policies on organization-issued laptops, smartphones, and tablets, which makes them even more high-value targets from the attacker’s perspective. That’s why securing Active Directory and Entra ID is crucial to defenders.

Common authentication factors

Earlier we mentioned that most organizations now require more than just a simple username-password combination to authenticate to a particular identity. The requirements vary based on where organizations are located, in what industry they operate, which compliance requirements apply, etc., but some of the more common rules include the use of passwords containing the requisite number of alphanumeric characters and symbols that are rotated on a set schedule, such as once quarterly, yearly, etc. (Despite evidence that rotating passwords on a set schedule is not only ineffective, but can actually be actively detrimental to identity security.)

In addition to stronger passwords, as mentioned before, organizations tend to secure identities within their environments using MFA. Some of the more common authentication methods include one-time passcodes and dedicated hardware keys. The near-ubiquity of smartphones, tablets, and laptops has also given rise to the use of biometrics—fingerprint scanning and face recognition in particular—for authentication purposes. All of these factors, from passwords and one-time codes to hardware keys and biometrics, can be combined in various ways based on the organization’s requirements and capabilities.

Alternative methods of authentication have also become popular in recent years. Foremost among them are single sign-on (SSO) mechanisms, which allow identities to access a variety of services, software, and systems upon authenticating with a single identity, and passkeys, which leverage dedicated chips in modern devices in combination with other authentication methods. (Thereby making it so individuals can use hardware-based authentication with the devices they already own rather than requiring them to remember the location of a separate key.)

The IAM lifecycle

IAM has a predictable lifecycle. Exact terminology will vary across identity providers and the organizations they serve, but the steps are:

1. Provisioning / enrollment
   The first step is to create an identity and, depending on who you’re asking, either provision or enroll it. The distinction makes little difference in day-to-day operations; this step is simply dedicated to setting up an identity.
2. Maintenance
   The second step is to maintain the identity provider system, which involves regularly auditing identities to determine which are active, which are operating as expected, etc. and which might need to be adjusted or, if they’re inactive and aren’t expected to become active again in the near future, move on to the next step.
3. De-provisioning / disenrollment
   The third step is to cull inactive, compromised, or misconfigured identities from the environment. Failing to do so can leave organizations vulnerable to attack from adversaries who know how to discover inactive identities, take them over, and use them to achieve their goals while attempting to evade detection.

The pillars of IAM

IAM has many responsibilities that can be sorted into a few broad categories. Each involves at least one of the actions we’ve already mentioned: administering identity providers, authenticating requests to use an identity, enforcing authorization policies that apply to that identity, and auditing the environment to check for any identity-based issues that might cause problems.

Directory services

Perhaps the largest delta between how simple a concept initially seems and how complex it becomes in practice is found with directory services. The idea’s simple: organizations typically rely on a large number of servers, software, and services, each of which is responsible for managing various information, so they need a way for identities to find and use those resources. Easy-peasy. But the interconnected workings of all these identities and infrastructure quickly becomes a convoluted mess of permissions and policies that only become more complicated over time. Handling this mess is a critical part of IAM.

Credential management

Humans struggle to manage their own authentication methods, due to the sheer number and complexity required for proper maintenance. Everyone’s heard stories about someone writing the password to their workstation on a sticky note attached to the bottom of their monitor, or the password for a shared printer appearing on a piece of paper hanging above the device, and things have only gotten worse over time. Passwords are shared via email, instant messages between colleagues, and knowledge base software. Hardware authentication methods are passed freely between people because at any given time some percentage of them have misplaced or forgotten their own keys. Push-based requests to authenticate are blindly accepted as they appear.

IAM tools must provide organizations with ways to handle these issues. That includes enforcing password-related policies, revoking credentials known to have been compromised, and providing ways to reset forgotten credentials. This is part of the reason why SSO and Passkeys have become so popular: They give organizations ways to “lock down” a single identity that can then provide access to other resources, simultaneously making it easier to administer and more secure than a hodgepodge of identities that rely on weak credentials.

Access controls

Providing ways to find resources (directory services) and control who’s allowed to use an identity (credential management) lays the foundation for another pillar of IAM: access controls. It’s kind of like posting a floor plan, distributing access cards to employees, and then deciding which floors and rooms that particular employee is allowed to enter (often based on their job, which is why this is called role-based access management); only in this case, it also involves deciding what they can do while they’re in the room, what they’re allowed to take out of the room, etc. and then enforcing those policies.

Each of these pillars is critical not only to an organization’s function but also to its security. Without them nobody would be able to find anything, remember what they need to access resources, or get anything done; nor would an organization be able to put limits on what they’re allowed to find, how they can access resources, and what they’re able to do. Finding the appropriate balance of usability and security is vital to IAM in modern environments.

IAM in the AI era

Many of today’s biggest identity access management trends stem from the dawn of the AI era, which intersects with IAM in several ways. The one most keenly felt by organizations embracing “agentic computing” is the explosion of identities they have to manage as well as the scrutiny with which those identities must be considered. The other one, which also promises to help system administrators and defenders manage that explosion, is using AI to improve the security of both authentication and authorization mechanisms.

AI, ad infinitum

AI service providers have popularized the notion of “agents” that can respond to prompts but is also capable of autonomous operation. There is a gap between the capabilities of “agentic computing” and its current iteration, but as large language models (LLMs) continue to improve over time, the promise is that these agents will achieve better results with less manual intervention over time. But at least for now they still require a human somewhere in the loop.

As for what that means from an IAM perspective: Each agent requires its own identity and, possibly, access to other identities. That would greatly complicate IAM requirements on its own, but it’s also not uncommon for tasks to involve multiple agents, all being orchestrated by a human or team of humans. (Or for multiple agents to receive instructions from a separate agent, which receives instructions from… well, you get the idea.) The relationships between these identities and organizational infrastructure constantly multiply.

The consequences of mismanaging identities associated with agents can also be dire. AI providers have tried to mitigate the harms their agents can do, but it’s still not uncommon for agents to misinterpret, ignore, or modify instructions in ways that can have severe repercussions, whether it’s deleting a production database, silently changing important assets, or causing other problems. Despite claims of being able to establish “guardrails” with hyper-specific prompts, the reality is that IAM solutions enforcing policies outside the agent’s purview remains the best way to prevent these problems.

Using AI to improve IAM

We mentioned earlier that IAM solutions use a variety of information, such as when an authentication request is being made and from where, to determine if a request using valid credentials is legitimate or not. The problem with this kind of analysis is that it can lack nuance—someone making a request outside their normal work hours might be responding to an emergency, for example, rather than attempting to steal organization secrets. An IAM solution lacking additional context might block a request to authenticate at a critical moment. AI service providers want to help organizations establish that context.

Organizations might also be able to use AI to better recognize legitimate usage patterns so they can scrutinize close-but-not-quite-the-same activity. Maybe authentication requests for a particular identity tend to originate from an employee’s home IP address, except for every third Wednesday, because that employee works from a local cafe on those days. Adversaries might know to spoof requests through the employee’s home IP address, but will they know about the monthly work-from-cafe pattern? Maybe not. Adversaries get better at compromising ostensibly secure IAM solutions all the time; the hope is that AI will be able to help defenders keep those attackers at bay anyway.