These four terms show up together constantly in identity and security conversations, but they solve different problems and operate at different layers. Understanding what each one actually does — and what it doesn't do — makes the rest of identity security much easier to follow.

Directory Services: The Source of Truth

A directory service is a database that stores identity records. At its most basic, it holds information about every person in the organization: their name, job title, department, reporting manager, email address, and whether their account is active. Active Directory (AD), Azure AD / Entra ID, and Google Workspace are the most common examples.

The key function of a directory service is authoritative identity data — it's the system of record that answers "does this person exist in our organization and what do we know about them?" When other systems need to know whether someone is a current employee, or what department they're in, or who their manager is, they ask the directory.

Directory services also manage groups and group memberships, which is how access is typically granted at scale. Rather than assigning permissions to individual users one at a time, IT assigns permissions to a group (like "Engineering") and adds users to the appropriate group. The directory tracks who belongs to which groups.

What directory services don't do on their own: they don't control how strongly you prove your identity before being granted access, they don't manage your access to the many SaaS apps that aren't natively connected to the directory, and they don't continuously verify that your access is still appropriate for your current role.

MFA: Verifying You're Actually Who You Claim to Be

Multi-Factor Authentication adds a second verification step beyond a password. The principle is that authentication factors fall into three categories: something you know (a password), something you have (a phone with an authenticator app, a hardware key), and something you are (biometrics). MFA requires at least two of these rather than just one.

The reason this matters: passwords alone are easily compromised through phishing, credential stuffing, or data breaches. If a password is the only thing standing between an attacker and someone's account, a stolen password is all it takes. Adding a second factor means a stolen password alone isn't sufficient — the attacker would also need the physical device or biometric factor.

Modern MFA implementations vary in strength. SMS codes are better than nothing but are phishable. Authenticator apps (TOTP codes) are stronger. FIDO2 hardware keys and passkeys are phishing-resistant, meaning they won't be tricked by lookalike login pages.

What MFA doesn't do: it secures the authentication event — the moment of login — but it doesn't govern what someone can do after they're in, how their access is managed over time, or whether their access is still appropriate for their role.

SSO: One Set of Credentials for Many Applications

Single Sign-On solves the user experience and security problem of managing separate credentials for every application. Instead of maintaining 30 different usernames and passwords across 30 different tools, a user authenticates once to their identity provider (Okta, Azure AD, Google Workspace, JumpCloud) and that authentication is accepted by all connected applications.

Technically, SSO works through token-based protocols like SAML, OIDC, or OAuth. When a user tries to access an application, the application checks with the identity provider: "is this person authenticated?" The identity provider issues a signed, timestamped token confirming the authentication, and the application grants access based on that token. The token is time-limited and non-reusable, which prevents replay attacks.

From a security perspective, SSO does more than simplify passwords. It centralizes the authentication control point — if you need to immediately cut someone's access (an employee being terminated, a compromised account), you disable their account in the identity provider and they lose access to all SSO-connected applications simultaneously. You don't have to log into 30 separate apps to revoke each one.

What SSO doesn't cover: the applications that don't support SSO (a significant portion of most SaaS stacks), what happens inside applications after the user authenticates, and the governance of whether the user should have that access at all based on their current role.

IGA: Governing Who Has What Access and Why

Identity Governance and Administration operates on a different dimension than the other three. Directory services stores identity data. MFA secures the authentication event. SSO manages the login experience across applications. IGA manages the entire lifecycle of what access each identity holds — from initial provisioning when someone joins to full deprovisioning when they leave, with continuous verification that access remains appropriate in between.

The core IGA functions are:

Lifecycle automation (Joiner-Mover-Leaver). When someone joins the organization, IGA provisions their accounts and grants the access appropriate for their role — not manually, but through policy-driven workflows triggered by the HR system. When they change departments, IGA adjusts their access to match the new role. When they leave, IGA revokes all access systematically rather than relying on manual processes that get skipped.

