What Is IAM: Identity and Access Management for Enterprise 2026

IAM (Identity and Access Management) is the discipline that manages the lifecycle of digital identities (human users, machines, workloads, and AI agents) and the access each one has over the organisation's resources. It is the foundation on which any Zero Trust architecture is built, any serious compliance programme (NIS2, ENS, ISO 27001, DORA, SOC 2), and any realistic defence against modern attacks, where credential theft and abuse is the dominant vector in most breaches.

IAM at a glance

• IAM is not a product, it is a cross-cutting discipline that covers authentication, authorisation, access governance, privileged identity, and machine identity.
• The main subdisciplines are operational IAM, IGA, PAM, CIAM, and Machine Identity, and each one solves a different problem.
• The authorisation model (RBAC, ABAC, PBAC, ReBAC) sets the ceiling for the granularity and maintainability of your access policy.
• The 2026 stack combines an enterprise IdP, phishing-resistant MFA, access governance, and privileged account management, trending towards identity as the new perimeter.
• It maps to NIS2 art. 21, ISO 27001 A.5.16 to A.5.18, ENS, GDPR art. 32, and SOC 2 CC6.

The three classic pillars: AAA

The historical acronym AAA (Authentication, Authorization, Accounting) remains the best way to explain what IAM does.

Authentication: who you are. An identity proves it is who it claims to be. Factors are grouped into something you know (password, PIN), something you have (FIDO2 key, TOTP, smartphone), and something you are (fingerprint, face, voice). Modern authentication combines factors (MFA) and replaces passwords with passkeys that are phishing resistant.

Authorisation: what you can do. Once authenticated, the identity needs a decision on which resources it can view, modify, or delete. It materialises in policies (roles, attributes, relationships, ACLs). The most complex piece because it grows with every application, team, and sensitive data set.

Accounting: what you did. Every authenticated and authorised action leaves an audited trail: who, what, on which resource, from where, when. Without accounting there is no forensics, no compliance, and no way to detect privilege abuse. IAM logs are one of the most valuable SIEM inputs.

Some literature extends to AAAA by adding Auditing, which separates log generation from periodic review. The distinction matters: generating logs without reviewing them is a common audit finding.

The subdisciplines of IAM

IAM is neither a single product nor a single team. It is a set of subdisciplines with different problems, vendors, and maturity levels. Confusing them is the most common cause of projects that get stuck.

Operational IAM. Day to day: account creation and removal, automated provisioning, HR sync, group management, password resets, SSO integration. Its success metric is speed and consistency: a new employee should have all their access on day one and lose it entirely on the day they leave.

IGA (Identity Governance and Administration). Goes beyond provisioning and focuses on governance: periodic certifications, entitlement reviews by managers, segregation of duties, approval workflows, role modelling. It is the layer that answers the auditor's question why does this user have this access? with traceable evidence.

PAM (Privileged Access Management). Manages privileged accounts: domain administrators, root on servers, database superusers, cloud service keys. Includes credential vaulting, automatic rotation, session recording, just-in-time access, and approval workflows.

CIAM (Customer IAM). Manages external user identities: customers, partners, citizens. Different requirements from internal IAM: scale of millions, social registration, branding, GDPR consent, minimal friction.

Machine Identity. Non-human identities: cloud workloads, containers, service accounts, IoT devices, AI agents. Their volume grows faster than human identities and their traditional management has been poor (static keys, secrets in code, certificates without rotation). 2026 focus is on SPIFFE/SPIRE, ephemeral identities, and integrated secrets management.

Technical components of the IAM stack

Beneath the business language, an IAM stack is made up of concrete technical pieces with clear responsibilities.

Identity Provider (IdP). Authoritative system that holds the identity and issues assertions. Microsoft Entra ID, Okta, Ping Identity, ForgeRock, Auth0, and Keycloak are the common names. The nerve centre: if it goes down or is compromised, so does access to everything that delegates to it.

Service Provider (SP). Application or service that trusts the IdP to authenticate users. In well designed SSO the SP never sees the user's password, it only receives a signed assertion.

Directory. Structured store of accounts, groups, and attributes. Active Directory remains the dominant on-premise directory after two decades. Microsoft Entra ID (formerly Azure AD) is its cloud counterpart, complementary not identical. Other options: OpenLDAP, JumpCloud, native directories of Okta and Google Workspace.

Federation. Allows a user authenticated in one domain to access resources in another without reauthenticating. Dominant protocols: SAML 2.0 (classic enterprise), OpenID Connect (OIDC) over OAuth 2.0 (modern standard), and SCIM for provisioning.

