Most explanations of IAM and IGA stay at the conceptual level — what they are in theory — without explaining what they actually look like when implemented inside a real company. This article covers the operational reality: how the JML lifecycle runs, how HR systems connect to Active Directory, what an audit trail actually contains, and why the distinction between IAM and IGA matters for your day-to-day work.

IAM vs. IGA: Why the Difference Matters in Practice

IAM and IGA are frequently used interchangeably in job postings and vendor marketing, but they solve different problems at different time horizons.

IAM is the real-time enforcement layer. When an employee opens their laptop and logs into Salesforce, IAM makes the decision in that moment: is this the right person, do they have the right credentials, and are they allowed into this application right now? Authentication (verifying identity) and authorization (determining what's accessible) happen in milliseconds. Tools like Okta, Entra ID, and Google Workspace handle this layer. The output is a yes or no at the moment of access.

IGA is the governance layer that operates continuously in the background. While IAM answers "can this person access this right now," IGA answers three questions that auditors require evidence for: who has access to what, should they have that access based on current policy, and what are they doing with it? IGA enforces Segregation of Duties (preventing one person from having conflicting access that would let them complete a sensitive transaction without oversight), manages the lifecycle of access over time, and produces the compliance evidence that SOC 2, ISO 27001, and HIPAA audits require.

The practical consequence of not having IGA: an employee who joined in the Sales department five years ago, moved to Engineering two years ago, then became a team lead last year, may still have access to every application they accumulated along the way — including admin rights from a project three years ago that nobody ever cleaned up. IAM lets them log into all of those applications because the access still exists in the directory. IGA is what would have caught and removed the accumulated access at each role transition.

The JML Lifecycle: How Access Changes at Every Stage

The Joiner-Mover-Leaver lifecycle is the operational framework for access management inside companies. Every person who works at an organization goes through all three stages, and how each stage is handled determines whether the access environment stays clean or accumulates risk over time.

Joiners — new employees getting set up on day one.

In companies with manual processes, onboarding looks like this: IT receives an email from HR, creates accounts in each application individually, sends credentials, and hopes nothing was missed. In companies with automated JML, it looks different.

An HR system — Workday, BambooHR, HiBob, or similar — is established as the authoritative source of truth for employment data. When HR adds a new employee with a start date, role, and department, the IGA system detects the new record and triggers an onboarding workflow automatically. That workflow provisions what's called birthright access — the standard set of applications, groups, and permissions that everyone in that role gets on day one. No manual IT ticket. No waiting for an email. By the time the new employee logs in on their first morning, their accounts exist and their permissions are configured.

Movers — employees changing roles or departments.

This is the hardest part of the lifecycle to get right and the source of most privilege creep. When an employee moves from Sales to Engineering, they need their new Engineering access provisioned. They also need their Sales-specific access removed. In manual environments, the provisioning side usually happens because someone submitted a request. The deprovisioning side often doesn't happen because nobody thought to submit that request.

Automated mover workflows run both sides simultaneously. When the HR record shows a department change, the IGA system deprovisions the access tied to the previous role and provisions the access appropriate for the new role in the same automated run. The employee has everything they need for their new job and nothing they no longer need from their old one.

Leavers — offboarding when employment ends.

When an employee is terminated in the HR system, the IGA system detects the status change and triggers an offboarding workflow that systematically revokes access across every connected application. The critical phrase is "every connected application" — not just the SSO-connected apps, but the shadow IT tools, the department-managed SaaS subscriptions, and the legacy applications that predate the current IAM stack.

Orphaned accounts — active accounts in applications belonging to people who are no longer employed — are a major compliance finding in security audits. The automated leaver workflow exists specifically to close those accounts before they become findings.

HR to LDAP Provisioning: How It Works in a Hybrid Environment

One of the most technically interesting parts of enterprise IAM is how HR systems connect to on-premises Active Directory in hybrid environments — organizations that have both cloud applications and on-prem infrastructure.

The challenge is that Active Directory lives inside the corporate network, behind a firewall. A cloud-based IGA platform can't just reach in from the internet and make changes to AD. The architectural pattern that solves this without opening inbound firewall ports is an agent-based approach.

A lightweight agent — typically deployed as a Docker container — runs inside the internal network. Rather than waiting for inbound connections, the agent polls the cloud platform over HTTPS on an outbound connection (the agent reaches out to the cloud, not the other way around). When the cloud platform has a provisioning instruction — create this user, add them to this OU, assign this group — it queues the instruction for the agent to pick up on its next poll. The agent executes the action locally against Active Directory using LDAP (port 389) or LDAPS (port 636 for encrypted communication), and reports the result back to the cloud platform.

The result: the cloud IGA platform can manage on-prem AD without requiring the security team to open any inbound firewall rules. The corporate firewall stays in its current configuration; the agent makes outbound connections to the cloud, not the other way around.

This pattern is why "HR to LDAP provisioning" is achievable even when the HR system is cloud-hosted and the Active Directory is on-prem. The agent bridges the network boundary without creating a security exposure.

What an Audit Trail Actually Contains

When auditors evaluate access management controls for SOC 2, ISO 27001, or HIPAA, they're not asking "do you have a process?" They're asking for evidence that the process ran correctly. The audit trail is that evidence.

A robust IGA audit log records every lifecycle event with enough detail to reconstruct what happened and why:

• What action was taken: account created, license assigned, group membership added, account disabled, access revoked
• When it happened: timestamp down to the second
• Who or what triggered it: was it an automated rule that fired from an HR event, or was it a manual action by an IT admin, or was it a manager clicking Revoke in an access review?
• What the outcome was: success, failure, pending manual action

For access reviews specifically, the audit log records which users were reviewed, what decision the reviewer made (approve, revoke, or modify), what justification they provided, and when the action was executed following that decision. When an auditor asks "how do you know this user's access was reviewed in Q3 and remains appropriate," the answer is the timestamped, non-editable certification report that the IGA platform generated when the review campaign completed.

The non-editable part matters. An auditor reviewing a spreadsheet can reasonably ask whether the data was accurate at the time it was created or whether it was modified. A timestamped report generated by the IGA system at campaign conclusion has an integrity that a spreadsheet doesn't.

How to Pivot Into IAM: What Actually Helps

For anyone using this session summary as a jumping-off point for an IAM career pivot, the concepts covered here map to specific skills that hiring managers evaluate:

Understanding the JML lifecycle — not just what the terms mean, but how each phase creates security risk when it's handled poorly — is the foundational conceptual knowledge. Understanding the HR-to-provisioning architecture (source of truth, agent-based LDAP connectivity, webhook triggers) is the operational knowledge that shows you can implement rather than just describe.

Building a hands-on lab — using MidPoint (open-source IGA), a local Active Directory instance, and a dummy HR data source — is how you demonstrate that knowledge practically. The GitHub documentation that explains what you built, what problem it solves, and what you learned is what converts lab work into resume evidence.

The combination of conceptual understanding (IAM vs. IGA, JML lifecycle, compliance evidence requirements) and hands-on evidence (a working system documented with architecture diagrams and workflow explanations) is what makes a career pivot candidate credible to hiring managers in the identity space.

Frequently Asked Questions

What is the JML lifecycle in IAM?

Joiner-Mover-Leaver (JML) describes the three identity lifecycle events every employee goes through. Joiners are new employees who need accounts and access provisioned. Movers are employees changing roles who need old access removed and new access added simultaneously. Leavers are departing employees whose access needs to be fully revoked across all systems. Automating all three phases from a single HR source of truth is the core function of an IGA system.

What is the difference between IAM and IGA in practice?

IAM handles real-time authentication and authorization — whether someone can log in right now. IGA handles the governance of access over time — whether someone should have access, whether that access has been reviewed, whether it's still appropriate for their current role, and whether there's compliance evidence to prove it. IAM enforces the access that exists; IGA governs whether what exists is correct.

How does HR-to-LDAP provisioning work in a hybrid environment?

A cloud IGA platform can't reach directly into an on-prem Active Directory through a corporate firewall. An agent deployed inside the network makes outbound connections to the cloud platform, picks up provisioning instructions, and executes them locally against AD using LDAP or LDAPS. This lets the cloud platform manage on-prem AD without requiring inbound firewall rules or network changes.

What does an IGA audit trail contain for compliance?

An IGA audit trail records every lifecycle event with the action taken, the timestamp, who or what triggered the action (automated rule or human), and the outcome. For access review certifications, it records which users were reviewed, the reviewer's decision, the justification provided, and when the resulting access change was executed. This record is the compliance evidence that SOC 2, ISO 27001, and HIPAA auditors require to verify that access management controls are functioning.