If you're coming from a background in vulnerability management or threat intelligence and wondering whether an identity governance role is a good entry point or a career dead end, the short answer from practitioners who've done it is: it's neither a pigeonhole nor a stepping stone. It's one of the more strategically positioned specializations in security right now, and the work is significantly more complex than basic AD provisioning would suggest.

The longer answer depends on what you find engaging about security work, because identity governance pulls from compliance, architecture, cloud infrastructure, and threat detection simultaneously. It's not a narrow lane.

What Identity Governance Actually Involves Day-to-Day

The distinction between IAM and IGA is worth understanding before the interview. IAM — basic identity and access management — is authentication and authorization: verifying who you are and controlling what you can access at the front door. Identity Governance and Administration goes deeper: it's concerned with what access people have accumulated over time, whether that access is still appropriate, and whether it's compliant with internal policies and external regulatory requirements.

In practice, the work includes: designing and maintaining RBAC structures that map job functions to access entitlements, automating the joiner-mover-leaver lifecycle so access is provisioned and revoked through policy rather than manual tickets, running periodic access certification campaigns where managers review and attest to their team members' current access, and enforcing Segregation of Duties controls that prevent one person from holding conflicting access rights (the person who requests a payment can't also be the person who approves it, for example).

The inventory and ownership work one commenter described as a starting point — knowing what systems exist, who owns them, how they're categorized, what the provisioning procedures are — is foundational to all of it. You can't govern access you haven't inventoried.

Is It a Pigeonhole?

The consensus from practitioners in this thread is no, and the reasoning is sound. Identity governance is cross-functional by nature. A practitioner with years of IGA experience has touched cloud infrastructure (provisioning to AWS, Azure, and GCP), compliance frameworks (SOC 2, ISO 27001, HIPAA, SOX), zero-trust architecture, Active Directory and Entra ID, HR system integrations, SaaS management, and increasingly privileged access management. That's a broad technical foundation.

The commenter who noted they went from central IT writing an IGA engine to take identity data from upstream sources to downstream directories is describing work that requires understanding data flows, directory architecture, automation, and security policy simultaneously. That's not a narrow skill set.

The IAM and Identity Security space is also explicitly growing. The core IAM market — commodity SSO and directory services — is largely saturated. Identity Governance, Identity Threat Detection and Response (ITDR), and Identity Security Posture Management (ISPM) are the active growth areas. The teams doing this work are increasingly visible to security leadership because the attack surface they're managing — compromised credentials, over-privileged accounts, orphaned access — is the actual attack path in a significant share of breaches.

The Skills That Actually Matter in This Role

PowerShell comes up consistently in identity governance work, primarily for AD automation — provisioning scripts, deprovisioning workflows, attribute synchronization. If you're worried about it going into an interview, the honest position is to acknowledge the gap and demonstrate that you understand the use cases: "I haven't written production provisioning scripts, but I understand the patterns — RBAC group assignment, attribute-driven automation, scheduled reconciliation against HR data." That's more credible than claiming proficiency you don't have.

The security mindset is the more transferable asset from your existing background. Vulnerability management experience translates directly to thinking about entitlement entropy — the accumulation of over-privileged access as people change roles and projects — and threat intelligence experience translates to understanding how identity-based attacks work in practice, which is increasingly relevant as ITDR becomes part of the IGA scope.

The RBAC design work — creating role groups per job function, nesting them into access groups, governing the lifecycle of those groups — is the core technical skill. Understanding how provisioning connects to compliance reporting (the access certification evidence that SOC 2 auditors want to see) is the governance layer on top of it.

Where the Field Is Heading

The shift from administration to threat detection is real and worth understanding for anyone entering the field now. Traditional IGA focused on lifecycle automation and access reviews. The frontier is moving toward real-time monitoring of access patterns, automated detection of anomalous entitlements (a developer suddenly with finance system access, a dormant account showing activity), and Identity Security Posture Management — continuously evaluating the configuration state of your identity infrastructure against security benchmarks.

Non-human identities are the other expanding scope. Service accounts, API keys, OAuth tokens, bot credentials, and increasingly AI agent identities represent a growing attack surface that traditional IGA tools weren't designed to govern. The practitioners entering identity security now will be working on this problem throughout their careers.

IGA platforms like Zluri are built on the assumption that the governance problem extends beyond human users in a single directory — covering SaaS applications, shadow IT, non-SSO tools, and increasingly non-human identity types from a unified platform. Understanding that architectural shift is useful context going into an identity governance role, both for the interview and for the actual work.

What to Expect in the Interview

Based on what practitioners in this thread described as the core of the work, the interview is likely to cover:

How you would approach building an inventory of systems and establishing ownership. What RBAC design looks like in practice and how you'd handle role proliferation as the organization scales. How you'd design a provisioning workflow connected to an HR system as source of truth. What access reviews are, how they're structured for compliance, and what makes them meaningful versus rubber-stamp certifications. How you'd handle the mover scenario — an employee changing departments — and what access creep looks like over time.

The PowerShell question may come up in the context of AD automation. Honest scoping of your current level and a demonstrated understanding of what the scripts are trying to accomplish is the right approach.

Frequently Asked Questions

Is identity governance a good entry point into information security?

Yes — identity governance provides hands-on experience with cloud infrastructure, compliance frameworks, directory architecture, automation, and zero-trust security principles simultaneously. It's cross-functional enough that practitioners regularly move into GRC, security architecture, cloud security, and threat detection roles after building an IGA foundation. The field is also one of the active growth areas in security, which creates career mobility rather than limiting it.

What is the difference between IAM and IGA in security?

IAM covers authentication and authorization — verifying identity and controlling access at the front door. Identity Governance and Administration (IGA) covers the ongoing management of that access: ensuring it's still appropriate as people change roles, revoking it when they leave, running periodic access reviews for compliance, and enforcing policies like Segregation of Duties. IAM is the front door; IGA is the continuous monitoring of what happens once people are inside.

What technical skills do identity governance roles require?

Core skills include: Active Directory and Entra ID administration, RBAC design, PowerShell for automation, provisioning workflow design connected to HR systems, access certification campaign management, and familiarity with compliance frameworks (SOC 2, ISO 27001, HIPAA, SOX). Understanding of SCIM provisioning, SSO protocols (SAML, OIDC), and increasingly cloud IAM (AWS, Azure, GCP) is valuable at more senior levels.

What is entitlement entropy in identity security?

Entitlement entropy is the accumulation of access permissions over time as employees change roles, join projects, and are granted temporary access that never gets revoked. Over time, users end up with admin privileges or application access from roles they left months or years ago. Orphaned accounts — active credentials belonging to former employees — are the most acute form. Detecting and remediating entitlement entropy through access reviews and automated deprovisioning is a core IGA function.

Explore Identity Governance as a Career Path

If you're evaluating an identity governance role and want to understand what the tooling looks like in practice, see how Zluri's IGA platform handles the day-to-day work of access reviews, lifecycle automation, and compliance reporting.