Authentication factors. From passwords (the weakest and still the most widespread) to FIDO2/WebAuthn passkeys and hardware keys, with TOTP, push (MFA fatigue risk), and biometrics (always as a local device factor) in between.

Adaptive authentication. Intelligence layer that adjusts friction based on session risk: location, device, time, behaviour. Low risk passes with one factor, suspicious sessions require reverification or are blocked.

RBAC vs ABAC vs PBAC vs ReBAC

The authorisation model you choose determines how much granularity you can express and how much maintenance cost you accept. There is no absolute winner, only better fits per case.

Practical rule for mid-sized enterprises. Start with RBAC for the clear cases (access to SaaS applications, department groups) and add ABAC or PBAC for cases where context matters (data access by classification, location restrictions, time windows). ReBAC fits multi-tenant SaaS products more than classic corporate IT.

Vendor landscape 2026

The IAM ecosystem in 2026 is fragmented by subdiscipline. This section describes capabilities without commercial endorsement: the choice depends on the starting point, the existing stack, and priorities.

Enterprise IAM and IdP. Okta as the reference independent, Microsoft Entra ID with native Microsoft 365 integration, Ping Identity with traction in banking and telcos, OneLogin as a lighter alternative, ForgeRock strong in CIAM, Auth0 (part of Okta) with developer focus.

PAM. CyberArk as the historical reference, Delinea (merger of Thycotic and Centrify) with a modular proposition, BeyondTrust with strong privileged endpoint focus, HashiCorp Vault centred on secrets and machine identity.

IGA. SailPoint as the consolidated leader, Saviynt with a cloud-first and modern approach, IBM Verify Governance, Omada with EMEA traction. The segment where licence and implementation cost weighs most.

CIAM. Auth0 and Okta CIAM (same group), Microsoft Entra External ID, AWS Cognito native for AWS stacks, Google Cloud Identity for Workspace. ForgeRock and Ping also compete here.

Open source. Keycloak (Red Hat) as the reference for self-hosted IdP, Authentik with modern UX, Authelia lightweight, Casbin as an embeddable authorisation library, OpenFGA and SpiceDB as open implementations inspired by Zanzibar for ReBAC.

Machine identity and secrets. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, CyberArk Conjur, Akeyless. For workloads, SPIFFE/SPIRE as the open standard.

The practical rule: first consolidate IdP and MFA, then PAM if there is significant critical administration, then IGA when application count and audit pressure justify it, and work machine identity in parallel from the start.

Zero Trust and IAM: identity as the new perimeter

In the Zero Trust architecture, identity occupies the place that the network used to occupy as the primary control plane. Identity is the new perimeter sums up the shift. Three concepts make it concrete.

Just-In-Time access (JIT). Privileged access is not permanent. An administrator requests the role when needed, receives approval, performs the task, and the role expires automatically. It drastically reduces the exposure window of compromised privileged accounts.

Just Enough Access (JEA). When access is granted, it is the minimum needed for the task. Not "system administrator" but "I can restart this service on these two servers". It materialises with PowerShell JEA on Windows, granular sudo on Linux, fine-grained scopes in cloud.

Continuous verification. The session is not taken as valid indefinitely. Device posture, user behaviour, and threat intelligence signals are continuously evaluated. If something changes, the session is re-evaluated and can be revoked.

For a deeper view of this model, see the Zero Trust architecture and implementation guide.

Common IAM risks

IAM-related breaches usually do not come from failures in the IdP itself, but from poor hygiene patterns and specific attacks against the identity plane.

Shadow accounts. Accounts created outside the official process (a team creates a local account in a SaaS application, a technician creates a service account without documenting it). Invisible to IGA and deprovisioning. Mitigation: active discovery and mandatory SSO discipline.

Orphaned accounts. Accounts of users no longer in the organisation whose access remains active. A recurring audit finding and an attacker favourite. Mitigation: offboarding automation and periodic access certifications.

Over-permissioned service accounts. Technical accounts that started with wide permissions "just in case" and were never reviewed. In many breaches the attacker finds one and inherits its permissions. Mitigation: need-based modelling, credential rotation, and specific monitoring.

MFA bypass. Attacks that go around MFA: MFA fatigue (push bombing until the user accepts), SIM swapping against SMS OTP, real-time phishing with kits like Evilginx, theft of session cookies after MFA. Mitigation: phishing-resistant MFA (FIDO2/passkey) and number-matching on push notifications.

OAuth token theft. Theft of valid OAuth tokens that grant access without a credential. Mitigations: short-lived tokens, rotating refresh tokens, device binding, anomalous use detection.

Session hijacking. Theft of active session cookies via malware or XSS. Mitigations: tokens bound to device, periodic reauthentication, detection of client fingerprint changes.

