# Identity and Access Management (IAM)

> Chapter 7 of the Courseiva ISC2-CISSP curriculum — https://courseiva.com/learn/isc2-cissp/identity-and-access-management-iam

**Official objective:** 4.1 — Manage identification and authentication of people, devices, and services

## Introduction

Identity and Access Management (IAM). The discipline that answers two fundamental questions for every single digital interaction: who are you, and what are you allowed to do? Without IAM, a network would be a free-for-all where anyone could read payroll files, delete customer orders, or spin up cloud servers. For the CISSP exam, IAM is a foundational pillar – you cannot protect what you cannot identify or control.

## The High-Security Apartment Building Analogy

73 residents. That is the exact number of people who call The Vault, a luxury apartment building, their home. It has no ordinary metal keys. Instead, every resident receives a personalised electronic fob that holds a unique identifier, like a digital name tag. To enter the building, a resident taps their fob at the main door (claiming an identity) and then enters a four-digit PIN on a keypad (proving they are that person).

Once inside, the fob does far more than unlock a front door. A penthouse resident can summon the lift to the top floor and open the private gym; a ground-floor tenant can only access communal areas and their own flat. The cleaning staff have fobs that work only on service doors between 08:00 and 17:00. Every single tap – every entry, every denied attempt – is recorded in a silent digital log watched by the concierge.

This is precisely how Identity and Access Management (IAM) works in the digital world. The fob is the user account, the PIN is the password, the different floor access rights are authorization policies, and the silent log is what security teams call accounting or auditing. Even visitors get a temporary pass with strict limits, just like a guest account in a corporate network.

## Core explanation

Identity and Access Management (IAM) is the set of policies, processes, and technologies that ensure only authenticated (identity-verified) and authorised (permission-granted) entities – people, devices, or services – can touch digital resources. It sits at the heart of every secure system.

At its simplest, IAM revolves around three building blocks often remembered by the acronym AAA: Identification, Authentication, and Authorization, with a fourth pillar, Accounting. Identification is the act of claiming an identity – like typing a username or swiping a smart card. Authentication is the process of verifying that identity claim, such as by checking a password, a fingerprint, or a one-time code from a phone. Authorization then dictates what that verified identity is allowed to do: view a document, delete a record, or only read an application’s dashboard. Accounting (sometimes called auditing) logs every action, so an organisation always has a reliable trail of who did what and when.

IAM is not just about human beings. In modern IT, devices (a server in a datacentre), services (a nightly backup script), and APIs (an online payment gateway) all need identities. A service account in Microsoft Entra ID, for instance, lets a web application connect to a database without a human entering a password. These non-human, machine identities now outnumber human identities in many businesses.

Authentication factors fall into three broad categories: something you know (password, PIN), something you have (smart card, hardware token, authentication app), and something you are (fingerprint, iris pattern, voiceprint). Using more than one factor is called multi-factor authentication (MFA). Two-factor authentication (2FA) is simply MFA with exactly two different factors. Single sign-on (SSO) improves usability by letting a user authenticate once and then access multiple applications without re-entering credentials, relying on a central identity provider. Behind the scenes, protocols such as SAML and OpenID Connect shuttle trust between the identity provider and service providers.

Once authenticated, what a user can do is governed by an access control model. Discretionary Access Control (DAC) lets the owner of a file decide who can read or write it – think of sharing a Google Doc. Mandatory Access Control (MAC) uses labels (like ‘Top Secret’) and is typical in military environments; users cannot override the policy. Role-Based Access Control (RBAC) gives permissions based on job roles – everyone in the ‘Finance’ role can access the accounting system. Attribute-Based Access Control (ABAC) is more granular: it considers attributes of the user, the resource, and the environment, such as granting access only if the user is a manager AND the request comes from a corporate laptop AND it is within business hours.

IAM also handles provisioning (creating accounts when someone joins), deprovisioning (removing accounts when someone leaves), and access reviews (certifying that permissions are still appropriate). In cloud environments, IAM capabilities are often delivered as a service, such as Cloud IAM in Google Cloud or AWS IAM, or through identity platforms like Microsoft Entra ID. These services let administrators define extremely fine-grained policies – for example, ‘Allow this group to read objects in this storage bucket from this virtual network only’.

