It might be a bold statement, but there is no consistent definition of the domain of identity and access management (IAM). Over the years, this inconsistency has led to widespread confusion.

Much has been written about the IAM domains of capabilities and services. With so much thoughtful and innovative work and so many disparate parties, it’s no wonder IAM lacks a single lexicon. There are some commonalities, however. The work by Gartner, Forrester Research, the National Institute of Standards and Technology (NIST), the International Organization for Standardization (ISO) and other organizations have helped to clear some fog.

Clearing the Fog

Older and more mature concepts have been widely adopted. For example, as much as it bothers those of us who understand Lightweight Directory Access Protocol (LDAP) as an actual protocol, it’s common to hear “the LDAP” in reference to an enterprise directory. But less mature concepts still vary widely and lack precision and consistency.

This isn’t strictly a problem with nomenclature. The real issue is the lack of consistent understanding about the relationships between the IAM domains. My colleagues and I have worked with hundreds of clients across industry sectors in the U.S. and Canada. In doing so, one of the most common topics of conversation starts with a client asking, “What do you mean when you say …?” We have become adept at translating the corporate vernacular.

Even after more than 15 years of widespread, mainstream IAM use, it has become routine to describe our view of the IAM domain. My colleagues and I developed a structure to describe this domain as it is divided into services that may be consumed by business users. Breaking these down further, we defined a set of common use cases for each.

The Fundamental IAM Domains

IAM is one of the most important facets of information security. It is connected to nearly every other element of security — in fact, it touches almost every aspect of the business. Think about that for a moment: What other systems affect nearly every user, every department and every application, and influence the financial reliability of a business? An enterprise resource planning (ERP) package? A web hosting platform? An HR management solution? Maybe, but not much else.

Below are the fundamental IAM domains:

• Identity data defines how user data is stored, used and managed. This data includes basic information (name, email, user ID, phone numbers, etc.), entitlement data (who has access to what applications, detailed application access) and identity metadata (user preferences and provisioning metadata).
• Identity management defines how users acquire, change, manage and lose access and identity data. This is likely the largest IAM domain and certainly the most complex. It is the manifestation of processes specific to each organization.
• Access governance defines how an organization’s management can oversee, control, report on and respond to users’ access and the use of secured resources. This is the most diverse IAM domain, with links to other security areas. It is also, in our experience, the IAM domain with the lowest level of maturity among clients.
• Access enforcement defines how users’ access is enforced to know who they are and ensure they only access what they are authorized to access. This is the domain that most end users interface with most directly and most often.

Domain Codependence

None of the IAM domains can exist without the others. Even identity data, which is the source of necessary information and was the first to mature into the pseudocommodity it is today, is dependent on the other domains. While it’s common to think about these domains tactically, it’s impossible to ignore the others.

Let’s consider the following example: Imagine your company received audit commentary stating the need for two levels of certification for user access to a set of applications. The natural reaction is to focus on access governance. But without high-quality identity data and alignment between access governance policies and the identity management provisioning rules, companies find themselves solving the symptom but not necessarily making themselves more secure. The audit finding will go away in the next audit cycle, but is that what we as security professionals are trying to achieve? Aren’t we trying to protect our sensitive resources?

Below is a high-level relationship between the IAM domains. These are the necessary links that enable all IAM domains to achieve maturity. Improvements in one IAM domain positively affect the others. Conversely, neglecting one weakens the others.

There has been an interesting and important growth of maturity in each IAM domain. It has not been consistent across all domains, however. The technology solutions have often led the way, while process integration has been the laggard in every case.

Recently, the majority of IAM initiatives across the industry have focused on wider adoption, process alignment and expanded functionality. Very few companies have high maturity in all capabilities of each IAM domain. Some try to boil the ocean and do all of them poorly. Others only fight fires and are unable to deliver strategic IAM services. Others still are heavily constrained by cost and cannot succeed at even the most basic capabilities. As a result, there appears to be an upper boundary to the maturity organizations are reaching in their attempt to fully service business users. Perhaps we need a better way to offer these capabilities — one that focuses on specific value.

IAM Service Model: Measuring Maturity and Value

The next step is to define the services these IAM domains offer and understand the value each can provide. We need to come to a consensus about what positive changes an organization might reap from each domain. Some are monetary, some are intangible and some simply won’t apply to your organization. But they all have value to stakeholders and business units.

These are not universal, and the extent of the value is dependent on the maturity in each area. The important takeaway is the direct relationship between maturity and the value received.

Identity data enables organizations to achieve:

• Cross-IT platform standardization;
• Consistent levels of access across applications;
• Common credentials;
• Centrally enforced security over sensitive identity data; and
• User data mining.

Benefits of identity management include:

• Operational efficiency through automation;
• Improved user effectiveness for new hires and movers;
• Regulatory compliance through process automation;
• Smooth organizational changes; and
• Improved security through policy enforcement.

Access governance empowers organizations to:

• Automate regulatory compliance;
• Simplify audit processes;
• Integrate cross-security platforms, such as system on chip (SoC) and event correlation; and
• Increase visibility into oversight and management controls.

Access enforcement engenders:

• Improved user experience;
• Consistent access control enforcement;
• User engagement and analysis;
• Regulatory compliance enforcement; and
• Business partner integration.

What About Privileged Identities?

If we take a product-centric view of the IAM domain, it would seem that privileged identities are not included. In our view, however, privileged identities are not a separate IAM capability. Rather, all of these IAM domains must apply to privileged identities, but via different mechanisms and use cases.

Fundamentally, privileged identities represent a small population of users — typically employees or vendors — who have unique and potentially risky access. In spite of the low number of affected users, many technology solutions provide these capabilities for this narrow audience. It’s justifiable given the high potential impact and unique use cases.