Access reviews and certifications. Periodically, IGA surfaces who has access to each application and asks the relevant managers or app owners to verify that access is still appropriate. This catches the "privilege creep" problem — access that was appropriate six months ago but no longer matches someone's current role. It also produces the audit evidence that compliance frameworks like SOC 2, ISO 27001, and HIPAA require.

Governance beyond SSO. Applications outside the SSO perimeter — tools departments bought independently, services employees signed up for with work emails, legacy apps that don't support modern authentication protocols — aren't visible to the identity provider. IGA discovery mechanisms find these applications through financial integrations, browser agents, and usage data, bringing them into the governance scope even when they can't be federated to SSO.

Principle of least privilege enforcement. IGA continuously verifies that users have only the access their current role requires — not accumulated access from previous roles, not access that was granted temporarily and never revoked, and not broader permissions than the job actually needs.

Platforms like Zluri implement IGA specifically — connecting to the HR system as the source of truth, running JML workflows across connected and disconnected applications, managing access certification campaigns, and surfacing shadow IT through discovery rather than relying on what the identity provider can see.

How All Four Work Together

The four layers aren't alternatives to each other — they address different parts of the identity security problem and operate at different points in the identity lifecycle.

Directory services provides the foundational identity data that everything else depends on. MFA secures the moment of authentication, making credential theft insufficient to gain access. SSO centralizes authentication across applications, making revocation faster and eliminating password sprawl. IGA governs the entire lifecycle of access, ensuring that what gets provisioned is appropriate, that it stays appropriate over time, and that it's fully revoked when no longer needed.

A useful way to think about the relationship: you can't do IGA without a directory service (governance requires a trusted record of who exists), SSO depends on the directory for identity data, and MFA strengthens the authentication that SSO performs. Each layer builds on the ones below it.

The security gaps appear when layers are missing. SSO without IGA means access is easy to use but may not be governed appropriately — someone who moved from Engineering to Sales may still have production database access because no one revoked it. MFA without SSO means authentication is strong but credentials are fragmented across dozens of apps. A directory without lifecycle automation means orphaned accounts accumulate as employees leave without systematic deprovisioning.

Frequently Asked Questions

What is the difference between SSO and IGA?

SSO handles authentication — it's the mechanism by which you prove your identity and gain access to applications using a single set of credentials. IGA handles governance — it manages whether you should have that access at all, how it was granted, whether it's still appropriate, and what happens to it when you leave. SSO controls the login event; IGA controls the lifecycle of what you're allowed to log into.

What is the difference between MFA and SSO?

MFA and SSO work together rather than competing. MFA adds a verification layer to the authentication process — it makes sure the person logging in is actually who they claim to be by requiring a second factor beyond a password. SSO then allows that single verified authentication to grant access across multiple applications. You authenticate strongly once (with MFA) and that authenticated session applies across all your SSO-connected tools.

What is a directory service and why does it matter for identity security?

A directory service is the authoritative database of identity records — who exists in the organization, what their attributes are, and what groups they belong to. It's the foundation that other identity tools rely on. SSO checks the directory to verify that a user exists. IGA uses the directory as the source of truth for lifecycle management. MFA enforcement policies reference directory attributes to determine which users require which authentication strength. Without a trustworthy directory, every layer built on top of it is unreliable.

What is privilege creep and how does IGA prevent it?

Privilege creep is the accumulation of access entitlements as people change roles, join projects, and are granted temporary access that never gets revoked. Over time, users end up with admin rights or application access from roles they held months or years ago. IGA prevents this through periodic access certification campaigns where managers review and confirm their team members' access is still appropriate, automated workflows that adjust access when role changes are detected, and continuous monitoring that flags access patterns inconsistent with someone's current role.

See How Zluri Handles IGA on Top of Your Existing Stack

If you're building out the IGA layer on top of your existing SSO and directory foundation, see how Zluri handles the lifecycle automation, access governance, and shadow IT discovery that sits above the authentication layer your current stack already covers.