Without IAM, you could not implement two of the most fundamental security principles: least privilege (giving people only the permissions they genuinely need) and separation of duties (ensuring no single person can approve and execute a sensitive action, like paying an invoice). IAM is therefore not a single product but a living framework that touches every corner of IT.

## Real-world context

A mid-sized e-commerce company, TrendyGadgets, hires a new developer, Priya. On her first day, an IT administrator does not simply hand over a username and password. They follow a structured IAM workflow.

The administrator opens the company’s identity provider – Microsoft Entra ID – and creates a new user object. They enter Priya’s full name, department, job title, and a corporate email address. During this provisioning step, an automated workflow triggers: Entra ID automatically adds her to the ‘All Developers’ group, which grants baseline access to the source-code repository and the internal wiki. The administrator also assigns her a specific IAM role that permits her to read but not modify the customer database, because her current project only requires read access.

Before handing over the credentials, the administrator enforces MFA. Priya must install the Microsoft Authenticator app on her company phone and register it. The system will now require her password plus a time-limited code from the app every time she logs in from a new location. The administrator also configures a Conditional Access policy: if the sign-in attempt comes from outside the country, it is blocked entirely, even with correct credentials.

Priya logs in for the first time at her office desk. The identity platform identifies her claim (username), authenticates her (password + MFA app), and then checks authorization. RBAC groups grant her access to the code repository and the project management tool. She cannot open the HR portal because her account lacks that role assignment.

Every action Priya takes – logins, file accesses, permission changes – flows into a logging system such as Microsoft Sentinel. The security operations team uses these audit trails daily. When a suspicious login attempt from another continent is blocked by Conditional Access, an alert fires in the SOC dashboard. The IAM framework not only enabled Priya to work securely on day one, but also gave the business ironclad control and visibility over its digital identities.

## Exam focus

The CISSP exam treats IAM as a core, high-weight domain, and the questions rarely ask for straight definitions. Instead, they present you with a scenario and expect you to apply concepts, distinguish between subtly similar terms, and spot configuration mistakes. Expect questions that mash together access control models, authentication factors, and identity-related protocols.

The exam loves to test these exact areas:

- The differences between identification, authentication, and authorization. You will see a scenario where a user swipes a badge (identification) and then enters a PIN (authentication) – you must know which is which.
- Biometrics and their error rates: False Acceptance Rate (FAR, letting an imposter in), False Rejection Rate (FRR, blocking a legitimate user), and Crossover Error Rate (CER, where the two are equal). The CISSP often asks which rate should be adjusted in a high-security facility (lower FAR, even if FRR rises).
- Access control models: DAC (owner decides), MAC (system-enforced labels), RBAC (job function), and ABAC (dynamic attributes). Questions will describe a university, a military base, or a hospital and ask which model fits.
- Authentication protocols: RADIUS (centralised remote access, often with network devices), TACACS+ (Cisco, separates authentication, authorization, and accounting), Diameter (successor to RADIUS), SAML (federation, SSO, XML-based), OAuth (delegated access, not authentication), and OpenID Connect (authentication layer on top of OAuth).
- Kerberos: a ticket-based authentication protocol using a Key Distribution Center (KDC), tickets, and mutual authentication. Expect questions on how Kerberos prevents replay attacks and what a Golden Ticket or Silver Ticket attack represents.
- Identity proofing and registration: NIST 800-63 levels of assurance.

Common CISSP traps you must recognise:

- Mixing up authorization with authentication: a receptionist being able to open a door is authorization, not authentication.
- Thinking that MFA eliminates all risk: an attacker with a session token can bypass MFA because the session is already authenticated.
- Confusing SAML with OAuth: SAML deals with authentication and attribute exchange; OAuth is about delegated authorisation, not proving who you are.
- Believing that biometrics are always the strongest factor: they have error rates and can be spoofed.
- Forgetting that IAM covers service accounts and devices, not just people: a misconfigured service account with excessive permissions is a favourite exam scenario.

The correct answer pattern is almost always the one that implements least privilege, separates duties, or enforces accountability through logging – not the one that simply applies the strongest technology without considering business context.

## Step by step

