Identity and Access Management

Identity and Access Management (IAM) Definition

Identity and Access Management (IAM) is a set of processes, policies, and technologies that enable organizations to manage digital identities and control access to resources and systems. IAM ensures that the right people have the right access to the right resources at the right time and for the right reasons.

IAM, PAM, IGA, CIAM and NHI — how they differ

IAM is the umbrella. The NIST glossary (citing SP 800-175A) describes identity management as administering the identities within a system; in a company’s IT it means deciding which roles network users hold and what each of them may access. Narrower tool categories sit under that umbrella. Each answers a different question and covers a different group of identities.

Category	Scope	Who it covers	Typical functions
IAM (Identity and Access Management)	identities and permissions across the organisation	employees, contractors, technical accounts	identity directory, SSO, MFA, roles and access policies
PAM (Privileged Access Management)	accounts and roles with elevated permissions	administrators and other privileged accounts	just-in-time access, time-bound role activation with approval, oversight of privileged activity
IGA (Identity Governance and Administration)	the identity lifecycle and control over granted access	all users; the resource owner’s and auditor’s view	account creation driven by the HR system, access reviews, separation of duties, access removal when people leave
CIAM (Customer Identity and Access Management)	identities of an application’s customers	consumers and business customers	self-service sign-up, sign-in with a Google or Facebook account, custom-branded sign-in screens, a tenant kept apart from the workforce
NHI (Non-Human Identities)	identities of software	applications, services, APIs, scripts, containers, bots	short-lived credentials instead of static secrets, key rotation, retiring identities nobody uses

The borders between categories are blurred. Microsoft ships its PAM-class tool (Privileged Identity Management) inside the Entra ID Governance package, which is the IGA side. According to that documentation, IGA answers four questions: who should have access to what, what they do with that access, whether the organisation has controls over it, and whether an auditor can confirm those controls work. Non-human identities are usually not tied to a specific person, and the usual safeguards for human accounts do not cover them (OWASP). Microsoft also notes that most IAM products on the market focus on protecting human identities.

Key Components of IAM System

• Authentication - verification of user identity
• Authorization - determining access permissions
• Administration - managing user accounts and permissions
• Audit and reporting - monitoring and analyzing user activity

How Does Identity and Access Management Work?

IAM works through:

• Central management of user identities
• Automation of access granting and revoking processes
• Implementation of the principle of least privilege
• Monitoring and logging user activity
• Integration with various systems and applications in the organization

IAM standards and protocols — from Kerberos to passkeys

IAM deployments rest on a handful of open standards. The dates below come from the headers of the specifications themselves.

• Kerberos V5 (IETF, RFC 4120, July 2005) — ticket-based network authentication. This specification replaced RFC 1510; versions 1–4 of the protocol came from people who worked on Project Athena.
• LDAP (RFC 4511, June 2006) — the protocol for reaching directory services. The current document replaced RFC 2251, among others.
• SAML 2.0 (OASIS, March 2005) — a framework in which business partners pass each other security information in the form of assertions. Browser-based federated SSO runs on SAML, started either by the application (SP) or by the identity provider (IdP).
• OAuth 2.0 (RFC 6749, October 2012) — an authorization framework. An application gets limited access to an HTTP service on behalf of the resource owner or on its own behalf; the specification replaced OAuth 1.0. Current guidance lives in RFC 9700 (January 2025): a public client must use PKCE, a confidential client is advised to, the implicit grant should be avoided, and the resource owner password credentials grant must not be used at all. OAuth 2.1 is still an IETF Internet-Draft, not an RFC.
• OpenID Connect Core 1.0 (final version from February 2014, now published with errata set 2) — an identity layer built on OAuth 2.0. The application learns who the user is from the authentication performed by the authorization server and receives the result in an ID token formatted as a JWT.
• SCIM 2.0 (RFC 7643 and 7644, September 2015) — an HTTP-based protocol for managing identities across domains, for example between a company and a cloud provider. It defines a shared user schema, a way to extend it and the /Users and /Groups resources, so accounts in applications can be created and removed automatically.
• FIDO2 and passkeys — FIDO2 is the FIDO Alliance’s open set of authentication specifications. A passkey is a credential built on those standards and stored on a phone, a computer or a hardware key. Signing in works like unlocking the device (biometrics, PIN, pattern), and public key cryptography makes passkeys resistant to phishing. On 5 May 2022, Apple, Google and Microsoft jointly said they would broaden their backing of passwordless sign-in built on the shared FIDO Alliance and W3C standard.
• NIST SP 800-63B-4 — the NIST authentication guidelines that superseded the earlier SP 800-63B. They set out three authentication assurance levels (AAL). At AAL3 the authenticator has to resist phishing, and an application assessed at AAL2 has to offer that option. Codes sent over the telephone network (SMS, voice call) are classed in these guidelines as a restricted authenticator.

Non-human identities (NHI) and cloud permissions (CIEM)

Non-human identities are the accounts software uses to authenticate: applications, services, scripts, containers, CI/CD pipelines. In Microsoft Entra they are applications, service principals and managed identities; together with device identities they form the group of machine identities. Microsoft notes that their number is growing fast and that recent attacks increasingly go after them. Unlike a person, a workload often juggles several credentials at once, and it is hard to tell when its identity was created and when it should be retired.

