A Blueprint for Identity Governance in the Digital Enterprise

Published: January 2026

Abstract

In our research reports, events, and consulting engagements, TechVision has relentlessly described the need for organizations to transform into Digital Enterprises. Being a Digital Enterprise emphasizes the requirement to be adaptive to the marketplace with enterprise-wide agility that optimizes responses to events and opportunities.

Since our last publication of the IAM Reference Architecture in 2021, several key developments have underscored the foundational importance of IAM:

1. Zero Trust Security: Robust, accurate, and available identity information is now required across all aspects of the digital landscape—people, things, agents, networks.
2. Artificial Intelligence (AI) and Agentic AI: Competitive pressure drives rapid AI deployment, requiring new governance models and identity controls.
3. Hybrid and Multi-Cloud Environments: SaaS, IaaS, and multi-vendor models demand consistent identity and access management across distributed infrastructure.

This report lays out the case for evolving your IAM environment into IAM 2.0: capable of supporting modern digital enterprise requirements. We provide a comprehensive reference architecture—capabilities-based, maturity-aligned, and execution-focused—that serves as a checklist for assessing progress and a blueprint for strategic road mapping.

Authors:

Gary Rowe CEO, Principal Consulting Analyst [email protected]	Doug Simmons Managing Director, Principal Consulting Analyst [email protected]
Gary Zimmerman CMO, Principal Consulting Analyst [email protected]

 

Revised Edition incorporating scope, conceptual model, deployment patterns, data integration, security/privacy, governance, and maturity guidance

 

Executive Summary

Identity management is the foundation that enables the 21st-century Digital Enterprise. The ability to manage digital identities—of every user, device, and asset—across all lines of business is now a fundamental requirement for realizing the full benefits of cloud computing, AI, mobility, and IoT.

However, traditional enterprise IAM/IGA solutions present a challenge: they require extensive manual effort to maintain, refine, and govern. Typical IAM and IGA environments have vast numbers of administration, lifecycle, monitoring, and configuration capabilities—often leaving organizations with gaps as tasks fall through the cracks.

AI is changing this. The inclusion of AI-powered administrative companions — agents that automate discovery, recommendations, remediation, and monitoring—marks the beginning of a new era: IAM 2.0.

Key Developments Driving IAM 2.0

1. Automated Role and Access Recommendations: AI analyzes usage patterns to recommend least-privilege policies and identify unused permissions.
2. Access Review Automation: AI assists in scheduling, optimizing, and executing access reviews based on risk signals.
3. Intelligent Query and Investigation: Administrators ask natural-language questions (“Who has privileged access to financial data?”) and receive actionable insights.
4. Cloud Infrastructure Entitlement Management (CIEM): AI discovers and explains permission sprawl across AWS, Azure, GCP, and on-premises environments.
5. Just-In-Time (JIT) Access: AI suggests policy updates to enforce least-privilege dynamically, eliminating standing access.
6. Shadow Workload Discovery: AI identifies non-human identities (service accounts, containers, agents) and proposes governance policies.
7. Risk-Driven Alerts: AI summarizes identity risks and recommends remediation for both human and non-human identities.

 

TechVision’s Approach

We recommend a structured approach to this critical infrastructure element: adopt a Reference Architecture (RA) to:

• Organize business requirements around identity
• Tie requirements to specific capabilities
• Identify current-state strengths and gaps
• Measure progress toward a future state
• Continuously refine and optimize

This new edition of the TechVision IAM 2.0 Reference Architecture includes:

• Execution guidance on scope, intended audiences, and how to use the architecture
• Conceptual framing independent of technology choices
• Deployment patterns for on-prem, hybrid, and cloud-native environments
• Identity data and integration models for consistent, policy-driven access
• Security and privacy considerations aligned to Zero Trust and regulatory requirements
• Governance and operating model to drive adoption and accountability
• Maturity model to assess current state and roadmap future evolution
• Playbook elements for alignment and implementation

With this comprehensive approach, you can develop a prioritized plan for making IAM an enabler—rather than a roadblock—to digital transformation.

Introduction

Why This Matters Now

Digital transformation depends on consistent, clear, and secure identity management for every user, device, and asset across all lines of business. At its simplest, identity management answers two questions:

• Who/what are you?
• What can you do?

These questions have never been more complicated. Nor have the stakes been higher. For enterprises, the ability to manage digital identities of every contributor, customer, and prospect is fundamental to realizing cloud computing, AI, mobility, and IoT benefits.

Digital Enterprises are driven by market ‘pull’—recognizing resources at a granular level and orchestrating them to meet market demands. This is a fundamental shift from the traditional ‘push’ model of standardized product delivery through well-defined processes.

Market-pull examples:

• Rolls Royce sells “thrust per hour,” not jet engines
• Auto companies increasingly sell “miles driven” through subscriptions
• NetJet sells “flight hours,” not aircraft
• Shopping has shifted from malls to online storefronts with same-day delivery
• AI is now driving rapid, loosely-governed deployment across enterprise digital services

The implication: Traditional enterprise IT infrastructure—designed for centralized applications and stable, well-coupled dependencies—cannot support the agility, distribution, and autonomous decision-making required by market-pull models.

The pull model introduces:

• Cloud and edge computing in addition to centralized infrastructure
• AI-driven composition of business logic by line-of-business managers
• Massively distributed endpoints (IoT) with hyper-connectivity
• Increasingly granular, orchestrated resources across hybrid, multi-cloud, and on-prem environments

This evolution shifts the focus of security from the data-center perimeter to individual resources themselves—no matter where they reside. As TechVision described in our report “Identity is the New Perimeter,” identity becomes the common denominator across the entire digital environment.

New requirements for IAM/IGA follow:

1. Zero Trust Security: Granular authorization of all subjects (users, agents, applications, devices) to access resources—with removal of standing access based on real-time contextual signals.
2. AI-Enhanced Identity Governance: Algorithms can manage complex decision-making across context, preferences, and patterns without decision fatigue, enabling faster, better governance decisions.
3. Choreographed Identity Governance: Policy-consistent yet responsive control across distributed resources—networks, clouds, applications, things, services, and data.
4. Diverse IAM Object Types: Support for all identity types—people, machines, IoT devices, AI agents—with discovery, verification, and governance.
5. Integrated, Privacy-Protecting Identity Services: Leveraging AI and contextual data for least-privilege access decisions and adaptive consent management.
6. Internet Scale/Speed: Connecting millions of subjects and resources in near real-time for market-pull responsiveness.
7. Elegant User Experience: Optimal governance with minimal user friction—never a roadblock for developers, administrators, or end-users.
8. Distributed Identity Fabric: Identity services distributed to best support zero trust, while maintaining governance consistency across the enterprise.
9. New Identity Proofing: MFA, biometrics, passwordless authentication (passkeys), adaptive authentication, and token-based solutions replacing password-based proofing.
10. Customer-Centric IAM and Identity of Things (IDoT): Integrating CIAM and IoT management as part of a distributed identity fabric.
11. Identity and Risk as Discrete Services: Identity/security APIs and microservices supporting DevSecOps and zero-trust governance.
12. Decentralized Identity and Verifiable Credentials: Blockchain-based registry and discovery enabling user-controlled identifiers and privacy-compliant IAM.

 

Purpose, Scope, and Usage

Purpose and Objectives

The TechVision IAM 2.0 Reference Architecture is a master template identifying IAM capabilities (rather than specific technologies) that can be improved or enabled. It allows business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time.

Objectives:

• Provide a starting point for enterprise architecture efforts around identity
• Establish a common vocabulary and reusable design patterns for IAM
• Guide evaluation of current state and road mapping to future state
• Support vendor and technology selection by clarifying required capabilities
• Enable measurement and maturity assessment
• Align IAM to business requirements and regulatory obligations

 

Scope and Assumptions

This Reference Architecture for IAM 2.0 addresses:

Identity Types (In-Scope):

• Workforce identities (employees, contractors, partners)
• Customer identities (CIAM scenarios)
• Non-human identities (service accounts, containers, IoT devices, AI agents)

Environments (In-Scope):

• On-premise IT infrastructure
• Hybrid (on-prem + cloud)
• Multi-cloud (AWS, Azure, GCP, and others)
• SaaS-as-a-platform

Regulatory and Compliance Context (examples):

• Zero Trust security architecture
• GDPR, HIPAA, SOX, PCI-DSS, and other regulatory frameworks
• Industry-specific governance (financial services, healthcare, government)

Key Assumptions:

• Identity and access governance are strategic, not tactical
• A reference architecture guides—it does not prescribe—implementation
• Different enterprises will implement capabilities in different ways, at different paces
• Maturity of IAM capabilities exists on a spectrum (not binary on/off)
• AI will increasingly assist with discovery, remediation, and monitoring