IAM audit

An IAM practice without regular auditing degenerates quickly. Three minimum processes:

Access certifications. Quarterly or semi-annually depending on criticality, managers review their team's access and confirm or revoke. Privileged access is reviewed more frequently. Must leave auditable evidence of who reviewed, what they decided, and when.

Segregation of duties (SoD). Rules forbidding toxic combinations of access. Classic example: the same person should not be able to create a vendor and approve payment to that vendor. Modelled as violation policies and reported to the audit committee.

Entitlement review. Review of fine-grained rights (not just "has access to SAP" but "has transaction XYZ"). More detailed than the general certification, applied to critical systems. Modern IGA tools integrate entitlement catalogs that make it easier.

Mapping to NIS2, ISO 27001, ENS, GDPR, SOC 2

IAM is one of the domains where regulatory controls materialise most directly. Having a solid IAM significantly reduces the cost of compliance across multiple frameworks at once.

For audit preparation, see the NIS2 audit step-by-step guide and the complete ISO 27001 guide.

Frequently asked questions

Should I start with operational IAM or with IGA?

With operational IAM. Without a consolidated IdP, generalised MFA, and basic onboarding and offboarding processes, putting IGA on top is like building a roof without walls. IGA delivers value when identity is already under control, dozens of applications are connected, and there is real audit pressure that demands certifications. A reasonable sequence is 6 to 12 months of solid operational IAM before tackling IGA.

Does Entra ID replace Active Directory?

Not entirely. Entra ID is excellent for cloud identity, SSO with SaaS, and authentication for modern applications, but it does not implement every service of classic Active Directory (full GPOs, Kerberos against traditional on-premise resources, deep LDAP schemas). In 2026 the common situation is managed coexistence: AD for legacy on-premise with Entra Connect syncing into Entra ID. Pure migrations only fit cloud-first organisations.

Is MFA enough, or do I also need PAM?

MFA is necessary but not sufficient for privileged accounts. An administrator account with MFA is still an account with permanent power that lives on a workstation that can be compromised. PAM adds vaulting, rotation, JIT, session recording, and approval workflows. The rule: MFA is the baseline for everyone, PAM is mandatory for the privileged subset.

Do passkeys eliminate passwords?

They tend to, but the transition spans several years. Passkeys (WebAuthn) offer much higher security (phishing resistant, device bound, no shared secret) and better experience. In 2026 adoption is growing fast in consumer and progressing in enterprise, but passwords coexist due to legacy application inertia and recovery use cases. A reasonable roadmap: passkey first where possible, password fallback only where there is no alternative.

Is machine identity more important than human identity?

Both matter, but the volume and growth of machine identities exceed those of humans. A mid-sized organisation can have thousands of service accounts, certificates, API keys, and workloads versus a few hundred humans. Their traditional management has been worse (secrets in code, keys without rotation), which makes them a favourite vector. Treating them with the same seriousness (inventory, lifecycle, rotation, least privilege) is a maturity focus in 2026.

Is open source IAM serious enough for enterprise?

Yes, in specific scenarios. Keycloak is a solid choice for self-hosted IdP with mature SAML and OIDC. Authentik and Authelia fit smaller cases. Casbin, OpenFGA, and SpiceDB cover embeddable authorisation. The trade-off is not technical quality but operational cost: open source requires a team capable of operating, patching, and scaling the platform. For organisations with strong platform capability it is viable; for the rest, commercial vendors usually come out cheaper in total cost.

Related resources

• What is Zero Trust: architecture, principles, and implementation
• What is PKI: public key infrastructure
• What is SAML: identity federation and enterprise SSO
• JWT security: vulnerabilities and best practices
• Active Directory pentesting: tier model and attack paths
• What is credential stuffing: attack and defence

IAM strategy with Secra

At Secra we help B2B organisations design and consolidate their IAM programme. In 4 weeks we deliver an assessment and roadmap with:

• Assessment of the current stack (human and machine identities, IdP, MFA, PAM, IGA) compared with your target regulatory framework (NIS2, ENS, ISO 27001, DORA, SOC 2).
• Target model of identity, authentication, and authorisation adapted to your stack (Microsoft, Google, AWS, Azure, hybrid).
• Phased plan with quick wins (phishing-resistant MFA, removal of orphaned accounts, retirement of legacy protocols) and structural projects (single IdP, PAM, IGA).
• Execution support optional through sensitive phases (passkey migration, PAM deployment, access certifications).

If your organisation is evaluating an IAM project, an IdP consolidation, or a PAM deployment, contact Secra and we will schedule an initial session with no commitment.