The OWASP Non-Human Identities Top 10 (2025 edition) organises the risks of this group. The list includes identities that were never offboarded (NHI1), leaked secrets (NHI2), excessive permissions (NHI5), long-lived secrets (NHI7) and people using technical accounts (NHI10). OWASP points out that cloud platforms can issue short-lived credentials themselves — AWS roles, Azure managed identities, SVID documents from the SPIFFE standard — so static keys are often unnecessary. SPIFFE is a set of open specifications for giving services an identity in mixed environments, built around short-lived cryptographic identity documents; the CNCF has listed it as a graduated project since 23 August 2022. RFC 8693 (January 2020), in turn, describes token exchange in OAuth 2.0: a service obtains a new token from the authorization server, including when it acts on someone’s behalf or under delegation.

In the cloud every provider has its own permission model, and identities — human and non-human — easily end up with more than they need. CIEM (Cloud Infrastructure Entitlement Management) tools deal with this. Microsoft’s documentation describes them this way: the tool shows the permissions of every identity across Azure, AWS and Google Cloud, finds unused and excessive permissions, trims them and then keeps watch; risk is measured by how far the permissions an identity holds exceed the ones it really uses. Microsoft itself, however, stopped selling its own product in this class (Entra Permissions Management) on 1 April 2025 and ended support on 1 November 2025 — when choosing a CIEM tool, check that it is still being developed.

Benefits of IAM Implementation in Organizations

• Increased data and system security
• Better compliance with regulations (e.g., GDPR)
• Increased employee productivity
• IT cost reduction through automation
• Improved user experience (e.g., Single Sign-On)

Challenges Related to Identity and Access Management

• Complexity of implementation in large organizations
• Integration with existing systems
• Managing identities in hybrid and multi-cloud environments
• Balance between security and user convenience
• Continuous adaptation to new threats and technologies

IAM and regulation: NIS2 and DORA

Two EU acts name the areas IAM is responsible for.

• NIS2 (Directive (EU) 2022/2555), Article 21(2): the risk-management measures include access control policies and asset management, alongside human resources security (point (i)), and — where appropriate — multi-factor or continuous authentication (point (j)). The directive therefore does not require MFA unconditionally. For breaches of Article 21, Member States set fines whose upper limit is at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher (Article 34(4) and (5)).
• DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025), Article 9(4): a financial entity narrows physical and logical access to ICT assets to what legitimate, approved tasks need, and maintains policies, procedures and controls for access rights (point (c)). It also puts in place policies and protocols for strong authentication based on relevant standards (point (d)).

Preparation for both acts is described on the nFlo service pages: NIS2 compliance and DORA readiness audit.

IAM best practices

• Least privilege and just-in-time access. Assign administrative roles as eligible rather than permanent. The user switches a role on only when a privileged task comes up — for a limited time and after approval; Microsoft Entra PIM works this way, for example.
• Phishing-resistant MFA where the risk is highest. Passkeys and FIDO2 keys rely on public key cryptography and resist phishing. NIST SP 800-63B-4 requires such an authenticator at AAL3 and treats SMS as a restricted authenticator.
• Conditional access. A policy takes an “if – then” form: if someone wants to open an application, they have to meet a condition, such as completing MFA. Microsoft Entra Conditional Access makes that decision from signals about the identity and the device.
• Lifecycle driven by the HR system, plus access reviews. Accounts are created and removed based on HR data, resource owners periodically confirm who still needs access, and separation-of-duties (SoD) rules catch conflicting permissions.
• Emergency (break-glass) accounts. Microsoft recommends at least two such accounts: cloud-only (no federation or sync with on-premises AD), with a passwordless method (FIDO2 passkey or certificate), excluded from conditional access policies that block sign-in, and not tied to any one person. Their credentials sit in fireproof safes in separate places, sign-ins to them are monitored with alerts, and they are tested at least every 90 days.
• Privileged access workstations (PAW). Whoever takes over a computer can impersonate every account used on it or capture its credentials and tokens. That is why administrators work from separate, secured workstations.
• Protecting the control plane. Centralised identity systems decide access to data and workloads, which makes them an attractive route for an attacker. Privileged access paths to them need the strictest protection (Microsoft’s enterprise access model).
• Keeping non-human identities in order. Short-lived credentials instead of static keys, secret rotation, no keys written into code, and retiring service accounts nobody uses any more (OWASP).

The nFlo service pages describe the help available in these areas: PAM implementation (administrator accounts and vendor access, privileged sessions through a recorded gateway), MFA deployment (phishing-resistant MFA) and Active Directory security audit (paths leading to Domain Admin rights).

IAM is a key element of cybersecurity strategy, enabling organizations to effectively manage access to resources while ensuring a high level of security.

Learn more

• Zero Trust in Identity Management (IAM): A Defensive Strategy for Modern Organizations
• What is PAM (Privileged Access Management) and How Does It Work?

Explore our services

• Security audits