Out of Scope (handled separately or by other frameworks):

• Detailed technology product evaluations
• Step-by-step implementation procedures
• Organization-specific policies and procedures
• Specific regulatory compliance mappings (though examples are provided)

 

Intended Audiences

Enterprise Architects & Security Architects

• Use the RA to align IAM capabilities to business strategy
• Reference deployment patterns for your environment model
• Use maturity model for gap analysis and road mapping

CISO and Security Leadership

• Use the RA to understand current posture against best practices
• Reference governance and operating model sections for accountability
• Use metrics/KPIs to track progress toward strategic objectives

IAM Platform Owners and Program Managers

• Use the RA as a design baseline for platform evolution
• Reference adoption playbook for phased implementation
• Use maturity model to prioritize capability investments

Application and Service Owners

• Reference “app onboarding” patterns and integration expectations
• Understand how your applications integrate with IAM layers
• Use the adoption playbook for migration planning

Auditors, Risk, and Compliance Teams

• Use the RA to assess control coverage and maturity
• Reference governance model for accountability and RACI clarity
• Use metrics/KPIs for compliance posture reporting

 

How to Use This Reference Architecture

As a Capability Checklist:

• Review each layer (Interact, Access, Change, Repositories, Analytics, Manage) and associated capabilities
• Assess which capabilities your organization currently has, partially has, or lacks
• Flag high-risk gaps (especially in Access, Change, and Analytics layers)

As a Design Review Baseline:

• When evaluating new tools, projects, or architecture changes, reference this RA
• Ask: “Does this design align with the reference patterns and principles?”
• Document intentional deviations and their business justification

As a Maturity and Roadmap Guide:

• Use the maturity model (Section 15) to place your organization on a 1–5 scale per capability area
• Identify “quick wins” (low-effort, high-impact improvements) and “strategic bets” (longer-term transformation)
• Prioritize initiatives that address multiple capability gaps simultaneously (force multipliers)

As a Vendor and Partner Discussion Framework:

• Use the capability model to clarify requirements and expectations with vendors
• Ask vendors: “Which capabilities does your platform deliver, and at what maturity level?”
• Shift the conversation from “What do you sell?” to “What do we need to buy?”

 

What Are Reference Architectures?

Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. They provide:

• A common vocabulary and set of definitions
• Reusable design patterns and building blocks
• Industry best practices and proven approaches
• A baseline against which to compare and assess

Importantly: Reference Architectures are not solution designs and are not meant to be implemented directly. Rather, they guide more concrete efforts. They provide structure and language so organizations do not have to reinvent the wheel.

Six Reasons to Use Reference Architecture

1. Understanding a Domain
   Reference architectures provide a starting point for enterprise architecture efforts. They offer a basic vocabulary and structures, eliminating the need to reinvent from scratch. You gain knowledge transfer from the research and consulting experience embedded in the architecture.
2. Supporting Interoperability
   In an increasingly networked world, organizations must connect and cooperate with many parties. Standards and building blocks provided by reference architectures facilitate these connections. Standardized components are easier to exchange and integrate, improving flexibility and reducing integration costs.
3. Enabling Digital Transformation
   For many enterprises, transformation means redistributing value chains among partners, service providers, and customers. When all parties speak the same language, use the same standards, and recognize the same functional boundaries, it becomes much easier to recombine elements in new ways. A reference architecture serves as a shared mental model.
4. Facilitating Measurement
   Often, differences between organizations are not in process design but in execution. Reference architectures make it much easier to compare progress, metrics, and execution results with peers and benchmarks. You can measure: “How mature are we on SSO adoption?” “What percentage of apps use our standard authentication pattern?”
5. Supporting Regulatory Compliance
   Reference architectures are often prescribed—or strongly recommended—by regulators. For example, GDPR mandates privacy protection principles and practices. Using a reference architecture that embeds compliance thinking makes it easier to audit, report, and demonstrate adherence to regulatory requirements.
6. Controlling Vendor Relationships
   A well-defined reference architecture describing capabilities and capability combinations (patterns) allows you to evaluate and select vendors based on your requirements, not on what vendors tell you to need. This shifts the dialogue from vendor-led to buyer-led. You can tell vendors: “This is what we need to deliver,” rather than accepting: “This is what we’re selling.”

 

IAM 2.0 Vision and Principles

Core Vision

IAM 2.0 envisions identity as an intelligent, distributed fabric that:

• Supports granular, policy-driven access decisions for all subjects (human and non-human) and resources
• Leverages AI and machine learning to automate discovery, governance, and remediation
• Operates across hybrid, multi-cloud, and on-premises environments with consistent governance
• Balances security, privacy, and user experience through elegant interfaces and frictionless access
• Continuously adapts to new threats, regulatory changes, and business needs through feedback loops and AI learning

 

Core Principles

1. Identity is the Common Denominator
   In a perimeter-less world, identity is the foundation for all security decisions. Every subject (human, AI agent, service account, device) must be verifiable, and every access decision must consider identity alongside context and risk.
2. Zero Trust
   Do not trust by default. Verify every access request through:

• • Robust authentication (multiple factors, phishing-resistant)
  • Context-aware authorization (real-time risk signals)
  • Continuous verification (not one-time at login)
  • Least-privilege provisioning (just enough access for the task)

3. Least Privilege
   Grant the minimum access necessary to perform a specific task, for the minimum duration required. Eliminate standing access where possible. Default to “deny” and explicitly grant only what is needed.
4. Governance as Code
   Encode identity policies, workflows, and rules as code (or code-like artifacts) that can be versioned, tested, deployed, and audited like any other infrastructure. This enables consistency, auditability, and rapid evolution.
5. AI-Assisted (Not AI-Driven)
   AI is a powerful tool for automating tedious, repetitive tasks (access reviews, role recommendations, anomaly detection). However, humans remain accountable for governance decisions. AI provides recommendations; humans approve, refine, and escalate as needed.
6. Privacy by Design
   Identity data is sensitive. Implement:

• • Data minimization (collect and retain only what is necessary)
  • Consent management (respect user choices about data use)
  • Subject rights (right to access, correct, delete identity data)
  • Data residency and localization where required

7. Interoperability and Standards
   Use open, standardized protocols (SAML, OIDC, OAuth 2.0, SCIM) and APIs. Avoid vendor lock-in. Enable ecosystem partners to integrate cleanly.
8. Continuous Improvement
   Identity governance is not a “set and forget” activity. Continuously:

• • Monitor metrics and KPIs
  • Incorporate lessons learned from incidents and audits
  • Adapt to emerging threats and regulatory changes
  • Refine policies and processes

Conceptual IAM 2.0 Model

Before diving into layers and capabilities, it’s helpful to establish a simple, technology-neutral conceptual model of how IAM 2.0 operates.

Core Components and Trust Relationships

1. Subjects
   Entities requesting access:

• • Human subjects: Users, administrators, partners, customers
  • Non-human subjects: Service accounts, containers, IoT devices, AI agents

2. Resources
   Things being accessed:

• • Data: Databases, files, cloud storage
  • Applications: SaaS, on-prem apps, APIs
  • Infrastructure: Compute, network, security appliances
  • Devices: Endpoints, IoT devices, servers
  • Facilities

3. Identity Providers (IdPs)
   Systems that authenticate subjects and issue credentials:

• • Enterprise directory (AD, Okta, Entra ID)
  • Workforce IAM platforms
  • Federated partners
  • Blockchain/decentralized identity systems

4. Policy Decision Points (PDPs)
   Systems that evaluate access requests against policies:

• • Authorization engines
  • Conditional access services
  • Risk engines
  • Policy repositories

5. Policy Enforcement Points (PEPs)
   Systems that intercept access requests and enforce decisions:

• • Application login screens or “dashboards”
  • API gateways
  • Network access controls
  • Cloud IAM services (AWS IAM, Azure RBAC, GCP IAM)

6. Trust Zones
   Logical boundaries within which different trust assumptions apply:

• • Corporate network (high trust, known devices)
  • Internet/untrusted (zero trust, adaptive auth required)
  • Partner/federated (medium trust, federation protocols)
  • Cloud-managed (delegated trust to cloud provider)

 

Trust Flow (Simplified)

The simplified IAM “trust flow” is illustrated below. Following this illustration are some example use cases that rely on such a trust flow.

Figure 1: Simplified IAM Trust Model

Key Use Cases

User Login to SaaS Application:

1. User navigates to app
2. App redirects to IdP (OIDC/SAML)
3. IdP authenticates user (MFA if risk-based rules apply)
4. IdP issues credential token
5. App requests authorization from PDP: “Can this user do action X on resource Y?”
6. PDP evaluates user attributes, role, risk score, time-of-day, location
7. PDP returns decision (approve/deny)
8. App enforces decision (grant or deny access)
9. Analytics layer logs access event for audit and anomaly detection

 

Service Account Accessing Cloud Infrastructure:

1. Service account requests temporary credential from IdP/secrets management
2. IdP verifies account identity and checks policy (JIT rules, time-bound access)
3. If approved, IdP issues short-lived credential (minutes/hours, not persistent)
4. Service account uses credential to call cloud API
5. Cloud API’s PEP checks credential and asks PDP: “Is this principal allowed to perform this action on this resource?”
6. PDP evaluates principal attributes, CIEM policies, risk signals
7. PDP returns decision
8. Cloud API enforces decision
9. Analytics layer monitors usage, detects unused permissions, recommends remediation

 

AI Agent Querying Enterprise Data:

1. AI agent requests access to query customer database
2. Agent’s identity is verified (not a common pattern yet; evolving)
3. PDP evaluates: agent’s role, intended data, purpose, risk signals, regulatory constraints
4. If approved, PDP issues fine-grained authorization (row-level security, cell-level masking)
5. Agent queries database with masked/filtered results
6. Analytics layer monitors agent’s data access, flags unusual patterns
7. AI administrative companion reviews access, flags policy violations, recommends remediation

 

TechVision Research IAM 2.0 Reference Architecture

The TechVision Research Reference Architecture 2.0 for IAM is a master template that identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. We will dive into the multiple layers of business and technology capabilities in the next sections.

Business Capabilities Framework

The Reference Architecture starts with business requirements, not technology. The following diagram shows how business questions map to IAM capability areas:

Figure 2: TechVision IAM Reference Architecture master template

Key Insight: These layers exist in nearly all IAM systems to varying degrees. The Reference Architecture helps you assess maturity of each capability and identify gaps.

Next, we drill deeper into the specific IAM and IGA capabilities that comprise the Combined Portfolio Architecture.

Combined Portfolio Architecture

Once business capabilities are identified, the next level of the IAM 2.0 Reference Architecture explores each layer in detail, listing specific technical and process capabilities within each.

Figure 3: TechVision IAM Reference Architecture Combined Portfolio

Each of these layers and related capabilities are detailed in the following sections.

Reference Deployment Patterns

The IAM 2.0 capabilities described in this architecture can be deployed across different environments and topologies. Below are three common reference patterns:

On-Premise–Centric Deployment

Characteristics:

• Traditional AD/LDAP as authoritative identity source and primary directory
• Enterprise IAM/IGA platform deployed on-premises or managed on-prem
• Most applications and data reside on-premises
• Some SaaS applications (but minority)
• Network-based federation for external partners

 

Typical Layer Placement:

• Interact: On-prem IAM portal, on-prem APIs, some cloud APIs to SaaS
• Access: On-prem AD as primary IdP, some cloud IdP connectors, PAM on-prem
• Change: On-prem lifecycle/IGA platform, on-prem workflows
• Repositories: On-prem AD/LDAP as primary, on-prem IGA directory, enterprise directory virtualization
• Analytics: On-prem SIEM/analytics, some cloud analytics for cloud apps
• Manage: On-prem IAM admin portal

 

Use Cases:

• Large enterprises with significant legacy infrastructure
• Regulated industries requiring on-premises data residency
• Manufacturing, utilities, financial services with stable core systems

 

Challenges:

• Limited ability to leverage cloud-native services
• Complexity in federating with SaaS and cloud services
• Requires ongoing on-premises infrastructure investment

 

Hybrid Deployment

Characteristics:

• Shared identity sources (AD, cloud IdP, both in sync)
• Mix of on-premises and cloud applications
• Both SaaS and custom cloud apps
• Federated trust between on-prem and cloud
• Growing cloud workload percentage

 

Typical Layer Placement:

• Interact: Hybrid (on-prem portal + cloud SaaS UX), hybrid APIs (on-prem + cloud)
• Access: Dual IdP model (AD + cloud IdP, synchronized) with federation
• Change: Hybrid IGA (on-prem core + cloud IGA for cloud apps)
• Repositories: Hybrid (on-prem AD + cloud directory, synchronized via SCIM or directory sync)
• Analytics: Cloud analytics with on-prem log forwarding, hybrid SIEM
• Manage: Hybrid management (on-prem admin console + cloud admin consoles)

 

Use Cases:

• Most large enterprises today (cloud adoption underway)
• Organizations with cloud migration roadmaps
• Multi-cloud or multi-vendor scenarios

 

Challenges:

• Synchronization complexity between on-prem and cloud sources
• Governance consistency across hybrid boundaries
• Requires dual-platform expertise

 

Cloud-Native / SaaS-First Deployment

Characteristics:

• Cloud identity provider (e.g., Okta, Entra ID, Ping Identity in cloud) as primary
• Most applications are SaaS or cloud-deployed
• Limited or no on-premises infrastructure
• Federated trust with partners and contractors
• Cloud-first security and governance

 

Typical Layer Placement:

• Interact: Cloud UX, cloud APIs, web-based portals, cloud chatbots/agents
• Access: Cloud IdP (Okta, Entra ID), cloud MFA, cloud conditional access, cloud PAM
• Change: Cloud IGA platform, cloud workflows, cloud provisioning
• Repositories: Cloud directory (Okta Universal Directory, Entra ID, cloud LDAP proxy)
• Analytics: Cloud security analytics, cloud SIEM integration
• Manage: Cloud admin portal, cloud configuration management, cloud monitoring

 

Use Cases:

• Startups and digital-native companies
• Cloud-first enterprises (AWS, Azure, GCP primary)
• Organizations shedding legacy infrastructure

 

Challenges:

• Vendor dependency (cloud provider or cloud IAM vendor)
• Potential complexity in supporting on-prem legacy apps
• Requires cloud security and cost management discipline

 

Architecture Layers and Capabilities (Detailed)

[This section continues with the detailed layer descriptions from your original document: Interact, Access, Change, Repositories, Analytics, Manage. For brevity in this outline, I’ll note that all original detailed content from Figures 5–9 and associated subsections should be included here, with no edits—your original content is excellent.]

Interact Layer

Figure 4: Interact Layer Capabilities

The Interact Layer comprises multiple types of interfaces enabling users, agents, and systems to establish connectivity with the IAM infrastructure. Typical capabilities include:

1. Self-Service UI – Intuitive interface for users to manage attributes, request access, and for admins to review approvals
2. Chatbot – Conversation-based interface for user registration and simple anomaly resolution (e.g., password reset)
3. AI Agents – Autonomous reasoning and task orchestration via agentic AI and LLMs
4. IVR – Touch-tone and voice-based access to IAM functions
5. Robotic Process – Automated task execution for repetitive IAM operations
6. APIs – Programmatic interfaces for embedding IAM functions in applications
7. Messaging Events – Event subscriptions enabling real-time notifications
8. ETL – Batch file processing for bulk user registration/deregistration
9. CLI – Command-line interface for administrative tasks

 

Access Layer

Figure 5: Access Layer Capabilities

Again, the Access is the layer that answers the “Who has access to what?” question. It ensures customers can confidently exchange information and get the services they need to buy and use your products. It ensures employees and partners have all the digital resources they need to get the job done, nothing less and nothing more. Its principal categories of capabilities are centered on authentication and authorization, described below.

Authentication

Authentication can and should often enable “adaptive”, or “step up authentication”, which enables the enforcement of additional authentication steps based on risk factors associated with the resource the entity is attempting to access, which may include the entity’s current geo-location, device, sensitivity of the information being accessed, etc. These entities can be people as well as AI agents, robotic processes and other forms of non-human subjects.

Adaptive Authentication includes the following processing elements:

1. Password management – the ability to reset user passwords and change/update user passwords via self-service interfaces.
2. Multi Factor authentication (MFA) – requires end user or endpoint to provide 1. Something they know (e.g., PIN or password); 2. Something they have (e.g., registered mobile device); 3. And possibly something they are (e.g., fingerprint, voiceprint, iris scan…) when authenticating to applications, networks or services.
3. Password-less authentication – a form of authentication that replaces the password with a more secure and manageable alternative, such as multi-factor authentication, biometrics, passkeys or secure verifiable claims within the decentralized identity model.
4. Biometrics – typically fingerprint, iris scan, facial recognition, voice recognition that can be used to better ensure the end users are who they claim to be.
5. Federation/Single Sign On – the ability to authenticate to multiple applications and systems with a single authentication event.
6. Access token management – access tokens are used in token-based authentication to allow an application to access the IAM API. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target IAM API.
7. Access key management – involves the monitoring and recording of each key’s access, use and context.
8. Certificate management – the capability to manage digital certificates that can be propagated to devices, workstations, network devices and so forth. Includes ability to revoke certificates when necessary.
9. App secrets management – refers to the tools and methods for managing digital authentication credentials (i.e., “secrets”), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
10. Remote Access and VPN Authentication – provides the ability to access a network, computer or device from any remote location, either using a Virtual Private Network (VPN) client or other VPN-less security protocols.
11. Verifiable Credentials– leverages the identity metasystem that uses credential exchange as the unifying protocol for exchanging identity data and to verify the claim being made from an authoritative source.

 