1. **Identity Provisioning** — An authority (such as HR or an automated script) creates a digital identity for the subject – a new user account, a device record, or a service principal – and populates it with basic attributes. Without this step, there is no identity to manage.
2. **Identification** — The subject presents an identity claim to the system (e.g., a username, an email address, or a smart card ID). The system now knows what identity the subject asserts, but does not yet trust it.
3. **Authentication** — The system challenges the subject to prove the claim, typically by requesting one or more authentication factors (password, biometric scan, token code). Successful authentication confirms that the subject is who they say they are.
4. **Authorization** — The system checks the authenticated subject’s permissions against a policy store (RBAC role, ACL, ABAC rules) to decide exactly what actions are allowed on which resources. This step enforces least privilege.
5. **Accounting** — Every significant event – logins, permission changes, resource accesses, and denied attempts – is recorded in a tamper-resistant audit trail. This log enables security monitoring, forensic analysis, and compliance reporting.
6. **Continuous Access Review and Revocation** — Over time, roles change. Periodic access reviews identify stale permissions, and compromised or departed identities are promptly deprovisioned. Without this live-cycle management, IAM drifts into a dangerous state of over-entitlement.

## Comparisons

### Authentication vs Authorization

**Authentication:**
- Answers ‘Are you really this person?’
- Uses factors like passwords, tokens, or biometrics
- Happens before any permission check

**Authorization:**
- Answers ‘What are you allowed to do?’
- Uses roles, ACLs, or policies to determine rights
- Happens after identity is verified

### Role-Based Access Control (RBAC) vs Attribute-Based Access Control (ABAC)

**Role-Based Access Control (RBAC):**
- Permissions tied to a fixed job role (e.g., ‘Manager’)
- Simple to set up; role explosion is a risk
- Best for organisations with clear, stable department structures

**Attribute-Based Access Control (ABAC):**
- Permissions decided by evaluating multiple attributes (user, resource, environment)
- Highly granular and dynamic, but complex to administer
- Ideal for environments with diverse, context-sensitive access rules

### SAML vs OAuth 2.0

**SAML:**
- Primarily an authentication and federation protocol
- Transmits identity assertions using XML
- Common for enterprise SSO between web applications

**OAuth 2.0:**
- Primarily an authorization framework, not authentication
- Uses access tokens (often JWTs) to grant scoped permissions
- Powers delegated access, like letting a social media app post on your behalf

### Multi-Factor Authentication (MFA) vs Two-Factor Authentication (2FA)

**Multi-Factor Authentication (MFA):**
- Uses two or more different authentication factor types
- Can include three factors: knowledge, possession, and inherence
- Often used as an umbrella term in policies

**Two-Factor Authentication (2FA):**
- Always exactly two factors – one plus one
- Arguably the most common implementation of MFA
- Every 2FA is MFA, but not all MFA is 2FA

## Diagram

_The AAA lifecycle: a subject moves from identification through to resource access, with every significant event logged for auditing._

```mermaid
flowchart TD
    A[Subject: User or Service] --> B[Identification: Claims Identity]
    B --> C[Authentication: Verifies Claim]
    C --> D[Authorization: Checks Permissions]
    D --> E[Access Granted to Resource]
    C --> F[Accounting: Audit Logging]
    D --> F
    F --> G[Monitoring & Compliance]
```

## Common misconceptions

- **Misconception:** Identity and Access Management only deals with human user logins – usernames, passwords, and maybe a fingerprint. **Reality:** IAM governs any entity that needs to prove its identity and request access, including application services, background processes, APIs, and Internet of Things (IoT) devices. (Beginners usually encounter IAM when setting up their first email account, so they equate it with human credentials. In a real enterprise, non-human machine identities often outnumber human ones.)
- **Misconception:** Authentication and authorization are different words for the same step; once you log in, everything you need just works. **Reality:** Authentication verifies who you are. Authorization then determines what that verified identity is permitted to do, and it can be different for every application or resource. (Because the browser or app typically handles both seamlessly and invisibly, users never see the separation. The CISSP exam punishes anyone who merges the two concepts.)
- **Misconception:** Turning on multi-factor authentication makes an account unhackable. **Reality:** MFA drastically reduces the risk of credential theft, but session tokens, push notification fatigue, SIM-swapping, and man-in-the-middle phishing kits can all bypass MFA under certain conditions. (Marketing material and consumer devices oversimplify MFA as an on/off switch for security, so newcomers assume it is an absolute shield.)
- **Misconception:** IAM is just the on-premises Active Directory I set up in the office. **Reality:** Microsoft Active Directory (and its cloud evolution, Microsoft Entra ID) are directory services that implement IAM. IAM itself is a broader discipline encompassing policy, processes, and technology that governs identity lifecycles, access reviews, and compliance. (For many people starting in IT, their only exposure to identity is through Active Directory. Cloud IAM, CIAM (customer IAM), and machine identities often remain invisible until later.)

## Key takeaways

- Identification (claiming an identity) always comes before authentication (verifying that claim); you cannot verify what has not been claimed.
- Biometrics are not a silver bullet — they have measurable false acceptance and false rejection rates that must be tuned to the organization’s security appetite.
- Least privilege means assigning users and services the absolute minimum permissions they need to perform their function, and nothing more.
- Single sign-on improves user experience and reduces password fatigue, but it also creates a high-value target — the identity provider.
- Service accounts and API keys are identities too; neglecting their hygiene is a leading cause of cloud security breaches.
- Accounting (audit logging) is the only way to retroactively answer ‘who did what and when’, making it indispensable for investigations and compliance.
- Federation protocols like SAML and OpenID Connect allow trusted identity brokering across separate organisations, but they are not interchangeable.

## FAQ

**What is the exact difference between authentication and authorization?**

Authentication verifies that you are the person you claim to be (e.g., checking a password). Authorization decides what you are allowed to see or do after your identity is verified (e.g., allowing read-only access to a folder).

**Is a fingerprint scanner used for identification or authentication?**

In most IAM systems, a fingerprint is an authentication factor. You must first claim an identity (by entering a username or tapping a badge), and then the fingerprint scan verifies the claim. The scanner can also be used for identification in a one-to-many search against a biometric database, but that is rarer in corporate IAM.

**What does the AAA acronym stand for in IAM?**

AAA stands for Authentication, Authorization, and Accounting (or Auditing). Some variations prefix it with Identification (IAAA). It describes the continuous flow from checking a user’s identity to recording their actions.

**How is OAuth different from SAML?**

SAML is an authentication standard that exchanges assertions about a user’s identity, often used for single sign-on. OAuth is an authorisation framework that lets one service perform actions on another service on behalf of a user, without exposing the user’s password.

**Why do organisations still use Active Directory if cloud IAM exists?**

Many organisations have decades of on-premises applications, file shares, and printers that rely on Active Directory. Cloud IAM (such as Microsoft Entra ID or AWS IAM) often connects with on-premises directories through federation or synchronisation, giving a unified view without discarding existing investments.

**Can multi-factor authentication be bypassed?**

Yes. Attackers can steal session tokens after successful authentication, wear down users with push notification bombing, or use SIM-swapping to intercept SMS codes. MFA dramatically raises the bar, but it does not provide absolute security by itself.

## Check your understanding

1. **A user enters a username and then scans their fingerprint. Which part is identification and which is authentication?**

   Answer: The username is identification (claiming an identity), and the fingerprint scan is authentication (verifying the claim).

2. **A hospital wants doctors to access only the medical records of patients in their own ward. Which access control model would fit best?**

   Answer: Attribute-Based Access Control (ABAC), because access depends on attributes of the user (ward assignment) and the resource (patient location), not just a fixed role.

3. **What does the Crossover Error Rate (CER) of a biometric system indicate?**

   Answer: CER is the point at which the False Acceptance Rate (FAR) equals the False Rejection Rate (FRR). A lower CER generally indicates a more accurate and better-tuned biometric system.

4. **During a penetration test, an attacker uses a service account’s API key to read a storage bucket. Why was this possible despite the organisation having strong user MFA?**

   Answer: Service accounts and API keys are non-human identities that often do not support MFA in the traditional sense. If the key was not protected by network restrictions or short-lived tokens, it gave direct, unaudited access.

5. **A global bank wants employees to log in once each morning and then use email, trading platforms, and HR portals without re-entering credentials. What IAM technology should the bank deploy?**

   Answer: Single sign-on (SSO), likely built on a federation protocol such as SAML or OpenID Connect, with a central identity provider that all participating applications trust.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/isc2-cissp/identity-and-access-management-iam