Authorization

Authorization matches risk with request by evaluating additional environmental conditions, using “risk scores” as a factor in dynamically determining authorization decisions. Using real-time data and signals from related security infrastructure supports the ability to provide “adaptive authorization”, comprised of the following processing elements:

1. Front-end App Dashboard – the user interface that is similar to the ‘portal’ method of providing the applications a user can access on a single screen.
2. Fine-grained authorization – enables object level security. For data stored in tables, it means row-level or cell-level security, for data or metadata entered in forms, it means field-level security, and so on. This capability relies primarily on an attribute-based access control system (ABAC), also known as a policy-based access control (PBAC) system, where attributes associated with a user or action or resource are inputs into the decision of whether a given user may access a given resource in a particular way. Note that role-based access control (RBAC) can also be implemented as a specialization of ABAC. Fine-grained authorization systems typically involve a PEP and PDP. The PEP (Policy Enforcement Point intercepts a user’s, application’s or device’s access request to a resource, makes a decision request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision. The PDP (Policy Decision Point) therefore evaluates access requests against authorization policies before issuing access decisions. The PDP often interfaces with the IAM directory, called the Policy Information Point (PIP) to access information about the user or device in question in order to inform its decision-making process.
3. Coarse-grained Authorization – only allows one level of access.
4. JIT (Just-In-Time) Access – the ability to grant privileged access on-demand, subject to policy and for a specific set of purposes and time period, using the entity’s enterprise ID. Often integrated with MFA to enforce stronger authentication for administrative tasks. The JIT Privileged Access Management (PAM) is a strategy that aligns real time requests for usage of privileged accounts directly with entitlements, workflow, and appropriate access policies. Companies use this strategy to secure privileged accounts from continuous, always-on access by enforcing restrictions based on behavioral and contextual parameters.
5. Zero Standing Privileges (ZSP) – beyond administrative accounts, typical end users and systems have no permanent administrative access but instead receive temporary permissions only when needed for specific tasks, then automatically revoked, aligning with Zero Trust principles to significantly reduce the attack surface and risk of privilege misuse.
6. Remote Access Authorization – evaluates whether access should be granted over a remote network connection, such as via VPN.

 

To support Adaptive Authorization, enterprises can (and should) deploy an “AI administrative companion”, which is an agent that can evaluate the organization’s Conditional Access policies, flags any policy gaps, suggests optimizations, and helps keep policies aligned with Zero Trust best practices. The agent evaluates the organization’s existing conditional access policies against the enterprise’s Zero Trust best practices, including enforcing MFA, blocking legacy protocols, requiring device-based access, and reducing policy redundancy.

The conditional access agent can also flag gaps, suggest improvements, and automatically create new policies in “report-only mode” so they can be safely previewed before enforcement. As the environment evolves, the agent continuously checks for “drift”. For example, it will spot any newly added users or applications that aren’t yet covered by an existing conditional access policy. It can also look for opportunities to merge any overlapping or redundant policies, helping to simplify the policy landscape without weakening protection.

These kinds of optimizations used to require tedious manual reviews, but now they’re surfaced automatically as part of each agent run. Agentic AI assistance can elevate an organizational identity threat security posture dramatically by “backfilling” the many tedious tasks formerly requiring human administrators – and subsequently left undone. Note, however, this is not to say that the agent can be held accountable, but that the human administrator can accomplish much more by relying on the agent to provide him or her with the right information at the right time to make accurate decisions.

Federation

Federation occurs when a proxy acts as a broker and authentication protocol translator for applications and other resources, enabling single sign-on (SSO) to applications across multiple internal and external domains. The following processing elements are involved in supporting these capabilities.

1. Federated SSO – established when a user is successfully authenticated to their domain / Identity Provider (IDP) and then is able to access applications in other domains by virtue of a header token that contains assertion information about the authenticated user, typically in the form of OpenID Connect (OIDC), OAuth 2 or Secure Assertion Markup Language (SAML) protocols.
2. Federated Cross-Domain Authorization – established with trust between multiple organizations (inter-organizational) to authorize each other’s users. Again, this is typically accomplished via federation protocols such as OIDC, OAuth2 or SAML. Note this approach can also be practiced inside an organization (intra-organizational) so that the user can access resources (different web properties and applications) within an organization. This method can be useful in very large, geographically dispersed organizations.

 

Privileged Access

Privileged Access – used to control access to privileged accounts by controlling the administrative session; facilitates session isolation, session recording and command filtering. The following process elements are included when PAM is required.

1. Session Management – privileged session management refers to the monitoring, recording and control over privileged sessions.
2. App Secrets Management – refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
3. Password Vaulting – a password vault is a system that stores passwords for various privileged accounts in a privileged account management system. Passwords are ‘checked out’ at the start of a privileged administration session and not able to be shared among multiple administrators. When the privileged session is completed, the passwords are rotated within the vault so that the next time an administrator requests access, a different password is provided for the new session.
4. Zero Standing Privileges (ZSP) – beyond administrative accounts, typical end users and systems have no permanent administrative access but instead receive temporary permissions only when needed for specific tasks, then automatically revoked, aligning with Zero Trust principles to significantly reduce the attack surface and risk of privilege misuse.

 

Change Layer

Lifecycle Management Figure 6: Change Operations Layer Capabilities

Change manages the relationships between all the moving parts within the digital environment. Change establishes the connections between people, devices, applications, and data when they enter the environment, manages the connections while the relationship exists, and disconnects when access is no longer necessary.

AI supports these capabilities through enforcement of entitlement management, lifecycle workflows, provisioning, privileged access management, cloud infrastructure entitlement management services, runtime authorization, as well as authentication, MFA, SSO and verifiable credential services. Let’s look at some of these key Change Operations capabilities in more detail:

Identity Lifecycle Management is the process of managing identities through their lifecycle (i.e., Join, Move, Leave) and relationship with the organization.

1. Join, Move, Leave – events that indicate that a person (or agent or thing) has joined the organization (Join) or changed jobs/functions/roles/locations, etc. (Move) or has left the organization (Leave). Such events can be detected on authoritative source systems such as HR, Contractor Management systems and so forth, and the events can trigger workflows, notifications, access right changes, entitlement updates, account disablement, and more depending on the rules associated with the IAM provisioning service listening for these events.
2. Identity Proofing – various forms of required proof that someone is who they say they are that are reviewed and verified before an account can be created/provisioned across the IAM-connected systems and applications.
3. Profile Management – the ability to manage one’s set of attributes associated with his/her/its digital identity.
4. Verifiable Credentials – represent identity systems and services that are controlled, managed by the individual on a decentralized basis and sometimes built on blockchain/distributed ledgers. They often integrate a verifiable claims infrastructure to support the exchange of trusted credentials associated with the decentralized identifier.

 

Access Administration

Account administration contains the capabilities associated with creating, modifying and deleting/disabling computer/network/application user (or device) accounts.

1. Access Request and Approval – workflows that facilitate any approval processes that may need to be enacted as part of an access request fulfillment. Access requests may be initiated through a self-service identity registration process, a delegated administrator request or an event trigger listening for changes on an authoritative source system such as HR.
2. Access Provisioning – automates the steps required to set up the required accounts and entitlements and fulfill any required changes on one or more connected systems or applications, such as the enterprise network, Google Suite, Active Directory and so forth.
3. Birthright Access – the set of entitlements someone (or something) can be granted immediately, without requiring workflows and approvals.
4. Time-bound Access – policy that grants access for a specific period of time.
5. Group Management – the ability to create and manage static and dynamic groups of accounts that are associated with runtime access control decisions.
6. Policy-based Access – using policies based on a set of rules, to decide on authorization.
7. Self-Service Administration – the capability to manage one’s own profile or request access to specific resources, typically through the Self-Service UI.
8. Delegated Administration – the capability for an administrator to manage a user’s or thing’s profile, request access or based on policy, approve access. This is performed typically through a version of the Self-Service UI that is tailored to the administrator’s view.
9. RBAC, ABAC – Role Based Access Control (RBAC) associates one or more enterprise roles with an account, while Attribute Based Access Control (ABAC) associates one or more attributes within an account’s profile – in both cases this information is used during runtime authorization decisions.

 

Identity Governance

1. Access Review and Re-Certification – a process by which an organization reviews and verifies the appropriateness of access privileges.
2. Entitlement Catalog – a method for organizing and entitlement definitions and mappings, listing what is assignable, describing what these entitlements actually do; facilitates entitlement ownership and accountability.
3. Access Risk Management – the overall management of access risk and actions or permissions that, when available to a single user (or single role, profile, or HR Object), creates the potential for fraud or unintentional errors.
4. Predictive / Autonomous Governance – uses artificial intelligence (AI) and machine learning (ML) to recognize and act on access rights and entitlements in relation to policy.
5. Access Policy Violation and Remediation – similar to predictive/autonomous governance, acts on existingentitlements that appear to violate policy by fixing the issue without direct human interaction.
6. Segregation of Duties – an internal control to mitigate risk by having different individuals handle different tasks.
7. Closed-loop Remediation – direct revocation of roles/entitlements from the provisioning system, often used in conjunction with Zero Standing Privileges (ZSP) capabilities.
8. Dormant Access Discovery and Suspension – uses a crawling mechanism to discover accounts and access privileges that have not been used in a specified period of time and – based on policy, suspend the access privileges until further admin or user intervention.

 

Privileged Access Governance

1. Privilege Definition – the aspect of defining what systems require administrator access and what the specific privileges are, based on specific criteria regarding a number of variables, including who, what, when, where and why.
2. JIT Privileged Access Granting – a least-privilege security model that requires users, processes, applications, and systems to have just enough rights and access—and for no longer than required—to perform a necessary action or task. Eliminating persistent privileged access for privileged user accounts—and activating it only for the duration it is needed to perform an activity is the objective of JIT PAM.
3. Privileged Access Discovery and Reduction – uses a crawling mechanism to discover admin accounts and access privileges that are in violation of policy and removes the access privileges until further intervention.

 

Identity Repositories Layer

Figure 7: Identity Repositories Layer Capabilities

The Identity Repositories Layer refers to the shared place where the identity profiles, attributes, and relationships are stored and maintained. It may be physically centralized or distributed and contains the map which defines “who has access to what?”, often in the form of an entitlements catalog and enterprise directories.

IAM and IGA administrative agents can monitor the integrity of identity stores to ensure no identity data tampering is occurring. Identity Repository Layer capabilities include:

1. Directory Management – maintaining a persistent, scalable view of the common identity information that is easily referenceable from other components within the IAM architecture; manages the identity object and attribute stores (i.e., directories), manages the directory database schema and hierarchy.
2. Directory Virtualization – a method for instantiating identity correlation and aggregation in lieu of persistent data synchronization between source and target systems; is the cornerstone of an Identity Data Service.
3. Identity Correlation and Aggregation – the ability to automatically match and associate multiple identities across multiple, disparate, connected systems; allows for a single logical view of these associated identities spanning all connected systems.
4. Identity Profile Propagation – maintaining a persistent, scalable view of the common identity information; easily referenceable from other components within the IAM architecture.
5. Identity Data Customized View – the ability to control or limit what a user or application sees when querying the IAM directory infrastructure; may also support data transformation to tailor the view to the specific application’s requirements.
6. Authoritative Identity Data Source Enrichment – refers to a bi-directional data integration mechanism that allows certain IAM attributes to be identified as the authoritative source for the data, that can then be synchronized back to the original authoritative source database.

 

Identity Analytics Layer

Figure 8: Identity Analytics Layer Capabilities

The Identity Analytics Layer is where we enable the runtime and stored analysis lens into the digital environment. It is how we instantiate the Risk Engine that supports “live” behavior observation, anomaly detection, platform health checks, and deeper analysis of usage and threats. It also provides the audit and reporting capabilities necessary to prove you are performing your duty to protect. This allows the enterprise to:

• Understand behavior to improve user experience balanced with enterprise risk management.
• Detect vulnerabilities before they are crises.
• Prove compliance as required by law.

AI supports these capabilities via the agent-enabled runtime adaptive authentication and authorization capabilities within the IAM and IGA ecosystem. Capabilities include:

1. Access Monitoring and Reporting – on-going surveillance and reporting to ensure that inappropriate access is not occurring and that the results are logged.
2. Access Policy Analysis and Recommendations – reviewing, analyzing and making recommendations with respect to access policies.
3. Trust Scoring – a trust engine establishes a trust score for an actor (e.g., user, device) based on many factors. An example might include having a user or devices trust score adjusted negatively because the actor is exhibiting behaviors that are well outside of an established baseline.
4. Risk Scoring – dynamically evaluates risk of a given operation based on current environmental factors and filters access to operations if the risk level exceeds the accepted threshold. The risk engine incorporates elements of the risk management framework and threat intelligence to calculate a risk score for each asset on the network. Factors that are taken into account include data classification, vulnerabilities found, and the controls that are applied to an asset. Together an actor’s trust and risk score determine if the authorization request is within defined tolerances for the organization. The policy repository is where baseline policies are managed and stored. The policy repository can also serve as a historical record of baseline policy changes and the policy changes made for each entity.
5. User Entity Behavior Analysis – (UEBA) uses machine learning and deep learning to learn how users and other entities on the corporate network typically behave, detect abnormal behavior, outlier access attempts (e.g., outside the ‘norm’) and figure out if this behavior has security implications. This information is fed in real-time to the PDP to provide relevant information to the runtime access decision. The goal is to identify abnormal behavior, determine if it has security implications, and alert security teams.
6. Identity Threat Detection and Remediation (ITDR) – reviews access entitlements in concert with segregation of duties (SoD) requirements to uncover SoD violations and recommend remediation via workflow or autonomously remediate. It focuses on perpetual analysis of the organizational entities’ access permissions in concert with the lifecycle of the entitlement assignments and policy definitions. This process will also help reduce the attack surface by removing unused entitlements from entities’ profiles; and can assist in identifying entity logins that do not have an entitlement to go further into the application. This will provide more access granularity to prevent entities from being able to view anything that doesn’t pertain specifically to their current assigned entitlements – which is key from the security and compliance perspective.
7. Approval Review and Recommendations – reviews workflow approvals for access requests – whether initiated by self, administrator or authoritative source system and evaluates risk of approval in conjunction with SoD policy. If deemed risky, recommends alternatives to Approver and application owner.
8. Access Recommendations – a method of governance decision making that leverages AI, ML and predictive data to make recommendations regarding appropriate access for a specific user, device, role, etc.
9. App Access Trend Analysis – monitors the access privileges being granted to users and devices, based on specific criteria, and provides trend reports to help with IAM access policy refinement.
10. IAM QoS Trend Analysis – measures the Quality of Service being provided by the entire IAM system to determine how well IAM meets Key Performance Indicators (KPIs).

 

Manage Layer

Figure 9: Manage Layer Capabilities

The Manage Layer is IAM system administrators (and their agents) perform Administrative Operations on the IAM/IGA platform to upgrade, configure, tune, troubleshoot, document, and audit the platform and its components.

AI supports these capabilities via the agent-enabled configuration, discovery and management tools within the IAM and IGA ecosystem.

1. Configuration Management – the ability to record changes to the configuration of your Identity and Access Management (IAM) users, groups, and roles (collectively referred to as IAM entities) and the policies associated with them.
2. Process Optimization – the configuration of processes such as workflows and data integration flows.
3. Access Policy Management – the configuration of access policies.
4. App Onboarding Self-Service – the mechanism that app owners can make available / publish their IAM-enabled applications.
5. Data Governance – pertains to how long to archive IAM log data in support of regulatory, legal and privacy compliance, legal.
6. Monitoring and Reporting – the ability to monitor all aspects of the IAM system and report on performance.
7. Auditing and Logging – the ability to log specific activities, such as login, access requests, approvals and so forth in support of audits.
8. Archiving / Purging – the mechanism used to save (archive) specific identity data and IAM activities for a specific period of time, and the subsequent ability to permanently delete such information – usually in accordance with data governance and privacy regulations.
9. Disaster Recovery – the configuration of key IAM subsystems to enable operability in the case of a disaster.

 

In the companion documents to this one, we will look into typical identity data management and integration models that will help you put the finer touches on the overall IAM 2.0 Reference Architecture. To continue, please see “IAM 2.0 Reference Architecture Playbook” and “IAM 2.0 Reference Architecture Roadmap”.

Identity Data and Integration Patterns

Reference Identity Data Model

An effective IAM 2.0 deployment requires a clear, shared identity data model—the “golden record” of who/what entities are and what they’re entitled to do.

Core Entities:

PERSON (Human Subject)

 |── Attributes: Name, Email, Phone, Department, Location, Manager, Hire Date
|── Credentials: Passwords, MFA Devices, Certificates, Passkeys
|── Accounts: AD Account, Cloud Account, App-Specific Account
└── Entitlements: Roles, Groups, Direct Permissions, Effective Permissions

SERVICE ACCOUNT (Non-Human Subject)

 |── Attributes: Name, Application Owner, Purpose, Criticality, Expiration
|── Credentials: API Keys, Certificates, Secrets, Tokens
|── Accounts: Cloud Service Principal, On-Prem Service Account
└── Entitlements: Cloud Roles, On-Prem Privileges, API Scopes

DEVICE / ENDPOINT (Non-Human Subject)

 |── Attributes: Hardware ID, OS, Device Owner, Device Type, Location
|── Credentials: Device Certificates, Hardware-Bound Keys
|── Accounts: AD Computer Object, Cloud Device Object
└── Entitlements: Network Access, VPN Access, Conditional Access Policies

IOT DEVICE / THING (Non-Human Subject)

 |── Attributes: Serial Number, Type, Location, Owner, Status
|── Credentials: Certificates, Tokens, Shared Secrets
└── Entitlements: API Scopes, Data Channel Access

AI AGENT (Non-Human Subject)

 |── Attributes: Agent Name, Purpose, Owner, Scope of Autonomy, Guardrails
|── Credentials: Agent API Key, Signed Assertions
└── Entitlements: Tool Access, API Permissions, Data Access Scope

ROLE (Grouping Entity)

 |── Attributes: Role Name, Description, Lifecycle, Owner
|── Assigned Entitlements: List of permissions granted by this role
└── Rules: SoD rules, conflicting roles

GROUP (Grouping Entity)

 |── Attributes: Group Name, Type (Static/Dynamic), Owner, Purpose
|── Members: People, Accounts, Other Groups
└── Entitlements: Permissions granted to group members

ENTITLEMENT / PERMISSION (Access Grant)

 |── Attributes: Name, Description, Resource, Action, Risk Level
|── Assigned To: Roles, Groups, Individuals (direct assignment)
└── Rules: Time-bounds, context conditions, approval requirements

RESOURCE (Thing Being Protected)

 |── Attributes: Name, Type, Owner, Classification, Location
|── Access Controls: Who can access, under what conditions
└── Audit: Who accessed, when, what actions

Authoritative Sources and Identity Correlation

Authoritative Source Strategy:

Human Identities

 |── Authoritative Source: HR System (Workday, SAP, ADP)
│   └── Attributes Mastered: Name, Email, Department, Manager, Status
|── Secondary Authoritative: Self-Service Profile (for attributes like phone)
└── Propagated To: AD, Cloud IdP, IGA System, All Applications

Service Accounts & API Principals

 |── Authoritative Source: Application Owner Inventory (IT Service Portal)
│   └── Attributes Mastered: Purpose, Owner, Criticality, Provisioning Rules
└── Propagated To: Cloud IAM, On-Prem IAM, Secret Management System

Devices

  |── Authoritative Source: Mobile Device Management (MDM) / Endpoint Management
│   └── Attributes Mastered: Hardware ID, OS, Compliance Status
└── Propagated To: Cloud Conditional Access, Network Access Control

IoT Devices

 |── Authoritative Source: IoT Device Registry
│   └── Attributes Mastered: Serial Number, Type, Location, Firmware Version
└── Propagated To: IoT Platform, Network Access Control

Identity Correlation Process:

When a person has multiple accounts (AD account, cloud account, app-specific account), they must be correlated to a single logical identity for governance and risk assessment.

HR System (Unique ID: EMP12345)

        ↓

    Correlation Engine

    (Matches by email, manager, department)

        ↓

        |── AD Account (CORP\jsmith)
|── Okta Account ([email protected])
|── Salesforce Account ([email protected])
|── AWS IAM Principal (arn:aws:iam::…user/jsmith)
└── GitHub Enterprise Account (jsmith-enterprise)

    Logical Identity Result:

    |── Primary Email: [email protected]
|── Unique ID: EMP12345 (from HR)
└── Correlated Accounts: [AD, Okta, Salesforce, AWS, GitHub]

    One identity ↔ Multiple accounts across systems
Enable unified role assignments and access reviews

Integration Mechanisms

IAM systems integrate with other systems (authoritative sources, applications, data systems) through various mechanisms:

1. APIs (Real-Time, Synchronous)

• • Use case: Real-time provisioning when a user is hired
  • Pattern: HR system calls IAM API; IAM creates account immediately
  • Example: “POST /api/users” with user details
  • Advantage: Immediate, no batch delays
  • Challenge: Requires tight coupling, error handling

2. Messaging/Events (Real-Time, Asynchronous)

• • Use case: Event-driven provisioning across many systems
  • Pattern: HR system publishes “UserCreated” event; multiple systems subscribe
  • Example: Kafka topic “hc.user.created” triggers IAM provisioning
  • Advantage: Loosely coupled, scales to many consumers
  • Challenge: Eventual consistency, requires event schema governance

3. ETL/Batch (Scheduled)

• • Use case: Bulk user imports from HR system
  • Pattern: IAM system scheduled job reads HR export file, processes nightly
  • Example: SFTP CSV file with daily employee updates
  • Advantage: Simple, works with legacy systems
  • Challenge: Not real-time, requires reconciliation

4. Directory Sync (Scheduled, Bi-Directional)

• • Use case: Synchronizing attributes between AD and cloud directory
  • Pattern: Azure AD Connect syncs on-prem AD to Entra ID
  • Example: User updated in AD; attributes synced to cloud within minutes
  • Advantage: Transparent to users, mature tooling
  • Challenge: Sync rules must be carefully managed

5. SCIM (System for Cross-Domain Identity Management)

• • Use case: Provisioning users to cloud applications
  • Pattern: IAM system provisions to SaaS app via SCIM endpoint
  • Example: “POST https://app.example.com/scim/Users” with user details
  • Advantage: Standard, widely supported by SaaS vendors
  • Challenge: Requires SCIM endpoint implementation

 

End-to-End Data Flow Patterns

Pattern 1: Batch Provisioning (Legacy)

HR System

    ↓ (Extract: CSV export daily)

ETL Process

    ↓ (Transform: Normalize attributes, map fields)

IAM System (Identity Repository)

    ↓ (Load: Create accounts, assign roles)

 |── AD
|── Cloud IdP
|── Target Applications
└── IGA System (For governance)

Timeline: T+1 day (next morning)
Risk: Delayed provisioning, manual errors, uncontrolled access

Pattern 2: Event-Driven Provisioning (Modern)

HR System

    ↓ (Event: “Employee Hired”)

Event Bus (Kafka, Azure Service Bus)

    ↓ (Multiple subscribers)

     |── IAM Provisioning Service
│   |── Create AD account
│   |── Create cloud account
│   |── Assign birthright entitlements
│   └──Trigger access request workflow
|──Collaboration Tool (Teams, Slack)
│   └── Create workspace, add to team
|── Badge System
│   └── Provision physical badge
└── HR Analytics
└── Update reporting

Timeline: T+seconds (immediate)
Risk: Higher complexity, but faster provisioning, consistent across systems

Pattern 3: Just-In-Time (JIT) Access

User → Requests Cloud Resource Access

    ↓

Self-Service Portal (Interact Layer)

    ↓

IAM → Evaluates Request

    |── User Identity (Verified via MFA)
|── Resource Risk (Sensitive/High-value)
|── Policy (JIT policy for this role/resource)
└── Approval Workflow (Manager approves)

    ↓

Access Granted (Temporary, e.g., 4 hours)

    |── Cloud Role assigned to user
|── Temporary credential issued
└── Activity logged and monitored

    ↓

Access Expires

    ├→ Credential revoked
└→ Role removed

Timeline: On-demand
Risk: Lower, because access is time-bound and approved

Pattern 4: AI-Driven Discover → Remediate → Monitor

Monitor Phase

    |── Collect logs: User logins, API calls, permission changes
|── Ingest to Analytics: SIEM, identity analytics platform
└── Store in data lake: Historical analysis

    ↓ (Continuous)

Discover Phase

    |──Run access reviews (AI-assisted)
│   └── “User has 50 AWS permissions but only uses 5”
|── Detect anomalies (ML)
│   └── “User accessing resources outside normal working hours
|── Scan permission sprawl (CIEM)
│   └── “Overly permissive S3 bucket policy”
└── Flag SoD violations
└── “User has both Approver + Requester roles (conflict)”

    ↓ (AI-Assisted Recommendations)

Remediate Phase

    |── Manual (Review + Approve)
│   |── Admin reviews AI recommendation
│   |── Approves: “Remove unused permission”
│   └── System removes permission
└→ Automated (Policy + Execute)
|── Policy: “Remove unused permissions after 90 days”
└── System auto-removes without manual step

    ↓ (Loop back to Monitor)

Timeline: Continuous (daily/weekly cycles)
Risk: Proactive, reduces attack surface, faster remediation

Security, Privacy, and Non-Functional Considerations

IAM 2.0 is the foundation for Zero Trust security. However, the IAM platform itself must be hardened against threats and we will identify some of the key considerations for the cybersecurity and privacy teams.

Security Architecture for IAM 2.0

Key Security Considerations:

1. Network Security & Segmentation

• • IAM services should be isolated from general application networks
  • Administrative access to IAM platforms restricted to corporate networks or VPN
  • API endpoints use HTTPS/TLS with certificate pinning where possible
  • DDoS protection and rate limiting on public IAM endpoints

2. Encryption and Key Management

• • Credentials (passwords, tokens, keys) encrypted at rest (AES-256 minimum)
  • Credentials in transit encrypted (TLS 1.2+)
  • Key management system (KMS) for encryption key lifecycle
  • Regular key rotation and secure key backup/recovery

3. Administrative Access Control (PAM for IAM)

• • Administrative accounts to IAM platforms require MFA
  • Session recording for all privileged IAM administration
  • Time-limited, just-in-time access to IAM configuration
  • Separation of duties: IAM admins cannot approve their own requests
  • All admin actions logged and auditable

4. Secrets Management

• • API keys, certificates, and tokens stored in secure secrets vault
  • Automated secret rotation
  • Audit of secret access (who accessed what, when)
  • Revocation mechanisms for compromised secrets

5. Logging and Audit Trail

• • All authentication events logged (success and failure)
  • All authorization decisions and policy changes logged
  • Immutable audit trail (tamper-evident)
  • Centralized log aggregation to SIEM
  • Long-term retention per compliance requirements (e.g., 7 years for financial audit)

6. Threat Detection & Response

• • Monitoring for suspicious patterns: multiple failed logins, unusual admin activity, unusual API usage
  • Alerting and incident response procedures for IAM-specific threats
  • Integration with Security Operations Center (SOC)

7. Software Supply Chain Security

• • IAM platform and components regularly patched
  • Vulnerability scanning of dependencies
  • Secure code review practices
  • Third-party component management (SBOM, license compliance)

 

Privacy and Regulatory Alignment

Identity data is sensitive personal information. IAM 2.0 must respect privacy principles and comply with regulations.

Key Privacy Principles:

1. Data Minimization

• • Collect only identity attributes necessary for access decisions
  • Example: Do not collect employee home address unless required for compliance
  • Regularly audit and remove unnecessary attributes

2. Purpose Limitation

• • Use identity data only for stated purposes (authentication, authorization, audit)
  • Example: Do not use employee identity data for marketing without consent
  • Enforce purpose constraints in data usage policies

3. Consent Management

• • Where required (GDPR), obtain explicit consent for data processing
  • Provide easy opt-out mechanisms
  • Maintain consent records and honor changes

4. Subject Rights

• • Right to Access: Users can request and view their own identity data
  • Right to Rectification: Users can correct inaccurate data
  • Right to Erasure: Users can request deletion (with business justification)
  • Right to Portability: Users can request data in standard format

5. Data Residency and Localization

• • Some regulations (GDPR, Brazil LGPD) require data stored in specific countries
  • IAM system should support geo-fencing of identity data
  • Tenant separation for multi-tenant cloud scenarios

6. Retention and Disposal

• • Define retention periods for identity data (e.g., 7 years for active employees, 2 years post-departure)
  • Automate secure deletion of expired data
  • Audit trails of deletions

 

Regulatory Examples:

GDPR (European Union)

• Requires lawful basis for processing personal data
• Mandates data protection impact assessments (DPIA)
• Requires privacy-by-design in systems
• Supports individuals’ rights to access, rectify, erase, port data

 

HIPAA (US Healthcare)

• Requires audit controls and access controls for protected health information (PHI)
• Mandates minimum necessary access
• Requires breach notification procedures

 

SOX (US Financial Services)

• Requires audit trails for access to financial data
• Mandates segregation of duties
• Requires attestation of access controls

 

PCI-DSS (Payment Card Industry)

• Requires MFA for administrative access to cardholder data
• Mandates access control lists (ACLs) and least privilege
• Requires regular access reviews and re-certification

 

GDPR + Data Privacy Integration into IAM 2.0:

Below is an example of data privacy integration into IAM 2.0:

Identity Data Subject

 |──── Data Collection
│   └── Obtain lawful basis (consent, contract, legal obligation, vital interest, public
|           task, legitimate interest)
|── Processing
│   |── Minimize: Store only attributes needed
│   |── Limit Purpose: Use only for authentication/authorization/audit
│   └── Secure: Encrypt, access control, audit trail
|── Subject Rights
│   |── Access: Provide data export
│   |── Rectification: Update inaccurate data
│   |── Erasure: Delete data (with retention exceptions)
│   └── Portability: Export in standard format
└── Retention & Disposal
|── Set retention period (e.g., active + 2 years post-departure)
|── Auto-delete at end of period
└── Audit deletion events

Quality Attributes and Operational Expectations

An IAM 2.0 platform must meet several non-functional requirements:

1. Availability

• • Target: 99.9% uptime (9 hours downtime/year) to 99.99% (52 minutes downtime/year)
  • Design: Redundant components, load balancing, failover mechanisms
  • Rationale: Identity services are critical; downtime blocks user access

2. Performance

• • Authentication: < 2 seconds end-to-end (login to application access)
  • Authorization: < 500ms PDP decision time
  • Provisioning: < 5 minutes end-to-end (approval to account creation)
  • Rationale: User experience depends on responsive identity services

3. Scalability

• • Concurrency: Support millions of concurrent identity transactions
  • Growth: Linear scaling with load (no performance cliffs)
  • Rationale: Must support enterprise scale and growth

4. Resilience

• • Fault Tolerance: Service continues despite component failures
  • Data Consistency: Identity data remains consistent across replicas
  • Disaster Recovery: RTO (Recovery Time Objective) < 4 hours; RPO (Recovery Point Objective) < 1 hour
  • Rationale: Identity is critical infrastructure; loss has cascading effects

5. Observability

• • Logging: Structured logs of all identity transactions
  • Metrics: Performance metrics (latency, throughput, error rate)
  • Tracing: Distributed tracing of requests through system
  • Rationale: Operational visibility enables troubleshooting and optimization

6. Security Posture

• • Vulnerability Management: Regular patching cycle (critical: < 30 days, others: < 90 days)
  • Penetration Testing: Annual assessment by independent party
  • Security Incident Response: Procedures and training for identity-related incidents

 

IAM 2.0 Leveraging AI

The amalgamation of all these specific IAM / IGA capabilities allows the enterprise digital ecosystem to right-size permissions and enforce the principle of least privilege based on historical usage and activity. It is also able to detect anomalous permission usage using machine learning and AI, and generate detailed forensic reports, which are capabilities sorely needed by security administration and operations. In a nutshell, this ecosystem should address three key use cases: discover, remediate, and monitor.

1 – Discover

• Assess permission risks by evaluating the gap between permissions granted and permissions used for any identity (irrespective of the identity type and origin) across any cloud.
• Analyze granular and normalized metrics for all identities across AWS, Azure, and GCP.
• Track permission risks with an aggregated metric that continuously evaluates the level of risk based on the number of unused or excessive permissions and resources for all identities. This metric is a quantitative measure of risk associated with an identity or role determined by unused high-risk permissions and resources. It allows administrators to instantly evaluate the level of risk associated with the identities and resources.

 

2 – Remediate

Organizations can also “right-size” permissions based on historical usage, grant new permissions on-demand, and automate just-in-time access for cloud resources.

• Automate deletion of permissions unused for the past 90 days.
• Permissions on-demand: Grant identities permissions on-demand (with self-service workflow) for a time-limited period or on an as-needed basis.

 

3 – Monitor

Organizations can detect anomalous activities with machine learning-powered (ML-powered) alerts and generate detailed forensic reports.

• ML-powered anomaly and outlier detections.
• Context-aware forensic reports around identities, actions, and resources to support more rapid investigation and remediation.

In this vein, AI supports a wider range of real-world identity and access scenarios – to help IAM teams investigate, monitor, and respond faster using natural language. In the traditional AI agent sense, administrators can just ask a question, and AI works across the entire enterprise data landscape to bring actionable insights. For example, let’s drill into these 3 use cases in more detail:

Discover: Identity Insights and Investigation

Provide a complete view of users, groups, sign-ins and risk, all in one place:

• Users: Investigate a user’s sign-ins, roles, apps, groups, and permissions.
• Groups: Understand group membership, access paths, and permissions.
• Sign-In Logs: Analyze abnormal or failed sign-ins to detect access issues or suspicious activity.
• Audit Logs: See who made changes to identities, policies, or configurations across the IAM/IGA ecosystem.
• Lifecycle Workflows: Manage onboarding/offboarding workflows and flag issues across joiner, mover, leaver tasks.
• Risky Users: Investigate high-risk users and prioritize remediation.

 

Discover and Remediate: Access Governance and Review

Simplify reviews and reduce excessive permissions:

• Access Reviews: Get summarized recommendations to streamline decisions.
• Entitlement Management: Review access settings and assignments.
• RBAC: Spot over-privileged roles and analyze assignments.

 

Discover and Remediate: App and Resource Protection

Quickly identify risky apps, secure configurations, and improve licensing hygiene:

• App Risk: Investigate app behaviors, detect misconfigurations, and flag risky integrations.
• IAM/IGA Recommendations: Act on best-practice guidance, security alerts, and policy recommendations.
• Enterprise Software License Utilization: Analyze license usage to optimize costs and tie licenses to active identities.

 

Monitoring and Posture Management

Get a clearer view of the enterprise IAM/IGA ecosystem, to help keep it healthy and secure:

• Alerts in Scenario Health Monitoring: Detect risks tied to misconfigurations or coverage gaps.
• Service Level Agreements in System Health Monitoring: Identify performance or reliability issues affecting key identity workflows.
• MFA Auth Methods: Audit usage and enforce phishing-resistant MFA.

In summary, TechVision sees this level of agentic AI “assistance” across the broad spectrum of IAM and IGA capabilities as the key harbinger of IAM 2.0.

With this information, technical architects can rapidly zero-in on the current options (technology and process) their IAM/IGA architecture should encompass to achieve the required capabilities for the business. In the form of architecture considerations, each of the options available is then described in more detail to help identify the right approach for an optimal IAM architecture and deployment strategy. In the subsequent section, we’ll look at sample IAM Reference Architecture patterns and map them to many of the key capabilities enabled by AI.

Patterns: The IAM 2.0 Reference Architecture In Action

Now let’s look at some examples where our customers have deployed various IAM services. We will look at authentication, SSO, runtime access management, IGA, entitlement management and audit/monitoring capabilities in the context of the Reference Architecture for IAM / IGA 2.0.

Standard IAM/IGA Service Pattern

Generically, the IAM/IGA capabilities are used as input to the development of the Reference Architecture pattern illustrated below:

Figure 10: Typical IAM and IGA Service Pattern

It is important to note that much of the overall IAM infrastructure supports or consumes the provisioning and IGA processing output. For example, the “login service” in the upper left corner relies on the IGA policies, birthright access provisioning, workflow and approvals and so on to be able to function appropriately and securely through the “App Dashboard” (PEP, for policy enforcement point) – which interacts during runtime with the access policy repository (PDP, for policy decision point), the Enterprise Directory/Cloud Directory and the entitlements catalog.

Now, let’s look at this IAM architecture pattern when the enterprise determines that it wants to leverage AI to grow or strengthen existing IAM/IGA deployments.

IAM 2.0 Pattern with AI Capabilities

Below is an illustration of the Enterprise IAM and IGA Reference Architecture embedding AI functions:

Figure 11: IAM 2.0 Reference Architecture Using AI Capabilities

As this modified pattern shows, the standard or required IAM and IGA capabilities as defined by our Reference Architecture are supported and enhanced with AI.

The administrative and self-service interfaces along with the associated service request/response workflows are enhanced with AI, along with automated discovery, recommendations, and remediation.

This is also the area where agentic AI is registered and managed, providing the authoritative source of all AI agents deployed across the enterprise. The discovery process will assist in keeping this agent registry accurate and up to date.

When overlaid with AI, the robust set of IAM 2.0 capabilities become more scalable, manageable and reliable. In other words, with so many “moving parts” in terms of capabilities, the inclusion of AI to meaningfully assist in the deployment, maintenance and further refinement of the architecture is substantially valuable.

With this information, technical architects can rapidly zero-in on the current options (technology and process) their IAM architecture should evaluate to achieve the required capabilities for the business. In the form of architecture considerations, each of the options available is then described in more detail to help identify the right approach for an optimal IAM architecture and deployment strategy. As such, the TechVision Research Reference Architecture for IAM 2.0 is a comprehensive ‘checklist’, a methodology to break down the business capabilities a client is endeavoring to facilitate, coupled with the technology and process necessary to achieve its objectives.

Conclusion

Identity management is the foundation enabling the 21st-century Digital Enterprise. The ability to govern identities—of every user, device, and asset—across cloud, on-premises, and hybrid environments is now critical.

IAM 2.0 represents a shift in how organizations approach identity governance:

• From Static to Dynamic: Conditional, risk-based access decisions in real-time
• From Manual to Automated: AI-assisted discovery, remediation, and monitoring
• From Centralized to Distributed: Identity fabric spanning hybrid/multi-cloud while maintaining consistency
• From Reactive to Proactive: Continuous monitoring and anomaly detection prevent incidents before they occur
• From Isolated to Integrated: Identity as a service that other security, compliance, and business systems consume

 

Getting There:

Start with a structured approach:

1. Organize business requirements around identity using this Reference Architecture
2. Tie requirements to specific capabilities and maturity levels
3. Identify current-state strengths and gaps using the maturity model
4. Prioritize using risk and impact analysis, grouping into waves
5. Measure progress using KPIs and metrics
6. Refine continuously based on lessons learned, incidents, and regulatory changes

 

The IAM 2.0 Reference Architecture is a tool to guide this journey. It provides a common vocabulary, reusable patterns, and a maturity framework that your organization can customize to your specific needs.

With this structured approach, you can evolve IAM from a bottleneck into an enabler of digital transformation and business agility.

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative.

Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions.

We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

 

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include:

Identity and Access Management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

Prior to starting TechVision Research he was President of Burton Group from 1999 to 2010, the leading technologyinfrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President (now Gartner for Technical Professionals) at Gartner.

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

Gary Zimmerman is an experienced executive known for helping companies deliver new offers and expand markets. Accomplishments include launching four companies, 20+ products, building high-performance organizations, and generating millions in sales.

His experience at Neustar, Respect Network, and Sovrin allows him to provide a broad perspective on a variety of subjects including self-sovereign identity, blockchain, enterprise data management, and the data brokerage industry.  His experience in both enterprise and startup product development gives him a unique perspective on the application of new technologies.

Appendices

Appendix A: Glossary of Terms

• ABAC: Attribute-Based Access Control
• AI Agent / Agentic AI: Autonomous software that reasons and acts without constant human supervision
• CIEM: Cloud Infrastructure Entitlement Management
• CISO: Chief Information Security Officer
• IDP: Identity Provider
• IGA: Identity Governance and Administration
• ITDR: Identity Threat Detection and Response
• JIT: Just-In-Time Access
• JML: Joiner, Mover, Leaver (lifecycle events)
• KPI: Key Performance Indicator
• LDAP: Lightweight Directory Access Protocol
• LLM: Large Language Model
• MFA: Multi-Factor Authentication
• OIDC: OpenID Connect
• PAM: Privileged Access Management
• PDP: Policy Decision Point
• PEP: Policy Enforcement Point
• RBAC: Role-Based Access Control
• SAML: Security Assertion Markup Language
• SCIM: System for Cross-Domain Identity Management
• SoD: Segregation of Duties
• SSO: Single Sign-On
• UEBA: User Entity Behavior Analysis
• ZSP: Zero Standing Privileges
• Zero Trust: Security model where all access is verified and authorized, regardless of network location

Appendix B: Mapping to Standards and Frameworks

This IAM 2.0 Reference Architecture aligns with several external standards:

• NIST Cybersecurity Framework: Identity & Access Management is a core function
• NIST 800-53: Controls AC (Access Control), IA (Identification and Authentication), AU (Audit & Accountability)
• ISO/IEC 27001: Information security management system controls for identity and access
• GDPR: Privacy protection principles and practices embedded throughout
• Zero Trust Architecture (NIST 800-207): Assumes no implicit trust; continuous verification
• FICAM (Federal Identity, Credential, and Access Management): Government sector identity best practices